One Job Per Agent: Narrow Scope As A Safety Principle

One agent, one job. Write that rule before choosing the model, building the prompt, or connecting a tool. A job is a bounded outcome with a clear trigger, permitted actions, and a stopping point. “Handle customer support” is not one job. “Classify an incoming refund request into one of five approved categories” is. Consider an agent reading support emails. It may extract the order number, identify the refund reason, and propose a category. It may not issue the refund, rewrite policy, contact the customer, or update unrelated account fields. Those are separate jobs with separate permissions. This can look unnecessarily restrictive during a demo because the model is plainly capable of doing more. Capability is not the boundary. Responsibility is. If the job cannot be stated in one precise sentence, the agent has too much scope.

Better models make bad boundaries look reasonable. They follow vague instructions more convincingly, recover from messy inputs, and produce polished answers when the underlying decision is wrong. That fluency encourages teams to keep adding duties. Soon the same agent is reading contracts, assessing risk, drafting amendments, and emailing suppliers. The problem appears in the cases nobody listed. A supplier submits an expired contract containing a handwritten renewal clause and asks for payment details to be changed in the same email. No prompt contains every combination of ambiguity, fraud, and policy conflict. Trying to enumerate them creates a brittle book of exceptions that still loses to production. Stop treating edge cases as a prompt-writing contest. Reduce the job instead. Let one agent extract clauses, another compare them with policy, and a human approve any change. Better reasoning should improve performance inside the boundary, not justify removing it.

Scope is a containment mechanism. It limits what an agent can see, decide, and change when the model hallucinates or an attacker manipulates its input. Prompt instructions alone do not provide that containment. Permissions and workflow design do. Take an accounts-payable agent that checks whether an invoice matches a purchase order. Give it read access to those two records and permission to return “match,” “mismatch,” or “review.” Do not give it access to supplier bank details or authority to release payment. If a malicious invoice contains instructions to change the destination account, the agent has nowhere to write that change and no payment tool to execute it. The attempt still matters, but the damage is bounded. Blast radius is not an unfortunate consequence to measure after deployment. It is a design variable. Decide the maximum acceptable failure first, then build the agent so it cannot exceed it.

Narrow scope pays three dividends: failures become legible, contained, and reviewable. Legible means the team can identify which decision went wrong. Contained means that error cannot spread across unrelated systems. Reviewable means a person can inspect the output without reconstructing an entire chain of hidden reasoning. Consider a recruitment agent whose only job is to compare an application with six published role criteria and cite the evidence for each result. If it marks a candidate as lacking Python experience despite a cited project, the failure is obvious. It has not also rejected the applicant, generated feedback, scheduled another candidate, and updated workforce forecasts. A reviewer sees six claims, six citations, and one proposed outcome. That is a realistic oversight task. Asking a human to approve a complete hiring process in thirty seconds is theatre. Narrow work produces small review units, and small review units give human judgement somewhere concrete to operate.

The do-everything agent feels efficient because it removes handoffs from the diagram. It also hides coupling, permissions, and untested assumptions inside one prompt. That debt stays invisible until production supplies the first awkward case. Imagine a sales agent asked to research a prospect, score the opportunity, draft outreach, update the CRM, and send the email. A subsidiary shares a name with its parent company. The agent merges their facts, assigns a high score, overwrites the correct CRM record, and sends a confident message citing a deal the recipient never made. One identification error has crossed research, decision, recordkeeping, and external communication. Debugging now requires replaying the whole run and deciding which downstream actions must be reversed. The saved handoffs were not removed. They became implicit and unauditable. Wide scope borrows speed from the demo and repays it as operational debt when real data arrives.

An agent should earn a wider remit through evidence, not receive it because the latest model benchmark improved. Extend one boundary at a time. Define the new action, measure its failure modes, limit its permissions, and preserve a rollback path. Suppose an invoice-matching agent has produced reliable recommendations for three months. The next step is not autonomous payment. Allow it to approve exact matches below £500 from established suppliers, while duplicates, changed bank details, missing purchase orders, and higher values still go to review. Track false approvals, reversals, exception rates, and reviewer disagreement. If performance holds across enough real cases, raise one threshold or add one tightly specified category. Do not expand the action set and the financial limit in the same release; you will not know which change caused a failure. Trust is accumulated evidence attached to a defined job. My stance is simple: widen only after the narrower system has proved where it is safe.