AI-Enabled Software & Automation

AI-enabled software built around a defined task.

Start with the task

Decide whether the task needs
AI at all

AI is not the default. We compare the task against rules, search, and conventional automation before introducing probabilistic behavior.

TIER01

Rules and conditionals

Fits when the task has a finite, describable set of conditions and outcomes. No probabilistic behavior is required.

TIER02

Search and retrieval

Fits when the task is finding or ranking known information rather than generating or deciding something new.

TIER03

Conventional automation

Fits when the workflow is deterministic and repeatable, and scripts or integrations handle it reliably.

TIER04

AI-enabled behavior

Fits when interpreting, generating, or judging unstructured input is unavoidable, and the task can define acceptable output, review, and fallback.

Task and data boundary

Define the user, decision, and consequence
before the model

A model earns its place only after the task, its inputs, and the cost of a wrong answer are understood.

01/

Task and consequence

Name what decision or output the system produces, and what happens when it is wrong.

02/

Inputs and authorised data

Define exactly which sources the model may read, and what it must never see.

03/

Human review and abstention

Decide who reviews output, when the system should refuse to answer, and how correction happens.

04/

Evaluation before release

Build a set of difficult, ambiguous, and adversarial cases before trusting a convincing demo.

System boundary

Give tools and actions the
smallest useful authority

The model's authority should stay proportionate to the risk. Broader autonomy is a separate, harder-won decision.

(001)

Keep authority proportionate to risk

The model only ever has the smallest set of permissions and actions the task genuinely requires. Broader autonomy is earned by evidence, not assumed.

(002)

Deterministic guardrails

Validation, schemas, and rule-based checks sit around the model, catching failure before it reaches a user or system.

(003)

Grounding and citations

When the task needs current or authoritative facts, output is grounded in retrieved, attributable sources rather than model memory alone.

(004)

Fallback and escalation

Every AI-enabled path has a defined non-AI or human alternative for low confidence or out-of-scope input.

Technology decisions

AI & agentic
runtime stack

The stack follows the requirement, not the other way round. These are the categories this engagement typically has to decide.

Anthropic Claude 3.5

OpenAI GPT-4o

LangChain & LlamaIndex

Pinecone & pgvector

Python & FastAPI

Redis Queue & Celery

Possible scope

Choose rules, search, models, automation, or bounded agents
from the task

The exact responsibility depends on the task and agreed scope. None of the following should be assumed automatically.

Task, users, and consequence mappingAuthorised data and source boundariesOutput schema and acceptance criteriaAbstention and escalation rules

Model or provider selection against the taskRetrieval and grounding where facts matterTool and action permissioningProduct surface integration

Representative and adversarial test setsHuman review and correction workflowAccuracy, latency, and cost baselinesAudit trail for reviewed decisions

Monitoring for drift and failure modesProvider and model version change processFeedback loop into evaluation dataOwnership for post-release behavior

AI implementation decisions

Select models and providers through
evidence and constraints

Every AI decision trades something specific for something else. The useful choice is the one whose reason is understood.

Rules or a model?

A model earns its place only where the task cannot be reduced to a describable set of conditions.

How much authority does the system get?

Autonomy should expand only as evaluated evidence justifies it, not by default.

General-purpose or fine-tuned?

A general model with strong guardrails and grounding is often more defensible than an undertested fine-tune.

Immediate or reviewed output?

Some tasks tolerate an immediate answer; others need a queued, reviewable step before anything reaches a user.

Inspectable outputs

Leave the workflow, controls, evidence,
and ownership inspectable

Deliverables should make the path from task to AI-enabled behavior visible and testable.

01/

Task and evidence record

The defined task, data boundaries, and the evidence used to decide AI was justified.

02/

Evaluation results

The test set, acceptance criteria, and the known failure modes the system currently has.

03/

Working integration

The AI behavior connected into the actual product surface, not a standalone demo.

04/

Operating handoff

Monitoring, escalation paths, and change ownership documented for whoever runs the system after release.

Delivery and engagement

Choose AI when probabilistic behavior
defines the work

The starting engagement should reduce the uncertainty that matters before committing to a build.

BOUNDED DISCOVERY

Task feasibility review

A bounded exercise to confirm whether AI is justified before committing to a build.

Discuss this model

FIXED-SCOPE MILESTONE

Defined AI feature

A scoped, project-shaped engagement to design, build, and evaluate one AI-enabled capability.

Discuss this model

STAGED RELEASES

Staged rollout

Release to a limited surface or audience first, expanding only as evaluation evidence supports it.

Discuss this model

CONTINUOUS CADENCE

Continued evaluation and tuning

Ongoing ownership of monitoring, evaluation data, and provider or model changes after launch.

Discuss this model

Fit and routing

Use the service
that owns the defining condition.

AI-Enabled Software & Automation is the right starting point when probabilistic behavior is the defining risk. A different service may own the wider need.

01/ ALTERNATIVE

Custom Software Development

Choose this when AI is one feature inside a larger requirement-specific system.

Explore route

02/ ALTERNATIVE

Product Modernisation & Improvement

Choose this when introducing AI is part of a broader change to an existing product.

Explore route

03/ ALTERNATIVE

Cloud & DevOps

Choose this when the defining need is model hosting, inference infrastructure, or observability rather than the AI behavior itself.

Explore route

04/ ALTERNATIVE

Ongoing Product Engineering

Choose this when continued evaluation and model change are part of an active roadmap responsibility.

Explore route

Frequently Asked Questions