2026 Comparative Analysis: Model Routing Infrastructure for AI Agents — Applied Technology Index

Executive Summary

A model router selects an inference model for each request or agent step. The selection can be learned from prompt characteristics, derived from aggregate market behavior, or declared as deterministic policy. A fallback selects another endpoint after an error. An AI gateway can host either mechanism while also applying authentication, budgets, rate limits, logging, or provider controls. These terms describe different functions and should not be treated as synonyms.

This analysis compares five publicly documented approaches:

Amazon Bedrock intelligent prompt routing predicts response quality across a configured pair of models in the same model family. A response-quality-difference threshold determines when the router uses the alternative instead of its fallback model.
Microsoft Foundry model router uses a purpose-built trained router across a broad, policy-constrained model pool. Deployments expose Balanced, Cost, and Quality modes, model subsets, selected-model disclosure, and automatic failover.
OpenRouter Auto Router classifies the task and ranks eligible models using aggregate, anonymized trailing-seven-day spend share for that task type. Cost tiers, allowlists, exclusions, account restrictions, session affinity, fallbacks, and opt-in pipeline metadata further shape execution.
Cloudflare AI Gateway Dynamic Routing is a deterministic, versioned flow rather than a learned quality predictor. Conditions, percentage splits, rate limits, budget limits, model nodes, and fallbacks make the routing policy explicit and rollbackable.
Databricks Unity AI Gateway Smart Routing is a beta coding-agent feature that selects the lowest-cost model documented as capable of a task. Through Omnigent it can also select a coding harness, and its choice applies to main agents and subagents.

The principal finding is that routing quality cannot be evaluated independently of the agent trajectory. A router may reduce cost on one call yet increase total cost if a weaker selection causes retries, extra tool calls, larger histories, failed patches, or escalation later in the run. Conversely, always selecting the largest model can waste money on classification, retrieval formatting, or routine tool arguments without improving task completion.

Production evaluation should therefore measure at least two levels:

per request: selected model, router overhead, input and output tokens, latency, cache behavior, errors, and fallback attempts;
per trajectory: task success, tool-call correctness, retries, intervention rate, elapsed time, total cost, and consequences of failure.

The five systems also expose materially different control surfaces. AWS provides a narrow quality-threshold router within a model family. Microsoft provides a managed learned router with policy-selected subsets. OpenRouter provides market-derived cross-provider routing with detailed optional metadata. Cloudflare provides explicit policy graphs. Databricks extends routing from individual prompts to coding-agent and harness selection. The correct choice depends less on the word “smart” than on whether the system’s candidate set, objective, decision evidence, update policy, and failure semantics match the workload.

Key Findings

Learned routing, market-derived routing, and policy routing solve different problems. AWS and Microsoft estimate suitability from the request; OpenRouter uses task classification plus observed spend preferences; Cloudflare executes operator-authored rules; Databricks targets coding tasks and can also route harnesses through Omnigent.
Model selection and failover are separate decisions. Quality routing asks which healthy model should receive the request. Failover asks what to try after an endpoint, provider, moderation, quota, or validation failure. A production gateway often needs both, but one does not prove the other.
Candidate-set governance is the strongest available safety control. Microsoft model subsets, OpenRouter allowlists and exclusions, AWS’s configured model pair, Cloudflare’s explicit model nodes, and Databricks permissions bound what the router can select. The router should optimize only inside an approved set.
A single endpoint does not guarantee stable behavior. Microsoft can update the active router’s underlying pool, OpenRouter’s market signal changes over a trailing window, and beta services can change availability or APIs. Stable client code can conceal a changing execution distribution.
Agent steps are not independent prompts. Tool definitions, prior messages, cache affinity, generated artifacts, and subagent choices affect later steps. Microsoft documents analysis of system messages, tool definitions, and conversation history; OpenRouter uses session-aware model and provider preference; Databricks applies routing to subagents as well as the main coding agent.
Context compatibility must be enforced before optimization. Microsoft documents that the effective router context limit is constrained by the smallest underlying model unless a subset narrows the pool. OpenRouter applies capability and modality filters. Deterministic routes must encode equivalent constraints themselves.
Cost mode is not a cost ceiling. OpenRouter describes cost_tier as a band, not a maximum. Microsoft’s Cost mode is an optimization preference. Hard spend limits require separate price filters, budgets, quotas, or policy nodes.
Observability must identify the actual model. Microsoft and OpenRouter include the selected model in responses. Cloudflare adds model and provider headers. AWS returns information about the selected model. Without this evidence, teams cannot reproduce regressions or attribute cost and latency.
Cache economics can change under routing. Microsoft notes that prompt caching depends on the selected underlying model and repeat affinity. OpenRouter prefers the same model and provider for an identified session when it remains a leading candidate. Frequent switching can erase savings that a per-token routing estimate predicted.
Routing must be evaluated on private workloads. Published objectives and provider benchmarks do not establish performance for an organization’s prompts, tools, languages, data, safety rules, or failure costs.

