AI agent engineering for systems that act, not just answer
An agent is a loop with tools and consequences. The loop is the easy part. The hard parts are what it is allowed to touch, how it knows when to stop, and how you find out what it did when it goes wrong.
Agents fail differently from every other AI system
A chat completion that is wrong is a bad answer. An agent that is wrong has already taken actions — called the API, written the record, sent the message. That single difference changes what has to be engineered: the failure is no longer a bad output to catch but a sequence of side effects to bound. The symptoms below are the ones that indicate the loop, not the model, is the problem.
- A demo that works impressively and has never been trusted with a real task
- No reliable answer to "what did it actually do?" when a run goes wrong
- Cost per run that varies by an order of magnitude with no way to forecast it
- Loops that do not terminate, or terminate early having done half the job
- Uncertainty about what the agent can reach if it decides to, which is why it has not been given access
- No way to tell whether a change to the prompt or the tool set made it better or worse
The people who usually bring us this problem
CTO / VP Engineering
You have been asked for an agent feature and need a straight answer about what can be made safe and measurable, versus what would be an unquantified risk in production.
Head of Product
The workflow you want to automate spans several systems and steps. You need to know which parts can run unattended and which need a human, and why.
Founder
Agentic capability is central to your product and you need it built to a standard you can put in front of a customer, not demonstrated in a screen recording.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
An unbounded agent is an unbounded incident
Every permission the agent holds is a blast radius. Deciding that boundary is a design decision, and one that is much harder to retrofit than to set — an agent that has been trusted with write access is not easily walked back.
Unmeasurable agents cannot be improved
If the only evaluation is a person watching a run and forming an impression, every change is a coin flip and every regression ships. Trajectories have to be captured to be assessed.
Cost per task is the business model
An agent that reasons for twelve steps where three would do may be correct and still uneconomic. Step count is a design variable with a direct cost, and it needs to be visible per task rather than per month.
Capabilities
Each of these is work we carry out, not an area we advise on.
Task decomposition and tool interfaces
How a goal becomes a sequence of calls, and how those tools are described. Most agent failures are tool-interface failures: an underspecified tool, an ambiguous return shape, or an error the agent cannot distinguish from a valid result.
Loop and termination control
Explicit stopping conditions rather than a step limit standing in for one — including how the agent recognises it has finished, and what happens when it has not finished but must stop anyway.
State, memory and context management
What persists across steps, what persists across runs, and what is deliberately discarded. Context is a cost and a correctness concern at the same time.
Permission boundaries and blast radius
Scoping each tool to the minimum it needs, separating read from write, and defining which actions are reversible before they are granted rather than after they are used.
Approval gates and human oversight
Where the run pauses for a person, what that person sees, and how approval is recorded. Placing these correctly is the difference between an assistive agent and one nobody will let run.
Trajectory evaluation
Evaluating the path, not only the destination. An agent that arrives at the right answer by calling a write endpoint it should not have touched has failed, and an output-only evaluation cannot see that.
Cost and latency per task
Instrumented per run rather than per month, because the aggregate hides the expensive tail — which is invariably the path real inputs take.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Decide the blast radius before the architecture
What the agent may read, what it may write, and what is irreversible. This is settled first because it constrains every subsequent choice, and because an agent granted access is far harder to restrict later than one that was never given it.
Make the loop observable before making it autonomous
The first version records every step, tool call, argument and result. Autonomy is added once the record shows the run behaving as expected — not before, because an unobserved agent in production is an incident waiting for a trigger.
Evaluate trajectories, not outputs
Scored runs are built from real tasks and assessed on the steps taken as well as the result. This is what catches destructive-but-successful runs, which are the ones that matter most and which answer-only evaluation reports as passes.
Cap the cost as a functional requirement
A per-task ceiling is set with the client, enforced in the loop, and treated as a specification rather than a nice-to-have. An economics ceiling that is discovered late is an architecture problem by then.
Grant autonomy against evidence, not optimism
Agents start behind approval gates. Gates come off step by step as recorded runs demonstrate the behaviour — which turns "can we trust it?" from a debate into a decision with data behind it.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Design
- Permission and blast-radius specification, per tool
- Read/write separation and reversibility classification
- Termination and failure-path definition
- Per-task cost and latency ceiling
Implementation
- Tool interfaces with validated contracts
- Loop with explicit stopping conditions
- State and context handling
- Step-level observability and run recording
- Approval gates where required
Operation
- Trajectory evaluation harness over captured runs
- Cost and step-count monitoring per task
- Review process for relaxing a gate
Architecture and technology
System concerns
- Goal intake and decomposition
- Tool definitions and argument validation
- Per-step result checking and error classification
- Loop control and stopping conditions
- Write-action gating and approval
- Run recording and replay
Operational concerns
- Permission scope per tool, reviewed
- Cost and latency instrumentation per run
- Evaluation over captured trajectories
- Incident path for a run that acted unexpectedly
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
You need a model integrated into an existing system, not an autonomous loop
See AI Engineering for integration, structured outputs and evaluation of a single model component.
You need a scheduled or triggered workflow that runs deterministically
See AI Automation. If the steps are known in advance, a workflow beats an agent on cost, reliability and explainability — and we will say so.
Frequently asked
Have you shipped an agent in production?
We can show the proposed tool boundaries, approval steps, evaluation plan and rollback controls during discovery. If you require a reference deployment in your exact environment, raise that at the start of the conversation.
Should we be building an agent at all?
Often, no. If the steps are knowable in advance, a deterministic workflow is cheaper, faster, easier to explain and far easier to debug — and an LLM is only needed for the parts that genuinely require judgement. We will frequently recommend AI Automation instead, and that recommendation is not a consolation prize.
How do you keep an agent from doing something destructive?
By deciding what it can reach before writing any of it. Tools are scoped to the minimum each step needs, writes are separated from reads, irreversible actions sit behind an approval gate by default, and every run is recorded. The boundary is designed first because an agent that has been given write access cannot easily be walked back to not having it.
Which agent frameworks do you use?
As few as the problem allows. A framework adds a dependency and an abstraction over the part that most needs to be legible — the loop — and the underlying APIs are usually enough. We would rather you could read the control flow than have it hidden behind one.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.