Five decisions an AI agent's model should never make. Give it everything else
Taxbit, Okta, AWS and a Microsoft reference architecture converge: the model proposes, deterministic systems decide identity, thresholds, amounts, order and the record.
Listen to this article · 4 min
AI-generated narration of the full article.
Design reviews of AI agents tend to argue about the wrong thing. Teams debate which model is accurate enough, as if accuracy were the control. In the production designs published over the past few weeks, accuracy is not what keeps the agent safe. What keeps it safe is a short list of decisions the model is never allowed to make.
That list is converging. Here is our version of it, and it is a view rather than a fact: five decisions that belong to deterministic systems, with the model free to do everything else.
The five
| Decided by | Example from production designs | |
|---|---|---|
| 1. Whose authority is used | The authenticated session, bound in code | Taxbit binds identity into tools before the model runs |
| 2. Whether an output is good enough to act on | A rule with a threshold | Microsoft's pattern: a rule decides if a diagnosis is specific enough to book |
| 3. How much | Limits and approvals in the system of record | Payments only through approved limits and a finance adapter |
| 4. In what order | A defined workflow | Step Functions runs the steps; the agent picks the moment |
| 5. What the record is | The system that executes, with references | Evidence linked by work-item and correlation IDs |
1. Whose authority it uses
The model may decide to open a ticket. It must not decide whose account the ticket belongs to. Taxbit’s production assistant binds the user’s identity into every tool from the calling service, so there is no parameter the model could fill with someone else’s ID. Okta and AWS go further across applications: each token names both the user and the agent, and only an administrator decides which agent may act for whom.
Review question: does any tool schema let the model supply a user, tenant or account identifier?
2. Whether its own output is good enough
A Microsoft reference architecture published on November 7 puts this plainly: model confidence is not a calibrated probability and is not business authorization. In its housing-maintenance example, a rule, not the model, decides whether a repair diagnosis is specific enough to book a contractor.
Review question: where the agent acts automatically, what deterministic check decides that the input is complete enough, and does it fail closed?
3. How much
Amounts are where errors become expensive. In the same architecture, payments flow only through approved limits, approvals and an adapter to the finance system; the model never authorizes a payment. The model can propose a refund of a certain value. The limit belongs to the system that owns the money.
Review question: for every action with a quantity, where is the maximum enforced, and can the model see or change it?
4. In what order
Procedures have an order for reasons someone once had to defend: eligibility before approval, approval before payment. We showed how AWS lets agents start Step Functions workflows while the workflow keeps the steps. The agent chooses when; the workflow decides what follows what.
Review question: is any regulated or approved procedure being reassembled by the model from individual API calls?
5. What the record is
When something goes wrong, the record must come from the system that executed the action, not from the model’s account of it. Microsoft’s design links evidence through work-item references and correlation IDs instead of copying prompts and photos into logs. That is the principle we called proof from outside the model.
Review question: if an auditor asks why an action happened, can you answer without reading the conversation?
What the model keeps
This is not a case for weak agents. Everything else stays with the model: understanding the request, choosing which tool and which workflow, gathering evidence, drafting, explaining, and proposing an action with its reasons. That is most of the value.
The pattern refines a thesis we have held since October: reasoning is becoming portable, the authority to commit is not. What the last few weeks add is a sharper boundary. Authority is not one decision but five, and each has a natural owner outside the model. A design review that checks those five will catch more real risk than one that compares benchmark scores.