Methodology

The public Applied Technology Index research index and local public research collection were checked before topic selection. Existing ATI research covered agent harnesses, caching, observability, runtime policy, durable execution, credentials, memory, sandboxes, delegation, and tool gateways. It did not provide a dedicated comparison of the model-selection control plane now appearing inside AI gateways and agent runtimes.

Current public release discussion was used only to identify the research question. Claims in this article are grounded in primary technical documentation available on 23 August 2026: Amazon Bedrock’s intelligent prompt-routing guide and API reference; Microsoft Foundry’s model-router concepts, architecture, and deployment guides; OpenRouter’s Auto Router, router-metadata, and fallback documentation; Cloudflare AI Gateway’s Dynamic Routing and usage documentation; and Databricks Unity AI Gateway’s Smart Routing guide.

Each approach was assessed on ten criteria:

Decision mechanism: trained quality predictor, task classification plus market signal, deterministic rule graph, or coding-task capability selection.
Candidate scope: model family, managed cross-provider pool, account-filtered marketplace, configured nodes, or governed model services and harnesses.
Objective control: quality threshold, cost-quality mode, cost band, explicit condition, quota, budget, or lowest-capable-model target.
Constraint surface: allowlists, subsets, exclusions, access policy, region, modality, tool support, context, rate, and budget.
Conversation behavior: whether model choice is stateless, session-aware, or applied to each agent and subagent task.
Failure behavior: fallback baseline, ordered model retries, automatic failover, route branches, or documented permission failure.
Decision transparency: selected-model field, headers, route version, task classification, attempts, pipeline stages, or other audit evidence.
Change management: pinned configuration, in-place pool changes, trailing market windows, versioned routes, preview flags, and rollback.
Agent suitability: tool use, structured outputs, subagents, coding harnesses, cache affinity, and long-trajectory implications.
Operational completeness: evaluation, monitoring, privacy, cost attribution, recovery, and governance gaps.

This is a documented-capability and architecture comparison. No common prompt corpus, agent harness, tool suite, quality grader, latency test, cost simulation, cache experiment, failure-injection suite, or compliance audit was run across all five products. Provider descriptions of “quality,” “best,” “capable,” and “minimal overhead” are recorded as documented design claims, not independently verified performance findings.

Comparative Analysis Table

