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.
3. Start with tooling clarity, not prompt creativity
An agent is only as good as its tools. Before writing the prompt, map out exactly what actions it can take, what data it has access to, and what happens when a tool fails. This forces you to be honest about scope. A vague tool ("search the web") explodes scope. A precise one ("query column X from table Y where Z matches regex") keeps it tight.
4. Measure cost and failure modes early
Deploy a narrow agent first. Measure: how often does it complete the task, how much does it cost per run, what percentage of failures are fixable vs. hard-stop errors. Use real data, not happy-path tests. This tells you whether to expand scope or double down on the tools you have.
5. Accept that stateful, long-running workflows need different thinking
If your agent is supposed to maintain context across hours or days, you're not building an agent anymore, you're building a state machine that uses agent logic as one step. Graph-based workflows (like LangGraph patterns) handle this better than agent loops. Name the pattern correctly or you'll scope it wrong from day one. Takeaway: Scope wins happen when you stop asking "what problem could an agent solve" and start asking "what specific action, with known inputs and clear success criteria, can this agent own". Everything else (routing, monitoring, recovery, state) follows from that clarity.