Boundaries

If a person cannot definitively say which one should be used in a given situation, an agent cannot be expected to do better.

That is the whole test, and it settles most arguments before they start. It is also easy to run: hand your catalogue to someone who did not write it, describe a task, and ask which one they would pick. If they hesitate, the agent will too — except the agent resolves its hesitation by choosing one and continuing, and does not mention that it hesitated.

You will meet this twice, from both sides. Your firm will have a catalogue of agents and workflows and you will route work into it: close support, reconciliation, invoice coding, variance analysis. And you will write instructions that hand an agent a set of things it can call. Same rule, same failure, different day.

The failure is recognisable. The agent tries one, gets a partial answer, tries the next, gets an overlapping answer, and spends the budget deciding rather than working. It is not confused about the task. It is confused about the menu.

Here is the most common mistake, and it is invisible to the person making it.

reconciliation_helper — Assists with reconciliations.

Everything in that sentence is true. It is also useless, because it answers a question nobody had. Anyone reading the catalogue can guess what a thing called reconciliation_helper does. What they cannot guess is when to reach for it rather than for close_assistant.

reconcile_account — Match one account's transactions to the ledger for a single period. Use when you have a statement and need to know whether it agrees.

The second sentence is doing all the work. It gives a precondition — you have a statement — and a purpose. Between two entries written like that, the boundary is visible without anyone having to be told what it is.

So the effort goes into when, not what. What is usually inferable from the name. When is never inferable from anything.

Every catalogue that has been alive for a year contains one of these:

ap_helper — General helper for accounts payable questions.

It arrived because someone had a task that fit nowhere, and adding an entry was easier than deciding where it belonged. It cannot be described without listing what it does, which is the definition of something with no boundary.

A catch-all is worse than a gap. A gap is visible: you look for the thing you need, it is not there, and you ask. A catch-all is always plausibly the right answer, so it quietly absorbs work that belonged somewhere specific, and nobody finds out until an output is wrong in a way that traces back to a routing decision nobody made deliberately.

Delete it and check what was actually lost. It is usually nothing.