AI delivery · Agents

An agent that does useful work, inside limits you can inspect

If you need an AI agent that takes real actions in your systems, you can commission a scoped agent implementation: I build the agent, the runtime permissions around it, the approval steps for consequential actions, an evaluation suite and the recovery paths for when it fails. You end with an agent in production, its controls documented and an owner who can run it.

This is a good fit if…

  • You have a tool-using prototype that works in a demo, and the next step is letting it act on real systems with real data.
  • Your agent needs to call internal APIs, update records or send messages, and someone has to decide what it may do without a human.
  • Security or risk has asked how the agent is constrained, how its actions are logged and how it is stopped, and you need concrete answers.
  • You are choosing between building on an agent framework and writing a thinner runtime of your own, and want someone who has shipped both.

Look elsewhere if…

  • You only need an existing assistant connected to your tools through the Model Context Protocol. Use MCP integration with controlled tool access.
  • The agent already runs and the problem is that it fails unpredictably. Use AI agent reliability and recovery engineering.
  • You want an engineer under your own manager rather than a commissioned outcome. Hire an AI agent engineer on contract.

What you get

Agent implementation, controls and recovery engineering

  • An agent running in your environment on an agreed set of tasks, with its tool access defined in code rather than in the prompt.
  • An action register listing every tool the agent can call, the permission it needs and whether a human must approve it.
  • An evaluation suite that runs before each change to prompts, models or tools.
  • Tracing and audit logs that show what the agent did, why, and on whose behalf.
  • Tested recovery paths: retries, safe stops, compensating actions and a kill switch.

How it runs

  1. 01

    Define the job and its limits

    We write down the tasks the agent should do, the systems it touches and the actions that must never happen without approval. This becomes the action register.

  2. 02

    Build the runtime and tools

    I implement the agent loop, tool interfaces with typed inputs and outputs, permission checks enforced outside the model, and approval steps for consequential actions.

  3. 03

    Evaluate and break it

    An evaluation suite built from real task examples, plus adversarial cases: bad inputs, unavailable tools, prompt injection through retrieved content, and partial failures.

  4. 04

    Release and hand over

    A staged release with tracing, alerts and a kill switch, then a handover of the code, action register, evaluation suite and runbook to your named owner.

What needs to be in place

  • A defined set of tasks and the systems the agent must act on, with an owner for each system.
  • Test or sandbox access to those systems, and a route to production access through your normal change process.
  • A decision-maker who can say which actions require human approval.
  • Agreement on which model providers and data-processing locations are acceptable.

Not included

  • Fully autonomous operation of consequential or regulated decisions. Human approval stays where your risk owners require it.
  • Guaranteed task success rates. Evaluation reports what the agent does reliably and where it does not.
  • 24/7 operational support. Ongoing care is a separate, capacity-limited maintenance arrangement.
  • Training foundation models. The work uses existing hosted or self-hosted models.

Which agent engagement fits your situation

Starting pointWhat you getChoose it when
Production AI agents (this page) A task and a prototype, or just a taskA built agent with permissions, approvals, evaluation and recoveryYou need the whole agent delivered and controlled
MCP integration An assistant or agent that needs your toolsMCP servers with scoped tool access, authentication and loggingThe agent exists; the work is connecting it safely to systems
Governed AI agents An agent in a setting with approval and audit obligationsApproval workflows, policy enforcement and an audit trail mapped to your controlsRisk, compliance or audit must sign off before the agent acts
Reliability and recovery An agent that already runs but fails in ways you cannot predictFailure analysis, retries, idempotency, safe stops and recovery testsIncidents, stuck runs or duplicated actions are the problem
Maintenance An agent in production that someone must keep healthyA bounded review cadence, incident roles and an improvement backlogThe build is done and you need capacity-limited ongoing care

From demo to an agent you can let act

Most agent projects reach the same point. A prototype, built in a few days, calls a handful of tools and completes the task in a demo. Then someone asks what happens when it is given a malformed record, when the API it depends on is slow, when a retrieved document contains instructions, or when it decides to update a thousand rows instead of one. The prototype has no answer, because it was never designed to have one.

The work on this page is building the parts around the model that make an agent safe to run: the runtime, the tool boundary, the permissions, the approvals, the evaluation, the tracing and the recovery paths. The model is one component. Most production failures I have seen come from the parts around it.

