Eighteen months of running agents in production: what actually transfers

Eighteen months in

For the past eighteen months I have been running a custom multi-agent ecosystem across eight live projects.

That includes Claude Code skills, sub-agent definitions and MCP integrations. These are not demos or weekend experiments. They are systems attached to paying customers, where reliability matters more than novelty.

Over that time, one pattern has become difficult to ignore.

The claim I would push back on

A common claim is that agents replace engineers. That has not been my experience.

In practice, agents are something both less dramatic and more useful. They provide leverage for the parts of engineering that are necessary, repetitive and easy to postpone: audits, reconciliations, migrations, consistency checks, and the operational work that should happen but often does not.

The value came less from replacing engineering effort than from making neglected engineering work economically viable.

What has actually moved the needle

Tool surface design

An agent is only as capable as the tools you give it. Most of the engineering effort is not prompt wording. It is designing the API surface: what a tool exposes, what it refuses to do, what it returns, and how predictable those behaviours remain over time.

Sub-agent delegation

One agent trying to solve everything is consistently worse than several agents with narrowly defined responsibilities. Clear boundaries and explicit hand-offs produce systems that are easier to reason about, easier to evaluate and easier to improve.

Comparison diagram: one brittle generalist agent doing everything, versus an orchestrator delegating to three specialist agents (audit, reconcile, migrate). — The generalist agent bends under everything at once. Three narrow agents with an orchestrator stay legible and testable.

Eval-driven iteration

If you cannot measure the output, you are not engineering; you are guessing with extra steps. Evaluations are the difference between a convincing demo and a production system.

Loop diagram: build, run in production, measure with evals, improve. — Build, run, measure, improve: the loop that separates a demo from a system.

Context engineering

The context you exclude matters just as much as the context you include. Many problems described as "the model got confused" turn out to be context problems: irrelevant information, competing instructions or unnecessary history that should never have been present.

Why these patterns transfer

The orchestration layer changes surprisingly little between development and production. The patterns I rely on inside Claude Code map directly onto standalone deployments using the Anthropic SDK and MCP. The interfaces are different, but the underlying engineering remains the same: tool design, delegation, evaluation and careful control of context.

Those lessons have proved much more durable than any individual model or framework.

The real lesson

The engineering discipline that works is the same one that has always worked. Design the failure modes before the happy path. Make behaviour measurable. Keep interfaces narrow. Decide what the system is allowed to do before deciding what it should do.

The tools have become dramatically more capable.
The engineering principles have barely changed.