When an agent works in a demo and fails in production, the usual fix is a longer prompt. It rarely helps, because the problem is almost never the wording.
Where agents actually break
We reviewed four hundred failed runs from teams moving agents into production. Fewer than one in ten failed because the model reasoned badly. The rest failed around the model: a tool timed out and nothing retried it, a long job lost its context halfway through, or a step quietly spent far more than anyone expected.
What a runtime adds
A runtime treats each step of an agent's work as something durable. It is written down before it runs, retried when it fails, and resumed when the process restarts. The model still decides what to do. The runtime makes sure it gets done.
- Durable steps that survive restarts and deploys
- Retries with backoff for every tool call
- Memory scoped to the job, not the chat window
- Spend limits checked before the step, not after
const run = await ordin.run({
job: "Reconcile Q3 invoices",
agents: ["planner", "analyst", "courier"],
budget: { usd: 5 },
retries: { max: 3, backoff: "exponential" },
});Prompts still matter, just less
Good instructions still make a difference. But once the runtime handles retries, memory and limits, a prompt can go back to describing the job instead of defending against every way the job could go wrong.
We deleted two thirds of our system prompt the week we moved to a runtime. It had been doing a job it was never good at.
Platform lead, fintech customer
- Runtime
- Reliability
- Architecture