What the work involves

I build agents on a principle published as the Substrate Pattern: the agent proposes, and a deterministic layer underneath decides what is allowed to happen. In practice that means:

  • Typed tools. Each tool has a schema for its inputs and outputs, and calls that do not validate are rejected before they reach your systems.
  • Permissions outside the model. The agent acts with credentials scoped to the task and to the user it is acting for. A prompt cannot widen them.
  • Approval steps. Actions that are expensive, irreversible or customer-facing pause for a human, with the proposed action and its reasoning shown in plain language.
  • Idempotency and compensation. Retries do not duplicate side effects, and actions that partly complete can be rolled back or completed safely.
  • Tracing. Every run records the inputs, model calls, tool calls, approvals and outcome, so an incident can be reconstructed afterwards.

Evaluation runs alongside the build. I assemble task examples with the people who do the work today, add adversarial cases, and wire the suite into CI so that a prompt or model change cannot ship without being measured.

The signature deliverable

You receive agent implementation, controls and recovery engineering: the agent code, the action register, the evaluation suite and a runbook. Illustrative example of an action register extract:

ToolEffectCredential scopeApprovalRecovery if it fails midway
lookup_orderReadOrders API, read-only, current customerNoneRetry with backoff
issue_refundWrite, financialPayments API, refund-only, capped valueHuman approval above agreed thresholdIdempotency key; reconcile against payment log
send_customer_emailExternal messageEmail service, templated sends onlyApproval for first release, sampled afterwardsQueue holds message until confirmed
update_crm_noteWriteCRM, notes field onlyNoneOverwrite-safe append

Illustrative example. Not taken from a client engagement.

How acceptance is judged

Acceptance criteria are agreed before the build: the task set, the success threshold on the evaluation suite, the actions that must be blocked or approved, and the recovery scenarios that must pass in a rehearsal. Your platform lead and the risk owner for each consequential action sign off. The evaluation report is part of the deliverable, including the cases the agent still gets wrong.

Ownership and handover

The code runs in your repositories and infrastructure from the first commit. At handover your named owner receives a walk-through of the runtime, the action register and the evaluation suite, plus a runbook covering alerts, the kill switch and common failure modes. If you want help keeping it healthy afterwards, maintaining production AI workflows is a bounded arrangement with a stated capacity, not an open-ended support promise.

Narrower routes

This page covers the full build. If your need is narrower, one of the routes in the comparison above will fit better: MCP integration for connecting an existing agent to your tools, governed AI agents where approval and audit obligations lead the design, and reliability and recovery engineering for an agent that already runs but fails unpredictably. If you want an engineer under your own manager instead, see hire an AI agent engineer.

Questions buyers ask

Which agent framework do you use?

The one that suits your stack and team, which is sometimes no framework. I have built agents in Python, TypeScript and Rust, on established frameworks and on thin custom runtimes. The deciding questions are who will maintain it, how much control you need over the loop, and how the framework handles tool errors and tracing.

How do you stop the agent doing something it should not?

Permissions are enforced in code at the tool boundary, not requested in the prompt. Each tool runs with the narrowest credential that works, consequential actions go through an approval step, and every action is logged with its inputs. A kill switch stops new actions without corrupting work in progress.

Can the agent run on our infrastructure with our data controls?

Yes. The agent can run in your cloud account or on your servers, call models through your approved providers or self-hosted models, and keep logs in your observability stack. We agree data handling, including what is logged and for how long, before any real data is used.

How is this priced?

As scoped delivery with acceptance criteria, shown in the engagement model on this page. Scope depends mainly on the number of tools and systems, how many actions need approval, and how much evaluation data exists. If the requirement is unclear, we start with a short scoping exercise before committing to a build.

What if evaluation shows the agent is not good enough?

Then you find out before production, which is the point. The evaluation report shows which tasks are reliable and which are not. Options include narrowing the agent's remit, adding approval steps, changing models or stopping. A stop recommendation is a legitimate outcome.

Review your agent delivery requirements

A short, non-confidential description is enough to start. I read every brief personally and reply within two business days, including when the answer is that I am not the right fit.

Step 1 of 2 · The basics