Approach	Routing mechanism and scope	Control and failure behavior	Decision evidence	Best fit	Main limitation
Amazon Bedrock intelligent prompt routing	Predicts response quality for models within the same family; configured routers use exactly two models, one designated as fallback	Operator sets a response-quality-difference criterion; the alternative is selected when predicted improvement clears the threshold, otherwise the fallback baseline is used	Response identifies the model used and routing criteria; router is an AWS resource with an ARN and APIs	AWS workloads wanting a narrow, managed quality-versus-cost decision between related models	English-only optimization is documented; no adaptation to application-specific performance data; narrow pair and same-family design is not a general cross-provider gateway
Microsoft Foundry model router	Purpose-built trained router analyzes system message, user message, tool definitions, and history; routes across an eligible multi-provider pool	Balanced, Cost, or Quality mode; policy-governed model subset; data-zone constraints; automatic failover inside the allowed set	Selected model appears in the response; Azure Monitor can expose distribution; date-stamped router versions and deployment settings	Diverse enterprise and agent workloads wanting one managed deployment, broad model choice, governance, and automatic lifecycle updates	Managed objective and in-place pool evolution reduce reproducibility; effective capabilities and context are constrained by the eligible subset
OpenRouter Auto Router	Classifies task type and ranks models by aggregate anonymized trailing-seven-day spend share for that task, then filters for capabilities and policy	Cost tier, allowed and excluded models, account restrictions, provider policy, ZDR rules, modality, fallbacks, and graceful default behavior if classification or rankings are unavailable	Response model; optional router metadata includes strategy, task type, candidates, attempts, region, provider, and material pipeline stages	Cross-provider applications wanting rapid adaptation to market usage, broad catalog access, and inspectable gateway behavior	Spend share is preference evidence, not a private-workload quality score; candidate and behavior changes can occur without application release
Cloudflare AI Gateway Dynamic Routing	Operator-authored, named, versioned flow with conditions and percentage branches rather than learned quality prediction	Request/body/header/metadata conditions, model nodes, rate and budget limits, fallbacks, A/B splits, deploy, and rollback	Route version plus `cf-aig-model` and `cf-aig-provider` response headers	Teams needing explainable segmentation, quotas, staged rollouts, and non-technical policy editing	Operator must design quality logic; dynamic routes currently require the compatible chat endpoint and are not available through the documented REST API
Databricks Unity AI Gateway Smart Routing	Beta coding-agent router selects the lowest-cost model documented as capable of each task; Omnigent can select both model and coding harness	Restricted to `system.ai` model services; user needs access to every candidate; `ucode` routes within a harness while Omnigent can route harnesses and subagents	Gateway and agent workflow expose the routed execution, but public documentation provides less general-purpose decision metadata than the gateway-focused products	Governed enterprise coding-agent fleets seeking per-task model and harness optimization	Beta, account-enabled, coding-specific, restricted to supported system model services, and dependent on Omnigent or `ucode` execution paths

Observed Profiles

Amazon Bedrock: a quality threshold anchored to a fallback model

Amazon Bedrock intelligent prompt routing is the most bounded learned design in this comparison. The service predicts the response quality of each specified model and selects between models in the same family. A configured router requires a fallback model, one other candidate, and a responseQualityDifference criterion.

The fallback label can be misunderstood. In this design it is not described merely as an error-recovery endpoint. It is the baseline model used when the predicted quality difference does not justify switching. The operator chooses how much predicted improvement the other model must offer before the router moves away from that anchor.

This makes the control surface comparatively legible. A team can choose a lower-cost baseline and escalate when predicted quality warrants it, or choose a stronger baseline and permit a cheaper model when expected quality remains close enough. The router is a managed Bedrock resource, created through console, CLI, or API and addressed by an ARN during inference.

The narrow scope is also the primary constraint. AWS documentation states that configured routers use exactly two models in the same family. The guide further states that intelligent prompt routing is optimized only for English prompts, cannot adjust decisions from application-specific performance data, and may not be optimal for specialized use cases because effectiveness depends on its training data.

Those caveats argue for workload-specific shadow evaluation. Record the selected model, predicted-policy configuration, task outcome, cost, and language. If a specialized workload consistently disagrees with the router, the application needs a different candidate pair, threshold, deterministic pre-route, or direct deployment.

Microsoft Foundry: a managed learned router with enterprise candidate governance

Microsoft Foundry model router presents itself as a deployable model, but the router is a lightweight, purpose-built selection model rather than the final answer model. It analyzes the full request, including system and user messages, tool definitions, and conversation history, then selects an eligible underlying LLM.

Its three modes expose a high-level objective. Balanced mode considers models within a narrow predicted-quality range and chooses the cost-effective option. Cost mode tolerates a wider quality band. Quality mode selects the highest-rated model without considering cost. These are optimization modes, not contractual task-success or budget guarantees.

The model-subset feature is the critical governance boundary. Teams can restrict routing to approved models for cost, compliance, region, capability, or procurement reasons. Microsoft documents that newly introduced models are excluded from a custom subset until explicitly added. Azure Policy can also govern which publishers and models are deployable.

Model lifecycle behavior requires careful reading. The active 2025-11-18 router version is updated in place as supported models and features are added, while earlier versions are frozen. Auto-update can move a deployment to a future router version. This reduces application maintenance but means the same deployment label can produce a changing model distribution. Regulated or regression-sensitive workloads should maintain a fixed subset, archive evaluation sets, monitor routing distributions, and gate changes.

Microsoft discloses the actual selected model in the API response and documents Azure Monitor as a way to inspect traffic distribution. It also provides automatic failover. The failover pool remains bounded by the configured subset, so resilience does not silently require sending a prompt to an unapproved model when the subset is correctly defined.

