TL;DR: The lowest-cost AI agent design is not the cheapest model, but the control logic that balances routing, retries, fallback, and escalation, according to Braintrust. The strongest policies resolved about 93% of tickets at lower cost per resolved request than the always-frontier baseline, while cheap-only strategies underperformed despite lower token spend.
At a glance
What this is: This is a Braintrust blog analysis showing that AI agent cost-efficiency comes from routing and escalation logic, not from swapping to a cheaper model.
Why it matters: It matters to IAM, NHI, and AI governance teams because agentic systems make runtime decisions about tools and escalation, which creates control, audit, and privilege boundaries that conventional static policy settings do not cover.
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
👉 Read Braintrust's analysis of agent cost-efficiency strategies and evaluation results
Context
AI agent cost-efficiency is not a simple token-price problem. Once a system can choose models, tools, retries, and fallback paths at runtime, the real control surface shifts from inference cost to control logic, safety gating, and the quality of escalation decisions. In that sense, the article is about how agent governance works when the model is only one component in a larger decision chain.
That matters for identity and access teams because agentic systems increasingly behave like software entities with delegated permissions and tool access. When those decisions are made dynamically, organisations need governance over the agent's runtime behaviour, not just over the model or the prompt template. The article's support-ticket benchmark is a compact proxy for broader agentic workflows, including copilots and coding assistants, and that pattern is already common in production environments.
The starting position is typical for emerging agent programmes: teams optimise the visible cost variable first, then discover that retries, human cleanup, safety failures, and tool misuse dominate the true bill. The stronger lesson is that runtime policy design is now part of security architecture, not just product tuning.
Key questions
Q: How should security teams govern AI agents that can change actions at runtime?
A: Security teams should govern runtime AI by correlating identity, data, and intent before trusting an action path. If the system can select tools or alter its sequence mid-session, a static access policy is not enough. The control objective becomes contextual verification of what the agent is doing, why it is doing it, and whether the data touched matches the approved purpose.
Q: Why do AI agents create new risk in non-human identity management?
A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.
Q: What do teams get wrong when they measure AI agent cost?
A: They often stop at token price, which hides retries, fallback calls, judge overhead, tool execution, and human cleanup. A policy can look cheap on the first pass and still be expensive once failures are counted. The better measure is cost per resolved request against a real quality bar.
Q: What should organisations do before giving agents broader tool access?
A: They should validate the control logic with evals that test unsupported claims, unsafe actions, and failed tool calls. If a policy cannot maintain output quality under failure conditions, broader tool access only increases blast radius. Scope should expand only after the escalation path is proven and observable.
Technical breakdown
Control logic is the real cost layer in agentic systems
In agentic workflows, control logic is the set of runtime decisions that determines which model runs, whether tools are called, when retries happen, and when the system escalates or abstains. That layer matters because the first answer is rarely the full cost of an interaction. Each failed attempt can trigger more model calls, more tool execution, more human review, and more downstream cleanup. In practice, the cheapest initial completion can become the most expensive resolved outcome if the control layer is poorly designed.
Practical implication: evaluate agent cost on resolved outcomes, not raw token spend, and instrument every decision branch.
Routing and escalation outperform static model selection
Static model choice treats cost as a fixed property of the model, but agent workloads vary by risk, ambiguity, and tool dependency. Routing policies work better because they send easy cases down cheaper paths and reserve stronger models for failures or sensitive tasks. Escalation policies add a second layer of control by letting the system recover from uncertainty without overpaying on every request. That is why cost-control increasingly looks like policy design, not model replacement.
Practical implication: build tiered routing and escalation rules that reflect task risk, not a single global default model.
Evals expose unsupported claims and brittle tool behavior
Evals are the mechanism that reveals where a policy fails under real constraints. In tool-using agents, the most important failures are often not obvious hallucinations but unsupported claims after tool failure, incomplete coverage of required points, or unsafe actions that should have been blocked. Those failure modes matter because they directly change whether an agent outcome is production-safe. If you do not test the control layer against those conditions, you will optimise for apparent efficiency while missing the real operational risk.
Practical implication: include quality gates, safety gates, and tool-validity checks in every eval suite.
NHI Mgmt Group analysis
Agent cost governance is becoming a runtime control problem, not a model-selection problem. Once an agent can route, retry, and escalate based on context, the organisation is governing behaviour, not just output. That shifts accountability toward policy design, observability, and exception handling. For IAM and NHI teams, the lesson is that runtime authority needs the same scrutiny as static permissioning.
Cost per resolved request is the right economic unit for agent governance. Token spend underestimates the true cost of failure because retries, fallbacks, judge calls, and human cleanup all sit outside the initial completion. This is analogous to access governance that measures entitlement counts but ignores privilege abuse pathways. The control objective is not to be cheap at the prompt level, but to be efficient across the full workflow.
Policy-based escalation creates a clearer governance boundary for agentic systems. If routing decisions are explicit, auditable, and tied to risk thresholds, teams can separate low-risk automation from high-risk escalation paths. That aligns with NIST AI RMF GOVERN and MEASURE functions, because the decision to escalate becomes a governed control rather than an ad hoc fallback. Practitioners should treat escalation rules as part of the security model.
Dynamic tool use introduces a familiar identity problem in a new layer. When an agent chooses tools at runtime, it is effectively acting through delegated privileges that need lifecycle governance, scope limits, and logging. That makes the link to NHI security explicit, because the agent's effective identity is defined by what it can do, when it can do it, and how its actions are reviewed. Teams should manage agents as governed identities, not as clever prompts.
What this signals
Runtime policy is now part of the control plane for AI systems. As agents start choosing models and tools dynamically, the operational question becomes whether those choices are observable, reviewable, and bounded. That pushes organisations toward stronger policy-as-control thinking, especially where tool access resembles delegated identity. For practitioners, the relevant reference point is the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework.
Cost optimisation will increasingly surface hidden governance debt. Teams that chase cheaper inference without instrumenting retries, fallbacks, and unsafe action handling will discover that their least-expensive policy is also their least governed. The NHI Lifecycle Management Guide is relevant here because runtime agent behaviour depends on lifecycle controls for the credentials and tools it can touch.
Cost-efficiency and security are converging on the same question: what authority did the system exercise, and under what conditions? That framing will matter more as agentic systems move from pilots into operational workflows. If the answer is unclear, the programme is not ready for scale.
For practitioners
- Implement cost-per-resolved-request reporting Track total spend against resolved outcomes, including retries, fallbacks, tool calls, and human interventions. Use that metric instead of token cost to decide whether a policy is genuinely efficient.
- Instrument escalation and fallback paths Log every branch decision in the agent workflow so you can see when the system escalates, retries, or abstains. That visibility is essential for tuning control logic and for auditing safety-related decisions.
- Add quality and safety gates to evals Require tool correctness, no unsupported claims, complete key-point coverage, and safe action handling before a run counts as resolved. Without those gates, cheap policies will look better than they are.
- Separate low-risk routing from high-risk escalation Use explicit rules or policies to send ambiguous or sensitive cases to stronger models while keeping routine cases on cheaper paths. That keeps the control boundary visible and easier to govern.
- Review agent permissions alongside model policy Treat tool access, escalation rights, and repair prompts as part of the same governance layer. If an agent can trigger actions or call tools, its effective privilege scope needs review and documentation.
Key takeaways
- AI agent efficiency is governed by control logic, not by model price alone.
- Resolved outcomes are the correct basis for comparing routing, escalation, and retry strategies.
- Agentic systems need auditable runtime boundaries because delegated tool use creates identity-like governance risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST AI 600-1, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | The article is about agent routing, escalation, and tool use in runtime policies. | |
| NIST AI RMF | MEASURE | The post centers on evals and measured cost per resolved request. |
| NIST AI 600-1 | The article concerns generative AI control logic and operational evaluation. | |
| NIST CSF 2.0 | PR.AC-4 | Runtime agent access and tool selection are access-control problems. |
| NIST Zero Trust (SP 800-207) | The article reflects zero-trust style continuous verification of agent actions. |
Map agent routing and escalation paths to OWASP agentic controls for tool use, safety, and policy boundaries.
Key terms
- Control Logic: The runtime decision layer that determines how an AI agent behaves. It includes model selection, tool calls, retries, fallbacks, and escalation rules. In practice, control logic is where cost, safety, and reliability are actually governed, not just where outputs are generated.
- Cost Per Resolved Request: A measure of how much it costs to complete a task successfully, not merely to generate a response. It includes retries, fallback runs, safety checks, and human cleanup, which makes it a better operational metric than token cost for agentic systems.
- Escalation policy: A rule set that determines what happens when an alert is not acknowledged or resolved in time. It defines priority, notification order, and fallback responders, making it a governance mechanism as much as an operational one because it shapes accountability during incidents.
- Runtime Delegation: The process by which an identity is allowed to choose actions, tools, or next steps while a task is in progress. In AI agent environments, runtime delegation is risky when it is broad, opaque, or disconnected from explicit policy, because the resulting behaviour may exceed the original intent.
What's in the full article
Braintrust's full blog covers the operational detail this post intentionally leaves for the source:
- Policy-by-policy comparison of model routing, retries, and fallback behaviour across the test set
- Per-policy cost-per-ticket and cost-per-resolved-request breakdowns for each control strategy
- Workflow logging and evaluation setup used to score tool correctness, safety, and completeness
- Loop-based frontier analysis showing where each policy sits on the cost and quality curve
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners designing runtime controls. It helps identity and security teams translate governance requirements into operational boundaries.
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org