Most agent projects start with a prompt. The ones that survive contact with production start with a spec — because the decisions that matter are not what to say to the model, they are what the agent remembers, what it is allowed to spend, which tools it may call and with what shape, what happens when a provider fails, and who approves the risky actions.
This produces a starting point for those decisions, in the structure we use ourselves. It is not a finished configuration and it will not run as-is against your stack. It is the document you argue about before anyone writes code, which is the cheapest time to argue.
What is in the spec, and why
Memory schema. What the agent retains between runs, split into facts it has established, episodes it should learn from, and procedures it follows. Without this an agent re-learns the same things every run and appears to get worse over time as your patience with re-explaining wears out.
Context budget. Token limits per turn and per task, with a summarisation trigger before the ceiling. If you cannot state your context budget as a number, you do not have one — and an agent with no turn limit is how two agents end up talking to each other overnight.
Tool contracts. A typed input and output schema per tool, plus timeout and retry policy. Loose JSON prompting means the agent can call a tool with a malformed argument and the tool can return something the agent does not expect. Schemas remove an entire class of failure.
Fallback cascade. An ordered list of providers, so one outage or one revoked model slug degrades the agent instead of stopping it. Provider access changes without notice.
Guardrails. Hard spend ceilings that stop execution, a circuit breaker on repeated failure, approval gates scaled to the risk you selected, and a delivery check so a run that produced work but delivered nothing is treated as failed.
The spec is generated, the thinking is not
The numbers this produces are defaults derived from your answers, not measurements of your workload. Treat the budgets as a starting point to be tightened once you have observed real runs — the first week of production data will tell you more than any default.
What the spec is genuinely useful for is the argument. Hand it to whoever owns the systems the agent will touch and the objections arrive immediately: that tool has rate limits you have not accounted for, that action needs approval from someone else, that data cannot leave our infrastructure. Every one of those is cheaper to hear now than after the build.
When the answer is not an agent
If your answers describe one input, one deterministic transformation, and one output with no judgement involved, the spec will still generate — but a script or an existing automation tool will beat an agent on cost and reliability. Agents earn their complexity when the task requires judgement across variable inputs.
We say the same thing in theframework comparison: knowing which problem you have saves weeks of forcing the wrong tool.