How do you scope what an agent should do?
The hardest part of building a useful agent is picking the right job for it. Most failed agent projects fail at this step, not at the engineering step. Pick a job too broad and the agent fails in unpredictable ways. Pick a job too narrow and the agent is not worth the engineering cost. The framework below is how good agent teams pick.
The decision to make is about the agent-vs-human boundary in your workflow. Where exactly does the agent's responsibility end? What does it hand back to a human, and what does the human hand back to it? This boundary is the single most important specification, and it is rarely written down.
Start with the job, not the technology
Every productive agent-building project begins by describing a specific job a specific role currently does. Not 'we want to put AI in our sales process' — that is a category, not a job. Instead: 'an SDR opens our CRM each morning, identifies the 30 leads most likely to convert based on activity in the last 48 hours, drafts a personalized first-touch email for each, and queues them for review.' That is a job. It has an actor, a trigger, a sequence, an output, and a handoff. An agent can replace it. The category cannot be replaced because the category is not a thing that gets done.
The discipline is to write down the current process in enough detail that someone unfamiliar with the company could execute it. Most companies cannot do this for their own processes; the institutional knowledge lives in the head of the person doing the job, and even they may not have a complete written description. The act of writing it down is half the value of the agent project, regardless of whether the agent ever ships, because it forces the organization to make implicit decisions explicit.
Decompose into the agent-vs-human boundary
Once the job is described, the next question is which sub-tasks the agent should own and which the human should still own. There is no universal answer. The right boundary depends on three things: the cost of the agent making a wrong decision; the cost of the human reviewing every agent decision; and the rate at which the agent's decisions can be verified after the fact.
A useful framing is the four-quadrant test. (1) Tasks with low cost of error and easy verification — these are good agent territory; let the agent do them and spot-check the output. Generating draft emails, summarizing documents, classifying tickets. (2) Tasks with low cost of error but hard verification — riskier; the agent might be wrong and you won't know. Anything in this quadrant needs to ship with structured output the human can scan quickly. (3) Tasks with high cost of error and easy verification — the agent proposes, the human approves. Drafting contracts, sending money, sending external communications. The agent owns the workflow up to a decision point; the human signs off. (4) Tasks with high cost of error and hard verification — keep the human in the loop entirely for now. The technology will improve, but this is not where to start.
Most production agents in 2026 live in quadrants 1 and 3. They are agents in the technical sense — they plan and act — but they hand back to a human at high-consequence moments and operate freely on low-consequence moments. This is the 'co-pilot' framing, and it is the right framing for the current state of the art.
Test 1: can a junior person do this job today?
If the answer is no, your agent project is in trouble. The current generation of language models — through 2026 — performs at roughly the level of an intelligent but uninformed entry-level employee. Specific tasks can be much better (writing first-draft code, summarizing long documents) but the average reliability is junior-level. If the job cannot be done by a smart but inexperienced human given the same instructions, written context, and tools that the agent will have, the agent will not be able to do it either.
The test is useful because most organizations have done this experiment already without realizing. Look at the jobs that have been successfully delegated to junior employees or to BPO providers. Those are the jobs that are most likely to be agent-ready. The jobs that have resisted delegation — that require deep institutional knowledge, complex stakeholder management, or judgment in ambiguous situations — are the jobs that will continue to resist agent automation through at least 2027-28.
Test 2: does the cost economics work?
Build a per-execution cost model before you build the agent. Estimate the number of model calls, the average token count per call, the API rates, and any tool-execution costs (database queries, third-party APIs). Compare that to the cost of the human doing the same job, including loaded labor cost and the time-to-completion. The agent should be at least 5x cheaper on a per-execution basis to justify the engineering cost. Less than 5x and the engineering effort eats the savings.
Be honest about the engineering cost. A production agent typically requires 1-2 engineers for 3-6 months to build, plus ongoing maintenance at 0.25-0.5 FTE forever. The amortized cost over the first two years is roughly $500K-1M for an internal agent at typical Bay Area cost rates. The agent has to deliver at least that much value, net of API and ops costs, to justify itself.
The cases where the math works overwhelmingly are: (a) high-volume jobs (hundreds or thousands of executions per week), (b) jobs where the human time is genuinely expensive (lawyer, doctor, consultant, senior engineer), and (c) jobs that scale a function the business otherwise cannot afford to scale at all (e.g., personalized outreach at 10x current volume). The cases where the math does not work are low-volume, low-stakes tasks where the agent is intellectually interesting but cannot pay for itself.
Test 3: what does the failure mode look like?
Before scoping, imagine the worst plausible failure of the agent. Specifically: imagine the agent makes a wrong decision in a real production execution. What is the consequence? Who finds out, and when? Who fixes it, and how long does that take? If the answer is 'a confused customer gets a slightly worse email' the scope is probably fine. If the answer is 'we wire $50,000 to the wrong account' the scope needs hard guardrails.
A useful exercise is to write out three specific failures that could happen, plus what the system does in each case. If you cannot write three plausible failures, you have not thought about the agent enough. If the system has no answer for at least one of them, the scope is too aggressive for the current state of the engineering.
Strategic read
Good agent scoping is the discipline of saying no. The agent should not do things adjacent to its job, even when the model could clearly do them. Every additional capability is another failure surface to engineer and another evaluation dimension to maintain. The agents that ship and stay shipped are scoped narrowly enough that the team can hold the entire problem in their heads at once.
If you are evaluating an agent product as a buyer, scope discipline is the most reliable indicator that the vendor knows what they are doing. A vendor whose pitch says the agent can do anything is selling generality, which is the easy story. A vendor whose pitch says the agent does one job exceptionally well and explicitly lists what it does not do is selling reliability, which is the actual product.