AI agents for defined product workflows.

Give the agent a bounded job

A support triage flow, an information-gathering task or a record update is easier to evaluate than an open-ended autonomous worker. Start by defining the inputs, permitted actions and the point where a person takes over.

A bounded job also needs a written definition of completion: a ticket categorised and assigned to a queue, or one confirmed write against a named object. That definition decides which tools the agent needs, which it must not be given, and what the evaluation set measures.

What the implementation can include

Tool contracts, integration code, action permissions, step and cost budgets, timeouts, retries and failure logs. A retrieval layer can supply authorised context. The proposal specifies which components your workflow needs.

The implementation consists mainly of integration code, validation, permission checks and state handling around the model calls rather than prompt text. The model selects among permitted options; that code enforces what is allowed, persists progress, handles partial failure and records what happened.

Planning or a fixed sequence of steps

Where the steps are known and stable, a deterministic pipeline that calls a model at defined points is cheaper to run and easier to test than letting a model decide the order of work. Model-chosen ordering is worth its additional cost when the steps a request needs cannot be listed in advance, because which systems must be consulted depends on what earlier results contain and there are too many distinct paths to encode. A step count that varies, such as one lookup or five, does not require it: that is a loop with a cap in ordinary code.

Tool contracts and input validation

Every action available to the agent is exposed as a tool with a typed schema. Model output is treated as a request rather than an instruction: the tool validates the parameters against the schema, checks permissions and only then performs the operation. A free-text parameter is acceptable where the tool stores or displays it, and is not where the tool would pass it into a query, a command or another system unchecked.

Contracts also define the error surface. Each tool returns a typed success, the failure cases the agent can act on such as a missing record or a conflicting update, and an unrecoverable error that ends the run.

Permission scopes and tenant isolation

A run executes with its own credentials and a scope limited to the records and actions the task requires, with read, create, update and delete granted separately. In multi-tenant products the isolation is designed into the query path rather than left to the model: tenant context is attached to the run and applied wherever records are read or written. The approach and its tests are agreed in the scope; no isolation guarantee is made here.

Bounded loops, step limits and budgets

The execution loop runs until the task completes, until a limit is reached, or until a person cancels the run. Limits cover steps per run, tool calls per step, tokens, wall-clock time and spend. They are set above what a normal run consumes, so a run that exhausts one is treated as a fault rather than as expected behaviour: it stops and escalates with its state attached. Repeated identical calls are detected and end the run. Where a workflow contains action pairs that cancel each other out, the rule that recognises them is written with the workflow.

State and memory between steps

A multi-step run needs state that outlives a single model call: the task, the steps already taken, the tool results and the current position in the workflow. Holding that only in prompt context ties the run to one process and loses it on restart, so run state is usually persisted in your database, where it can be resumed, inspected in flight and audited. What the agent retains between runs is a separate decision; retrieval over approved sources is often preferable to accumulated free-text memory, because the origin of each fact stays identifiable.

Where human approval is required

Actions in the agreed workflow are classified by reversibility and cost. Reversible, low-cost actions can run without a checkpoint; irreversible, externally visible or expensive actions queue for approval, and the approval screen shows the proposed action, its inputs and the records affected. It also shows the justification the model gave, which is model output rather than a verified explanation of why the action was chosen. A workflow can launch with approval on every write, and a class of action can move to autonomous execution once evaluation results support it.

Failures, retries and idempotency

External services time out, return conflicts and fail partway through a sequence. Transient failures are retried with backoff and a cap; permanent ones end the run. Tools that write carry an idempotency key derived from the run and the step. Where the downstream service honours that key, a retry reuses the original result; where it does not, the tool keeps its own record of completed writes and checks it before retrying, and which of the two applies is settled per integration. Where a sequence can be ordered so that the irreversible step runs last, it is ordered that way; where it cannot, we scope compensating actions or leave the run in a declared incomplete state for a person to finish.

Tracing an agent run

Each run produces a structured trace of the input, every step, the tool calls with their parameters and results, the limits consumed and the outcome. It is specified as a requirement rather than added after an incident, because a run cannot be reconstructed from data that was not recorded while it ran. A trace establishes what the run did; why the model selected a particular step is inferred from it. Traces hold business and often personal data, so redaction, access control and retention are decided with the design.

Review before release

Agree representative cases, invalid requests, service failures and actions requiring approval. Test those paths against written acceptance criteria before deployment with your approval.

That testing takes the form of a fixed evaluation set of recorded tasks with expected outcomes, scored the same way on every change: task completed, correct tools called, no out-of-scope action attempted, and the steps and cost consumed. Prompt changes, model upgrades and new tools are run against it, because a change that improves one class of task can degrade another. No accuracy figure is promised here; acceptance criteria and the scoring method are agreed in the scope.

What an agent project costs

Every engagement starts with a fixed-price discovery sprint at USD 2,500 over two weeks, which produces the architecture, initial screen designs, acceptance criteria, a running-cost model and a fixed price for the build. The sprint fee is deducted from the build.

Running cost is per run rather than per message, because one task can involve several model calls, retrieval and multiple tool invocations. The cost model accounts for steps per run as well as tokens per step, and for the infrastructure that holds run state and traces. What an AI feature costs to run →

Part of the AI Feature Implementation Sprint → · Explore our work → · Read the agent guardrails write-up →