Agent engineering
An agent is given a goal and a set of tools, and decides which to call and in what order. That is the whole difference from an automation, and it is why the engineering is mostly about constraint: what the agent may touch, when it must stop, and who checks it.
01Scope
Two shapes of agent
The shape is the first decision, and it sets everything after it: the tool set, the cost per run, and how much of the behavior you can actually test.
One job, a small tool set, a clear stopping condition. The agent knows what finished looks like and stops there. Most production work is this shape, and it is what we recommend first, because it is the one you can measure.
A goal that needs planning across several sub-tasks, with a supervisor deciding what happens next. Worth it when the path genuinely varies from run to run, not because it sounds more capable.
02Wire
What we build
Five pieces, and each one is a place where a production agent parts company with a demo.
- tool use
- Every capability is a typed tool with a narrow schema, its own error surface, and idempotency where a repeat call would otherwise double-write.
- MCP servers
- Connectors that expose your systems to the agent through one contract, so the same tool works across models and hosts.
- orchestration
- Sequential chains, parallel fan-out where calls are independent, and a router that picks a path rather than running everything.
- memory and state
- Run state that survives a restart, context managed so the window does not fill with noise, and a long-term store only where recall genuinely helps. We are explicit about what an agent should not remember.
- stopping conditions
- The step budget, the confidence floor, and the escalation path for when neither is met.
03Build
How the build runs
In this order, every time. The evals come before the agent, because otherwise there is nothing to build against.
-
Scope one task
Pick a single job and narrow it until it can be measured. A task with a clear stopping condition is the one that goes first.
-
Write the eval cases
Your real examples become test cases, before any agent exists. They are what defines correct for this task, and they stay the reference for every change after.
-
Define the tools
Name every capability the agent needs, then write its schema and its failure modes. A tool that cannot say how it failed cannot be recovered from.
-
Build the orchestration
Start with the simplest shape that passes the evals. A chain before a router, a router before a supervisor, and only move up when the eval results ask for it.
-
Set the gates and ceilings
Decide which writes wait for a person, then agree the cost ceiling and the latency ceiling and enforce both inside the run.
-
Ship with tracing on
Tracing is live from the first run, not added after the first incident. Plan, tool calls, inputs, outputs and cost are all recorded.
04Trust
What holds the agent to its scope
An agent chooses its own path, so the interesting failures are the ones nobody wrote down. These four are how we find them before you do.
The eval suite is built from your examples and runs on every change to a prompt, a tool schema or a model version. When a change makes the agent worse at the task, the suite says so before the change ships.
Every run records its plan, each tool call with its inputs and outputs, the retries, and the cost. When someone asks why the agent chose that path, you read the trace instead of guessing.
An agent only ever holds the tools its task needs, and every write is checked against your rules before it executes. Anything above the threshold you set stops and waits for a person.
Step budgets, cost ceilings and latency ceilings are enforced in the run, not reviewed after the invoice. When a model or an API is down, the agent takes a defined fallback path instead of improvising one.
Related work
Agents rarely arrive alone. Grounding usually comes from retrieval, and the triggers and approval steps around a run come from workflow automation.
05Asked
Questions we get asked first
How do we know whether we need an agent or a workflow?
Ask whether the path varies. If the steps are the same on every run, a scripted workflow is cheaper to build, cheaper to run and far easier to debug. An agent earns its cost when the order of the work depends on what it finds along the way. We settle that question in scoping, and we say so plainly when a job does not need an agent.
What does the first engagement actually deliver?
One task, scoped narrowly enough to be measured. You get the eval cases written from your real examples, the tools and their schemas, the orchestration that passes those evals, the gates and the cost and latency ceilings we agreed, and tracing switched on from the first run.
Who owns the code and the evals?
You do. The tools, the MCP servers, the orchestration code and the eval suite are yours, in your repositories, running on your accounts. There is no platform of ours you have to keep paying for to run the agent you paid us to build.
Bring us one task, not a roadmap
Describe a job you would hand to a capable new starter. We will tell you whether it wants an agent or a workflow, what it would touch, and where it should stop and ask.