One Job Per Agent

Why this matters

Agents that try to do many different things become hard to understand, hard to evaluate, and hard to stop. When a multi-purpose agent misbehaves, you cannot tell which capability went wrong, so you either live with it or shut the whole thing down. A narrow agent with one job fails in one place, and the fix is as small as the job.

What you will be able to decide after this

Whether the solution's capabilities are separable enough to run and stop independently.
Where the deliberate handoffs are — and where the human sits between them.
Whether an unexpected action can be traced to one capability and one owner.

Core lesson

Prefer narrow agents with clear jobs:

One primary goal — a single sentence that says what the agent is for. If it takes two sentences, it is two agents.
Clear inputs and outputs — what it receives, and what it produces, named and bounded.
Explicit boundaries — the allowed actions and the prohibited actions, written down, tested.
A human owner — a named person accountable for what this agent does.

If a workflow needs multiple capabilities, compose multiple narrow agents with deliberate handoffs rather than one large autonomous system. The handoff is where control sits: a human between agents, or a confirmation token. Example structure:

Agent A: Research and draft only. No send or write permissions.
Agent B: Execute a specific approved action. Requires explicit human confirmation token.
Human: Reviews draft, decides, and releases the confirmation if appropriate.

The test question is the shutdown test: "If this agent starts doing something unexpected, can I explain exactly what it was supposed to be doing and shut only that capability down?" If the answer is no, the agent is too wide. Narrow it until the unexpected action points to one capability with one switch.

Worked example

The answer-drafting system as narrow agents. Agent A drafts: job is research-and-draft; inputs are the approved question and the two knowledge bases; outputs a draft with citations to the review queue; allowed actions — read the two bases, write to the review queue; prohibited — sending anything, creating tickets, accessing customer accounts. Agent B publishes: job is executing one approved action; inputs a confirmed draft plus a confirmation token; allowed — sending the approved answer, nothing else; prohibited — drafting, editing, answering questions, acting without the token. The human interface: the support lead reviews Agent A's draft, edits it, and releases the token for Agent B. The shutdown test, run for real: Agent A starts citing sources outside the two bases — the fix is disabling its read scope, one switch, and Agent B keeps working on confirmed drafts. Two capabilities, two agents, two switches.

Practice

List the capabilities in your Module 1 solution. For each, write the one primary goal in a single sentence. If a capability takes more than one sentence, split it. Then check each against the shutdown question.

Apply — produce the artifact

Redesign the solution from Module 1 as one or more narrow agents. For each agent define: single job, allowed actions, prohibited actions, and the human interface.

Verify

Ask: "If this agent starts doing something unexpected, can I explain exactly what it was supposed to be doing and shut only that capability down?" If the answer is no, narrow it further.

Sources

This module is original practice guidance based on the authoring standard and does not depend on a specific external factual claim. Editorial review is still required.