Building Agents Is 80% Plumbing
A rare look inside a production agent shows the moat isn't the model — it's the unglamorous engineering wrapped around it.
When the internals of a multi-billion-dollar coding agent briefly became public, the coverage fixated on unreleased feature flags. The far more useful signal was the architecture underneath — and how little of it is about the model.
The moat is the harness
Strip away the hype and what sustains a production agent is a stack of deeply boring primitives: a tool registry that describes capabilities before executing them; permission tiers that separate read-only from destructive actions; session state that survives a crash; workflow state that knows which step you were on and whether an action is safe to retry; hard token budgets; structured streaming and event logs you can replay. None of it is glamorous. All of it is the difference between a demo and a product.
Failure paths are the design
The recurring theme is planning for things going wrong. Agents crash, connections drop, users close tabs. Good engineering assumes the failure and designs the recovery — persisted checkpoints, a "black box" event on the last message before a crash, and verification that checks not just the agent's output but the changes you make to the harness itself.
The real risk is over-engineering
The common way agent projects die isn't doing too little. It's building a multi-agent coordination layer before sessions can survive a crash, or a plugin marketplace before permissions work. Start single-agent and simple; earn the complexity.
The model was never the hard part. The plumbing is the whole game — and it turns out to be good backend engineering applied to a genuinely new problem.