Watch how an agent gets built today. A team picks a goal, sketches a plan, wires the prompts and the tools, and ships a prototype. Then the real work starts: the prototype loops on a refund call, deadlocks on a long session, leaks a field it should have redacted. Weeks go into finding failures that were decided the moment the design was chosen.
The Wrong Side of the Line
The whole tooling market sits on the wrong side of that line. Tracing, evals, guardrails, observability: every one of them needs a running agent and real traces before it can say anything. They are good at telling you how the thing you built is doing. None of them can tell you whether you should have built it that way.
The Design Gap is the Product
That gap is the product. Before there are prompts, traces, evals, or production failures, the paths an agent can take are already fixed by four things: its goal, its user personas, the data it reads, and the tools it calls. Lay those paths out and the break points are visible. You do not need to run the agent to see that an uncapped retry against a flaky API is going to spin, or that a write against a drifting schema is going to fail.
We call the result a Faultmap: the map of where the agent breaks, plus the first test suite it has to pass. It runs in the design phase, on the goal and your data, with nothing to instrument. The point is not to replace the eval stack. Keep it. The point is to move the moment of truth one step earlier, to where a fix costs cents instead of a sprint.
Why Agent Failures Repeat
The reason this works is that agent failures repeat. A retry loop in a support agent is the same retry loop in a sales agent. Schema drift, state deadlock, leaked private data: the same shapes, across every domain. Learn a failure class once and it is recognizable in the next agent before a line of its code exists.
Build-first and pray has been the only option because nothing ran earlier. That is the habit we are ending. Map it before you build it.