Several compatibility constraints matter for agents. The effective context window defaults to the smallest underlying model, and larger requests can fail unless the subset contains compatible candidates. Routing decisions for image-enabled requests are based on text input, and audio is not supported by the documented router. Prompt caching works only when the selected model supports it and repeated requests land on a compatible model. Tool-heavy agents should therefore evaluate schema support, context, modality, caching, and structured-output behavior across every candidate—not only answer quality.

OpenRouter: task classification plus a live market-allocation signal

OpenRouter Auto Router uses a materially different signal from a conventional quality predictor. It classifies the prompt into a task type and ranks models using the aggregate, anonymized share of spend observed for that task over a trailing seven-day window. The premise is that real purchasing behavior reveals which models developers currently prefer for comparable work.

This approach can adapt quickly when market usage moves to a new model. It does not require the operator to benchmark and curate the entire catalog before the first request. It is also not equivalent to evidence that the selected model maximizes accuracy for a particular private workload. Spend share can reflect price, availability, fashion, ecosystem defaults, or workloads unlike the buyer’s own.

The router filters rankings through model capability and operator constraints. Per-request settings can allow or exclude model patterns. Account policy, provider restrictions, zero-data-retention rules, output modality, tool support, and cost tier further shape the surviving set. If restrictions remove every candidate, the request fails rather than violating the declared set.

cost_tier is explicitly a market band, not a hard ceiling. It can exclude models below as well as above the selected band. A separate maximum-price filter is needed to enforce a price cap. This distinction is important for agents because one unexpectedly expensive step can dominate a long run even if average routing is economical.

Auto Router is session-aware. It ranks candidates on each turn but prefers the previously selected model when that model remains among the leading choices, and it can keep a session on the same provider. This supports conversational coherence and prompt-cache reuse without permanently pinning a conversation after its task changes.

OpenRouter provides unusually detailed opt-in decision evidence. Router metadata can identify the requested alias, routing strategy, region, selected endpoint, attempts, provider, task type, and material pipeline stages such as context compression or guardrails. This evidence should be persisted alongside trajectory traces. It allows an operator to distinguish a model-quality regression from a provider failover, context rewrite, moderation stage, or changed task classification.

OpenRouter’s ordered model fallbacks remain separate from Auto Router. Errors such as downtime, rate limits, moderation refusals, and context validation can trigger another model. Because a fallback may differ in context, safety, tools, and output behavior, the agent should validate the final model field and treat retries of consequential tool-producing steps with particular care.

Cloudflare AI Gateway: deterministic, versioned routing policy

Cloudflare Dynamic Routing is not documented as a model-quality predictor. It is a named, versioned flow composed from nodes. Conditions can inspect request body, headers, or custom metadata; percentage nodes support experiments; model nodes invoke providers; rate and budget nodes enforce quotas and switch to fallback branches; and a route can be deployed or rolled back without changing application code.

This is the most explainable approach in the comparison. A route can encode rules such as sending paid accounts to one model, capping a project’s daily spend, assigning a percentage to a candidate model, or selecting a region-specific provider from trusted metadata. The policy is visible before execution rather than inferred from a managed objective.

The tradeoff is that the operator owns the routing intelligence. Cloudflare’s flow can express “if plan is paid, use model A”; it does not by itself establish that model A will perform better on a difficult debugging task. Quality-aware routing must come from an upstream classifier, explicit task metadata, evaluation-derived rules, or a model node that the application has already selected.

Versioning and rollback make Dynamic Routing useful for controlled experiments. A team can deploy a candidate route, compare task-level metrics against a prior version, and revert without shipping application code. Percentage routing should still be keyed or sticky when a multi-turn agent requires consistency; purely random per-request assignment can mix models inside one trajectory and make attribution difficult.

Cloudflare returns the actual model and provider through cf-aig-model and cf-aig-provider headers. Those headers should enter the agent trace with the route name and version. The documentation also notes a current interface caveat: dynamic routes use the OpenAI-compatible chat-completions endpoint even though that endpoint is deprecated for ordinary single-model chat, and Dynamic Routing is not currently available on the documented REST API.

Databricks Unity AI Gateway: model and harness routing for coding agents

