An agent demo is easy to make impressive and easy to make wrong in the same afternoon. The gap between "it worked in the demo" and "it's safe to run unattended" is where most agent projects quietly stall.
The demo tests the happy path by construction
Whoever builds the demo picks the inputs, which means they unconsciously pick inputs the agent handles well. That's not dishonest, it's just how demos get made — and it's exactly why a demo can't tell you how the agent behaves on the input you didn't think to try.
Recovery is the feature, not the model
The question that actually determines whether an agent ships isn't "how good is the model" — it's "what happens when a tool call fails, a step times out, or the agent gets stuck in a loop." We spend more engineering time on detection and recovery from those states than on the agent's core reasoning step.
Ship the guardrail before the capability
Every new tool an agent gets access to ships with its own rate limit, its own confirmation step for anything irreversible, and its own kill switch — before the agent is allowed to use it unsupervised. It's slower to build. It's also the difference between an agent project that survives contact with real users and one that gets quietly turned off after an incident.