Agentic Routing

An agent with tools has a far wider surface than a prompt does. Access is transitive: whatever a tool can read, the agent can read, and whatever that tool can reach in turn belongs to the agent as well. A repository token, a ticket system, a shared drive, and a search index each carry their own reach, and the reach compounds when one agent holds several of them. The question worth answering before you grant a tool is what its credentials chain to.

This is the line between judgment and authority. An agent that investigates a problem and drafts a fix is a different risk class from one that applies the fix. Both may use the same model, the same tools, and the same data. Only one of them can be wrong in a way that persists after the run ends.

A gate a model can talk its way past does not function as a gate, because the same reasoning that makes an agent useful also makes it persuasive about its own work. A working gate runs in ordinary code, outside anything the model can influence, and leaves the run stopped whenever its condition is not met. Placement matters as much as existence. A gate before a plan is written costs little and catches little, while a gate immediately before an irreversible action is the one that changes outcomes.

An agent that retries, re-reads, and re-plans can spend far more on a hard task than on an easy one, and nothing inside the model tells it when to stop. Treat step caps, wall-clock limits, and daily ceilings as safety controls that happen to save money. Set them so that a runaway loop is caught by the cap long before it is caught by an invoice. A bounded loop also fails in a way you can reason about, since you know the worst case before you run it.

Every step an agent takes should leave a ledger row: what it did, what it touched, on whose authority, and when. An output sits there waiting to be read, so anyone can go back and check it. An action has already landed by the time anyone looks. The record has to be written as the run happens, rather than assembled afterward out of logs that were kept for other reasons.

Changing model provider is mostly a matter of credentials and prompt tuning. Changing orchestration framework means rewriting how tools are declared, how state moves between steps, and where the gates sit, which is the part you least want to rewrite under time pressure. Keep the pieces that carry your policy in code you own, including tool definitions, approval logic, and the ledger format, and let the framework handle the loop around them.

The scheme below is one defensible version for a generic organization, with the reasoning attached to each tier so you can argue with it and redraw it against your own classification.

Published material

Any model class may receive it, including consumer endpoints with the weakest retention terms, because the material is already outside your boundary and another copy of it in someone's logs costs you nothing. Agents may work on it without a gate, drafting, summarizing, and rewriting, since the worst outcome is wasted effort. Publication under the organization's name still needs a human gate, because that risk sits in the action rather than in the data.

Internal working material

Restrict it to model classes covered by a contract you have read, with retention, logging, and subprocessors named, and keep consumer endpoints out, because the cost of exposure here is embarrassment and there is no reason to accept it for free. Agents may read, reason, and draft against it without a gate, and may act on their own where the action stays inside the tier and can be undone, such as filing a ticket or editing a working document. Anything that carries the material out of the tier drops to recommend only with a human gate, because the tier boundary is exactly where the cost of a mistake changes shape.

Confidential material

Only model classes whose terms you have checked for the specific endpoint you are calling, with residency, retention, and each subprocessor in the path answered, and only where the contract or the regulation permits processing outside your own systems at all. Agents recommend here and do not execute, so every action that touches this tier waits on a human gate that fails closed and leaves a ledger row naming who approved it. The obligation attached to this data stays yours no matter which model handled it, and an answer you cannot reconstruct is the same as no answer when someone asks who authorized a specific action.

Material that stays inside the boundary

Only models you run inside the boundary, self-hosted or in a tenancy you control end to end, and no external endpoint regardless of how good its terms are, because this tier is defined by where the data may go rather than by what a counterparty promises about it. Agents read and recommend, and a human executes, since the tier exists precisely for material where a wrong action cannot be walked back. Where the existence of the material is itself sensitive, gate the retrieval as well as the action, because a query pattern leaks the same fact the content would.

The example does not settle the edges, and the edges are where classification schemes actually fail. Real material rarely arrives pre-tiered, so a mostly internal document with one customer name in it belongs to the higher tier under any rule you can write down, which is correct and also over-classifies enough that people start working around the scheme. Derived output is harder, since a summary of confidential material is usually still confidential while a count drawn from it usually is not, and an agent that accumulates context across a long run can end up holding a combination that sits a tier above anything it was given.

We operate a human-gated agentic framework against a live production service. The service is not named here, so the gate is set out precisely enough to be judged on its mechanics alone.

1. 01Execution advances only on an exact phrase match, and the comparison runs in ordinary code. Anything short of an exact match leaves the run stopped.
2. 02The phrase is re-read from the live project at the moment of the check. It is never carried forward from earlier in the run or trusted from the agent's memory of it.
3. 03Authorship is verified before the phrase counts. The approval has to come from a human account rather than a bot, and from a human with the authority to approve that action.
4. 04No model participates in the step. The check that decides whether to proceed contains no inference of any kind.
5. 05The gate fails closed. A missing phrase, an unreadable project, a failed verification, and a timeout all leave the run stopped.
6. 06Every step leaves a ledger row, including the steps that did not proceed. A refused approval is part of the record in the same way an accepted one is.

Assuming the flagship model is the safest choice.

Capability and data handling are separate questions, and a model earns the top of a lineup on reasoning quality alone. Retention, logging, and subprocessor terms can differ between models and between endpoints at the same vendor. Read the terms for the specific model and endpoint you are calling, then decide.

Treating "we do not train on your data" as if it meant the data never left.

It is a statement about one use of the data. The data still crossed your boundary, was processed on someone else's hardware, and may be retained for a period for abuse monitoring or support. Ask the other questions separately. Where did it go, how long does it stay, who can read it while it is there, and which subprocessors sit in the path?

Confusing a provider's stated region with actual data residency.

A named region tells you where inference runs. It does not by itself tell you where prompts are logged, where abuse-monitoring copies are held, what happens on failover, or which subprocessors sit outside the boundary. Residency is a property of the whole path, so ask about each hop rather than the endpoint alone.

Granting an agent tool access without mapping what that access reaches transitively.

Tool permissions get reviewed one tool at a time, and the risk lives in the combination. A read-only search tool over an internal wiki is harmless until the wiki holds a pasted credential. Draw the reach as a graph, follow each credential to what it opens, and review the union rather than the list.

Treating a model-evaluated approval as a gate.

Asking a model to judge whether an action is safe, or to confirm that a human approved it, puts the decision back inside the thing being controlled. Such a check will usually be right, and usually is a weaker standard than always. If the check can be influenced by text the agent produced or retrieved, treat it as a useful heuristic in front of the gate and put the gate itself in code.

Routing on cost alone and finding the quality floor the hard way.

Cheaper models handle a large share of routine work well. When they fail, they tend to fail quietly, returning a plausible answer in the same format and at the same speed as a correct one. Set the quality floor before you route on price. Send the cheap model the tasks where a wrong answer is cheap to catch, keep the expensive model where it is not, and re-check the split whenever either model changes.

• Vendor catalog. Every AI vendor and tool in use is recorded in one place, so the inventory is a list rather than an estimate.
• Tool approval. Each tool carries an approval decision, and the platform keeps that record. It does not sit in the path of live requests.
• Cost normalization. Vendor pricing is put on a common basis, so two tools priced in different units can still be compared.
• Redundancy detection. Overlapping tools are surfaced, so paying twice for the same capability shows up as a fact rather than a suspicion.

Routing decides which agent does the work, under whose authority, and with what record. It does not make the underlying model correct, and it does not tell you whether the work was worth doing at all. An agent that runs a badly chosen task under perfect governance is a governance success and a business failure, and only a person reading the output can tell the two apart.