We have been in the room when a lot of AI projects get scoped. The conversation almost always gravitates toward the same question: which model should we use? GPT-4 or Claude? Open-source or API? Fine-tuned or prompt-engineered?
These are not bad questions. But they are the wrong first question. The model is maybe 20% of whether an agent succeeds in production. The other 80% is whether someone thought clearly about what the agent is allowed to do, what happens when it hits something unusual, and how a human gets back into the loop when it needs to.
The scope question comes before the model question
A well-scoped agent with a mediocre model will outperform a brilliantly-prompted agent with a fuzzy scope every time. Why? Because a fuzzy scope means the agent is regularly encountering situations it was not designed for, and it has to improvise. Sometimes it improvises correctly. Often it does not. And because the scope was fuzzy, no one quite knew what "correct" was supposed to look like anyway.
The scope question has three parts:
- What exactly triggers this agent to start acting?
- What are the complete set of actions it is allowed to take?
- What situations cause it to stop and wait for a human?
If you cannot answer all three before you start building, you are not ready to build yet.
Entry conditions: the trigger problem
Most agent designs start with "when X happens, the agent does Y." The problem is that X is usually described at a level of abstraction that hides important edge cases. "When a new support ticket arrives" sounds clear. But: what if it is a duplicate of an existing ticket? What if it is from an account that is currently in dispute? What if it arrives outside business hours and the escalation contact is on leave?
The trigger is not just "when does the agent start" — it is "what context does the agent need to have before it starts, and what does it do if that context is incomplete or ambiguous?"
A good entry condition definition lists every known exception to the happy path and specifies what happens in each case. Not all of those exceptions need to be handled by the agent. Some of them should immediately route to a human. The point is that the decision is made explicitly, not left for the agent to figure out on its own.
Action space: what the agent is and is not allowed to do
This is where most agents are over-built. The temptation is to give the agent as many tools as possible — if it can do more, it can handle more situations. In practice, a larger action space means more ways for the agent to take an action that seemed reasonable in the moment but was not what the humans involved would have wanted.
We use a simple rule: the agent should have the minimum action space required to handle the happy path reliably. Everything else gets added incrementally, after the base case is running cleanly in production.
The agent should have the minimum action space required to handle the happy path reliably. Everything else gets added incrementally.
This is not a technical constraint — modern orchestration frameworks make it easy to add tools. It is a design discipline. An agent that can only send an email and update a CRM record will surprise you much less than an agent that can also create new records, reassign ownership, and trigger downstream notifications.
Exit conditions: the escalation design
Every production agent needs a clearly defined set of conditions under which it stops acting and surfaces a situation to a human. This is not a failure mode — it is a feature. An agent that knows when it is out of its depth is far more useful than one that keeps going regardless.
Good escalation design requires thinking about three categories of situation:
- Ambiguous inputs — the agent receives something it cannot confidently classify
- Conflicting signals — the data from two sources does not agree
- Consequential decisions — the next step has a disproportionate downside if wrong
For each category, the design specifies: what does the agent surface to the human, in what format, and through what channel? A well-designed escalation feels like a useful briefing, not a confused interruption.
The model question: now you can ask it
Once you have a clear scope, action space, and escalation design, model selection becomes much more tractable. You know what kinds of reasoning the agent needs to do. You know how much ambiguity it will encounter. You know what the output format needs to look like. These constraints narrow the model choice considerably — and often the right answer is simpler and cheaper than you expected, because the hard work has been done in the scope design rather than delegated to the model.
This is the other thing that often surprises clients: a well-scoped agent with a smaller, cheaper model typically costs less to run and is more predictable than an under-scoped agent with a frontier model. Predictability in production is usually worth more than raw capability.
The agents we are most satisfied with, when we look back at them six months after deployment, are the ones that do one thing cleanly and reliably. Not the ones that could theoretically do many things.