name-the-job

Write it in this shape and no other: given INPUT, return OUTPUT. One input clause, one output clause.

Say the grain while you are here. One record in and one out, or many in and one summary out. "Why we are losing" is portfolio grain and "why did we lose this one" fans out per deal. Both fit the sentence shape and they are different agents, so pick before you go on.

Then apply the split test, which is about work and not about grammar. Would splitting duplicate the work? If the halves would each re-read the same input, and could disagree about what they read, they are one agent. Several fields of one record, produced by one read of one input, are one output: a renewal-terms row, not a date agent plus a notice-period agent plus a clause agent.

Only after that, look at the sentence. An "and" or a comma joining two genuinely different deliverables, from different inputs or different reads, means two agents: "a scored list and a draft message" is two agents that fail at different times and share the blame. When the work test and the sentence disagree, the work test wins. Do not let a rewording settle it. If calling the output one noun is the only thing that made it pass, you have renamed the problem.

The output may also include a refusal: "return one message, or a refusal and the questions that would make it writable" is one output in two states. The states have to be addressed to the same person. A refusal that goes back to the operator is a state. Something that goes outward to a third party, like a clarifying question sent to a customer, is a second deliverable with its own delivery path, and that usually belongs to a comms agent rather than this one.

When a request names several jobs, do not run this skill once per job and hand back a pile of specs. Pick the target: the one whose current output is worst. If that is not obvious, ask. The rest become fence items and land on the map as suppliers or later work. One spec and one map, every time. If two really are co-equal and nobody can choose, scope the one that is upstream of the other and say why.

A schedule or a trigger is not a fence item and gets no resolution. Record it on its own line: what fires this, and what it does when it fires with nothing to do. A recurring agent that wakes to an empty queue should do nothing visible rather than produce an empty report.

Ask these five questions in order. Each one surfaces work that feels like it belongs and does not.

1. What data does it need that it would have to go and get? Fetching is almost always a different agent, because fetching fails differently than judging.
2. What decision does it make that someone or something else already makes? If a scoring model, a CRM field or a person already decides this, the agent reads that decision rather than making its own. Careful here, because this question can land on the job itself rather than beside it. The test: would reading somebody else's answer make this agent pointless? If yes and that answer exists, the real job is a reader, and say so. If yes and no such answer exists, this is the judgment the agent owns. Write that down as owned, with the reasoning, so the next person does not mistake it for a gap.
3. What happens to its output after it is produced? Sending, scheduling, posting and writing back are their own jobs.
4. What happens immediately before its input arrives? Whatever produces the input is a sibling, and it is usually the blocker.
5. What would stop it cold on a real input? Not a wrong answer, an impossible one. A scanned PDF where it expects text. A language it cannot read. A file too large to hold. These are capability gaps, and each one is a sibling agent or a preprocessing step. What the agent does with a merely bad or empty input is a contract question, not a fence item, so leave that for agent-contract.

Questions one, three and four produce an item for almost every agent that has ever existed, because nearly everything needs something fetched, something written somewhere, and something upstream. Those three are plumbing and they do not count toward a healthy fence. The bar is at least one item specific to this job: a decision it must not make, a capability it does not have, or a judgment a named person keeps. If you cannot find one of those, you have not understood the job yet.

Each item gets exactly one of three resolutions, and you say which:

• Covered. An existing skill or agent does this. Name it. Check before you claim it: a skill that sounds right and does something adjacent is not coverage.
• Human. A person does this and should keep doing it. Name the role, not the team.
• Gap. Nothing does this yet. This is a new agent, and it goes on the map.
• Unverified. It might be covered and you could not check. Name the candidate and what would confirm it. This is a legitimate resolution rather than a failure, and it is the honest answer every time this skill runs without access to your library. Never resolve an unchecked item to GAP. A map that tells someone to rebuild a skill they already own is worse than one that says go look.

Checked means you read the candidate's own description and method. A name that sounds right is not coverage and never was.

"Something else handles that" is not a resolution. It is the thing that becomes a surprise in week three.

A gap is a blocker when nothing valid reaches the agent's input without it. Not "the agent would be better with it," and not "the agent cannot run unattended without it," because hand-feeding is usually the right first move and that looser reading would make every gap a non-blocker.

Everything else is later, however appealing it looks.

Blocker or later often turns on data quality rather than architecture. A loss-theme analyst needs call notes only if the loss-reason field is mostly "Other." When the call depends on data you have not looked at, mark it unknown and say what you would check, rather than guessing at a CRM you have not seen.

Blockers come first on the map, but the target agent still gets built before them whenever you can feed it by hand. That is how you test the contract without waiting on a dependency, and it means the blockers get built against a consumer you already trust.

Hand back the one sentence, the fence with resolutions, and the swarm map with its build order. The map is the deliverable people do not expect and the one they keep.