Most agent projects that stall do not stall on the model. They stall because nobody drew a line around the work. “Handle support” is not a job an agent can own — it is a department. “Triage every inbound ticket, tag it, and draft a first reply for a human to send” is a job. The second one can be specified, measured, and fixed when it breaks.
Scope is the design decision
An agent’s scope determines almost everything downstream: which tools it needs, what its failure modes look like, and whether anyone can tell if it is doing well. Broad scope defers all three questions. Narrow scope forces them up front, which is uncomfortable in week one and the reason the thing still works in month six.
A useful test: can you write down, in one sentence, what the agent did today and whether that was correct? If the answer needs a paragraph and a caveat, the scope is still too wide.
Measure the job, not the model
Once the job is narrow, evaluation stops being abstract. You are no longer asking whether the model is good; you are asking whether ninety-four percent of tickets got the right tag, and what the other six percent had in common. That is a question an engineering team can act on.
This is also what makes an agent maintainable by someone who did not build it. The eval set becomes the specification. When the business changes, you change the examples and watch the number move.
Let the boundaries do the integration
Narrow agents compose. Three agents that each own one step, with a human or a queue between them, are easier to reason about — and far easier to roll back — than one agent holding the whole process in its context. The seams are where you put the logging, the approvals, and the off switch.
None of this is an argument against ambition. It is an argument about ordering: scope the job, prove it, then widen. Agents that own one job earn the right to own the next one.