The gap between 'agent research' and 'agent in production' is where most projects actually break. Here's what we've learned about scoping them right.
1. Agents need bounded scope to stay reliable
An agent that can do "anything" will eventually do something wrong. Start by defining what success looks like for one narrow task: "classify these support tickets" or "validate this API response schema". Unbounded autonomy is a research question, not a deployment pattern. The arxiv work on "Agents in the Wild" captures this tension well.
2. Routing and fallback logic are where the real work lives
The agent itself is maybe 20% of the system. The rest is monitoring what it decides, catching when it's outside its competence zone, and routing to a human or a different tool. Papers like CodeRescue show this explicitly: budget-aware routing isn't a feature, it's the foundation. If you're not budgeting for mistakes and modeling recovery paths, your scope is too loose.
