Escalate to a stronger model when the task presents a diagnosed capability gap, a different model is a plausible remedy, and the result can be checked against the same acceptance criteria. Escalate to a person when the missing ingredient is authority, a disputed objective, or an unacceptable consequence. Gather evidence or repair the tool when those are the actual blockers.
For digital and IT leaders, the policy should specify what triggers review of a model choice, what evidence travels with the task, and when work must stop. The framework here adapts AMF’s internal execution-policy ideas. It is proposed operating guidance, not an experimentally validated routing algorithm.
Define stronger in relation to the task
“Stronger” should mean a candidate with a reason to perform better on the required work: resolving interacting constraints, interpreting a long context, planning tool use, or diagnosing a failure. A larger price tag, a confident answer, or a general benchmark position is not sufficient task evidence.
Before routing, state the task’s acceptance test and the cost of a wrong result. Distinguish a reversible draft from an action that affects another person or system. One task may warrant inexpensive preparation and more demanding review; another may need a person to define the objective before any model proceeds.
AMF’s internal policy separates mechanical work, ordinary implementation, and consequential judgment or review. It also separates requested model routing from observed execution. These categories organize responsibility; they do not establish measured quality differences between models. This article deliberately does not turn internal role names into a public model ranking.
Diagnose the reason before changing the model
The following signals should trigger examination, not automatic escalation. Each row pairs a diagnostic question with AMF’s proposed next step.
| Signal | What to examine and next step |
|---|---|
| Interacting constraints or task complexity | Does the task require coordinating decisions across components? Next step: Consider a more capable reasoning model with the constraints and acceptance criteria intact. |
| Uncertainty or ambiguous instructions | Are there competing interpretations, or is a necessary owner decision missing? Next step: Ask for a decision when objectives conflict; otherwise make the ambiguity explicit for the candidate model. |
| High error cost | Could a mistake cause consequential or difficult-to-reverse effects? Next step: Increase review and restrict authority; stronger reasoning does not remove approval requirements. |
| Context requirements | Is necessary evidence absent, irrelevant, stale, or outside what the model can use? Next step: Repair the evidence package first; consider another model only when context handling remains the issue. |
| Tool-use difficulty | Is the problem planning calls, misunderstanding an interface, access denial, or a failing service? Next step: Escalate planning difficulty; repair interfaces or obtain authorized access for infrastructure problems. |
| Failed validation | Which criterion failed, and what does the failure reveal? Next step: Supply the exact failure and a new hypothesis rather than requesting another unbounded attempt. |
| Repeated rework | Are distinct approaches failing, or is the same mistake recurring without new information? Next step: Stop the loop and request a diagnostic review or human decision. |
Suppose an agent cannot read a required source. A stronger model may produce a more convincing answer from the same incomplete record, but that does not resolve the missing evidence. A refused write request is another clear case: the permission boundary must remain in place after a model change.
Route, repair, or return the decision
Use a short decision sequence before paying for another attempt:
- Is the task authorized and its intended result clear? If not, return the specific decision to the owner. Do not ask a different model to invent it.
- Are the required facts and tools available? Obtain approved evidence or diagnose the tool failure. Record what cannot be accessed.
- Is the failure plausibly about capability? Name the missing capability and why another model is worth trying. Keep the task and criteria stable.
- Can the result be evaluated? Preserve an independent check, reference answer, test, or qualified reviewer. Agreement between two models alone is not the acceptance criterion.
- Is the bounded attempt worth its cost and delay? Set a budget and a stop point, including the work a person must perform to evaluate the result.
These are policy choices to adapt. There is no universal number of retries that makes escalation correct. For an ordinary reversible task, a team might permit an initial attempt and one materially different repair attempt before diagnostic escalation. That is an illustrative limit, not an AMF performance finding. A permission or consequential-risk issue should stop immediately.
An illustrative evidence-review task
Imagine an agent preparing a recommendation from several internal policy documents. A check finds that the cited passage does not support one conclusion. The first useful action is to locate the correct evidence or narrow the claim. If all required documents are available but their rules interact in a way the agent repeatedly misinterprets, a stronger reasoning model may be worth a bounded attempt.
Send that model the actual question, relevant document versions, disputed conclusion, failed check, and the acceptance rule. Do not send only a summary that says the previous model “struggled.” The next attempt should identify its support and unresolved conflicts so a reviewer can assess it.
If the documents disagree about who may approve the requested action, the model can describe the conflict. It cannot resolve the organization’s decision rights by sounding more certain. The owner must settle the ambiguity before action. This scenario is illustrative; no client or AMF trial outcome is claimed.
Automatic routing is a product behavior, not an acceptance decision
Amazon Bedrock’s prompt-routing documentation, inspected September 11, 2026, describes predicting response quality and selecting between models within a family. It also states that routing cannot adapt to application-specific performance data and may be suboptimal for specialized use cases. These are provider descriptions of a particular service, not AMF measurements or a comparison of routing products.
Our inference is that using a router does not eliminate the need to evaluate the selected output on your task. Request routing chooses where work goes; acceptance determines whether the result meets the requirement. Preserve both decisions in the record, including the actual model selected when available.
Do not reuse old pricing or feature lists to justify an escalation budget. Check current availability, data-handling requirements, and cost before implementation. This article makes no current price, latency, savings, or cross-provider capability claim.
What would make the policy an empirical claim?
A policy can be reasonable without having demonstrated an improvement. To test it, define a representative task set and compare the proposed routing policy with explicit alternatives, such as staying with the initial model or using the candidate model from the outset. Use the same available evidence and acceptance criteria, and record model/version and tool configuration.
Count failures, unresolved tasks, and human interventions alongside accepted outputs. Measure the whole workflow: initial attempts, routing, retries, validation, and review. Report task categories separately when the consequences or difficulty differ. Keep a held-out set for the final comparison so tuning the policy on familiar examples does not become the claimed evaluation.
This is a proposed evaluation design, not an experiment conducted for the article. NIST AI RMF 1.0’s discussion of validity and reliability calls for realistic test sets and documented methodology, and for human judgment in selecting context-appropriate metrics and thresholds. The organization must decide what failure is tolerable; the model cannot choose that standard on its behalf.
Next action
Review one recent failed or heavily revised task. Classify the blocker as capability, evidence, tool operation, or authority. Write the smallest next action that addresses that blocker and the check that would show it worked. Only then decide whether a stronger model belongs in the next attempt.
Provenance and limits
Prepared for Agent Model Fit with material Codex assistance in source inspection, policy synthesis, and drafting on September 11, 2026. It reuses the existing AMF escalation brief and internal execution policy; exact internal references are retained for editorial review. AWS documentation is a provider source; NIST supplies general evaluation guidance. The decision sequence, scenario, and evaluation design are recommendations, not measured routing outcomes. Human editorial review was completed by Cresencio on September 11, 2026.