Databricks Smart Routing extends the routing question beyond which model answers a prompt. Its public beta documentation says Unity AI Gateway selects the lowest-cost model capable of each coding task. Through Omnigent version 0.8.0 or later, it can also select the coding harness. The choice applies to the main agent and each subagent launched in the session.

Harness routing is a meaningful architectural shift. Claude Code and Codex can present different tools, context construction, planning behavior, filesystem semantics, and subagent strategies around the same underlying model. Selecting a model without accounting for the harness can therefore optimize only one part of coding-agent performance.

The feature is deliberately constrained. Smart Routing is enabled per account, chooses only among system.ai-prefixed model services, and requires the user to have EXECUTE access to every candidate model. Missing access causes an explicit error naming the required services. Custom model services are not currently candidates.

Execution path also determines capability. ucode can route models within the selected harness. Routing across harnesses requires Omnigent. Native Claude Code or Codex launched outside ucode do not receive Unity AI Gateway Smart Routing through this mechanism, and interactive root sessions have documented invocation constraints.

This system is publication-worthy because it treats the unit of optimization as a coding task and, in its fuller form, the model-harness pair. It is not yet a general-purpose inference router. The beta status, restricted candidate set, and narrower public decision metadata mean buyers should retain per-task model, harness, subagent, cost, patch, test, and intervention records before accepting claimed savings.

Router Architecture Analysis

Quality routing versus availability fallback

A quality router chooses among candidates expected to succeed. A fallback responds to failure. Combining them without separate telemetry hides two different events.

For every agent step, record:

the candidates eligible before execution;
the objective or route version;
the primary selection;
every attempted model and provider;
the error or policy reason for each retry;
the model that returned the accepted result;
whether the result led to a valid tool call or completed task.

An answer from a fallback is not necessarily interchangeable with the primary model’s answer. It may have different context limits, tool syntax, safety policy, deterministic behavior, or cache state. Consequential actions should pass the same output validation and authorization regardless of which model produced them.

Per-call savings versus trajectory economics

The correct economic unit for an agent is usually the completed task, not the token. A weaker model can be cheaper per call while increasing retries, tool failures, context growth, and human intervention. A stronger model can cost more per call while shortening the trajectory.

A routing experiment should calculate:

total inference cost per completed task;
successful tasks per fixed budget;
elapsed time and tail latency per task;
tool-call validity and first-attempt success;
retry, escalation, and fallback rates;
human minutes required for correction;
cost of failed or unsafe side effects.

Do not promote a router because its average selected-model price fell. Promote it when end-to-end outcomes improve inside predefined quality and safety bounds.

Candidate sets as policy boundaries

A router should never discover compliance through trial and error. The host must determine eligibility before optimization.

Candidate policy should include:

approved provider and model versions;
data residency and retention terms;
input and output modalities;
context and structured-output requirements;
tool-calling and parallel-call compatibility;
safety and content-filter requirements;
maximum unit price and task budget;
availability tier, region, and quota;
licensing or customer-contract restrictions;
known workload-specific failure exclusions.

The learned or dynamic optimizer can then select inside that set. Microsoft subsets and policy, OpenRouter restrictions, AWS’s explicit pair, Cloudflare’s configured nodes, and Databricks model-service permissions all support this pattern at different layers.

Routing state, caching, and conversation coherence

Stateless routing is attractive for independent requests but can be harmful for multi-turn agents. Switching models can change interpretation of hidden assumptions, formatting habits, tool schemas, or prior assistant messages. It can also move a request away from a provider-side prompt cache.

Use an explicit trajectory or session identifier. Preserve model affinity while the selected model remains suitable, but permit escalation when the task changes or evaluation detects failure. Measure cache-read tokens and provider affinity as part of routing economics rather than assuming every selected model begins from the same cost baseline.

Subagents need an explicit policy as well. A coding agent might reserve a high-capability model for planning and review while assigning search, test triage, or formatting to cheaper workers. Databricks applies Smart Routing to subagents; other systems can implement similar behavior through step metadata or separate routes. The parent should record which model produced each delegated result.

Change control and reproducibility

Managed routing intentionally changes behavior without requiring an application deployment. That is operationally convenient and scientifically dangerous if changes are invisible.

Treat the following as versioned production dependencies:

