Most agent projects do not fail on the model. They fail because nobody agreed what the agent was supposed to do.
Pick a decision, not a department
“Automate support” is not a scope. “Draft a first reply for password reset tickets, in English, and hand anything else to a human” is a scope. The second version can be tested, measured and rejected. The first can only be argued about.
We start every engagement by cutting the process down until it has three properties: a clear trigger, one decision, and an outcome somebody already tracks. If we cannot find all three, the process is not ready for an agent, and we say so before any code exists.
One indicator, agreed in the room
A scope needs a number attached to it before the build starts. Not a dashboard, one number: median handling time, share of tickets resolved without escalation, hours of manual entry removed per week.
The number does two things. It tells us when to stop tuning, and it gives the team a way to say the agent is not working without it becoming a matter of opinion.
Refuse the vague middle
The hardest part of scoping is declining work. Processes that are undocumented, that change every quarter, or where two teams disagree about the correct answer are not automation candidates yet. They are process problems wearing an AI costume.
Fixing the process first is slower to sell and faster to deliver. We have never regretted starting narrow. We have repeatedly regretted starting wide.