router product and version;
candidate model identifiers and provider endpoints;
objective mode, threshold, tier, or policy graph;
allowlists, exclusions, and access policies;
classifier or market-signal window where exposed;
cache and session-affinity settings;
fallback order;
guardrail and context-transformation pipeline;
evaluation set and acceptance thresholds.

Archive this configuration with each release and retain enough response metadata to reconstruct which backend handled an incident. When a managed pool updates in place, rerun a canary evaluation even if client code and endpoint names did not change.

Selection Framework

Choose Amazon Bedrock intelligent prompt routing when the application already uses Bedrock, a same-family pair is acceptable, and the organization wants a simple managed tradeoff around a known fallback model. Test non-English and specialized workloads separately, because the documented optimizer is English-focused and does not learn from application-specific outcomes.

Choose Microsoft Foundry model router when a broad managed model pool, enterprise policy, one deployment, automatic failover, and cost-quality modes are priorities. Use an explicit model subset, monitor selected-model distribution, and gate in-place pool changes with private evaluations.

Choose OpenRouter Auto Router when cross-provider breadth, rapid adaptation to market use, granular candidate restrictions, session affinity, and detailed optional routing metadata are valuable. Treat spend share as a discovery prior rather than final proof, and enforce hard price and compliance limits separately from cost tiers.

Choose Cloudflare Dynamic Routing when explainability, deterministic segmentation, budget and rate controls, A/B rollout, and instant rollback matter more than learned prompt-quality prediction. Derive route rules from evaluation evidence and keep multi-turn assignment stable enough for coherent analysis.

Choose Databricks Smart Routing when the workload is enterprise coding agents already governed through Unity AI Gateway, and optimization across model-harness combinations is desirable. Accept beta constraints, use Omnigent for harness routing, and evaluate whole coding tasks—including tests and interventions—not isolated prompt responses.

Before production selection, run every candidate against the same routing acceptance suite:

replay a representative private prompt and trajectory corpus;
include simple, complex, long-context, multilingual, multimodal, tool, and structured-output cases;
compare fixed-model baselines with every router objective mode;
record selected model, provider, route version, attempts, cache use, tokens, latency, and cost;
score task completion, tool correctness, retries, intervention, and unsafe outcomes;
remove or revoke one candidate and verify fail-closed behavior;
inject rate limits, provider errors, context overflow, moderation refusals, and malformed tool output;
change a candidate model version and measure regression detection;
test conversation affinity and deliberate mid-trajectory escalation;
prove that deletion, audit, and incident review cover routing metadata without unnecessarily retaining sensitive prompts.

The most defensible architecture uses policy before optimization, evaluation after selection, and trajectory-level accounting throughout. The router may be learned, market-derived, or deterministic; it should never be the unobserved authority over which model receives sensitive data or produces consequential actions.

Limitations

This analysis reflects public documentation available on 23 August 2026. Microsoft’s active model pool, OpenRouter’s market-derived rankings, Cloudflare route capabilities, AWS-supported models, and Databricks beta availability can change rapidly. Product labels and examples do not guarantee continued API, regional, or model support.

No equivalent workload was executed across the five systems. The article does not measure routing accuracy, answer quality, agent task completion, latency overhead, token savings, cache hit rate, provider availability, fallback correctness, multilingual performance, safety outcomes, or total cost.

The compared approaches are not strict substitutes. AWS offers a constrained same-family quality router. Microsoft offers a broad managed model router. OpenRouter combines marketplace routing and gateway controls. Cloudflare exposes a deterministic routing graph. Databricks targets governed coding agents and can route harnesses. Their objectives and abstraction layers differ.

Provider documentation does not fully disclose every training dataset, score calibration, ranking feature, classifier error rate, update process, or internal fallback condition. “Best,” “capable,” “quality,” and “minimal overhead” remain provider-defined unless validated with an independent workload and grader.

Costs were not normalized. Token prices vary by selected model, provider, region, cache state, routing product, gateway plan, discounts, and contract. A cost preference or mode is not necessarily a maximum spend guarantee.

Public documentation cannot establish data residency, retention, compliance, security, or contractual suitability for a specific deployment. Candidate eligibility can depend on account configuration, provider terms, model publisher, region, private networking, content filters, and customer obligations.

This article does not determine whether a selected model is safe to authorize an action. Model routing must remain separate from identity, authorization, human approval, sandboxing, output validation, and durable side-effect controls.