A year ago, the question in most of my customer conversations was whether an agent could do the work their businesses needed. That question is receding.
The new question is whether that work can run end-to-end instead of stalling partway through the workflow, how to find the ROI for early AI investments, and who is accountable when the agent acts. The pressure has shifted from having an AI story to having AI results, and most teams never architected their agents to produce results.
In those same conversations, the thing standing between a promising pilot and production is rarely the model. It’s authorization, compliance, and cost.
I know enterprise teams are under enormous pressure to prove ROI now, and in this context governance can sometimes feel like “brakes on a sports car,” as one exec put it. But with agentic AI, it’s closer to the opposite.
Governance is what lets the return show up at all.
The return lives in whole workflows
Connecting an agent to your systems is now table stakes. Your agent can read your email, pull a record, post a message. That’s useful, but the value is capped, because each of those is a single action against a single system. The agent does one thing, then hands the work back to a person who picks up everything that comes next. The gains stay incremental because the agent stops at the point where the real work starts.
The returns change when an agent takes on a whole workflow end-to-end. Not one tool call, but dozens, strung across every system the work actually touches.
Take onboarding a new enterprise customer. The agent reads the signed contract in Google Drive, creates the account and opportunity in Salesforce, opens the implementation epic and tickets in Jira, stands up the customer’s project space in Notion, and posts a kickoff summary to the account team in Slack. That’s dozens of actions across five systems.
And notice what the workflow doesn’t require. To onboard that customer, the agent needs to read account data in Salesforce and create new records, it never needs to delete them. A valuable and safe workflow defines a narrow set of permissions the agent needs to accomplish the job, and nothing more.

Complete workflows are where the math starts to work. It is also, and this is not a coincidence, the exact moment the governance questions arrive, because now the agent is acting, repeatedly, in the systems the business runs on, and every action is one a person will answer for.
Why your returns are stuck
The models are ready to act. The controls to let them act safely, and affordably, are not.
The evidence is piling up. Around 81% of teams have moved past planning into testing or live use, while only 14% report full security sign-off. The gap is not because of slow security teams. It’s because the controls were built for a different problem. Approval workflows and access reviews were designed for human employees working at human speed, and they check work after it happens.
An agent taking dozens of actions a second does not fit that model, which results in one of two scenarios.
- Security holds the line and potential ROI remains stuck in the gap, waiting.
- The line doesn’t hold and teams wire up their own connectors and personal tokens, putting agents into production on access no one can see, revoke, or audit. That’s shadow AI, which can feel like value unlock in the short-term but surfaces as risk later.
AI Agent Impact: one approval, dozens of agents at a top-five bank
A top-five bank set out to put a wealth management agent into production, and the whole rollout stalled on a single question: could the team guarantee that each user only ever saw their own account information? Security would not approve a custom auth build, and the project sat. Once that authorization was enforced at the runtime, security had one foundation to review instead of one agent to interrogate. The first agent took seven months to clear. After it, Arcade became the firm-wide standard and the approval stopped being the bottleneck: dozens of production agents now serve 30,000 users across eight teams, connected to more than 50 systems, with 95%+ of tool calls executing successfully. The first agent was the hard one. The hundredth shipped against the same foundation.
The mechanism under that promise is delegated authorization: the agent acts as the specific person behind it, authorized at the intersection of that user’s identity and the agent’s scope, so it can never reach past the person it is acting for. We covered how that works in depth in the previous post in this series. It’s what lets the bank promise each user would only ever see their own accounts, and what moves a security review from “we can’t prove this is safe” to approved.
Ungoverned agents burn money too
A breach isn’t the only harm an ungoverned agent can do to your business. There’s also the bill.
A poorly governed agent improvises. It retries, wanders, and calls tools it never needed, and every one of those steps is tokens. I wrote about this at length previously. What decides whether a task resolves in a few clean steps or turns into an open meter is the architecture of an agent, how tightly its tools and permissions are scoped and how clearly its job is defined.
Governance and good architecture are the same discipline viewed from two angles. One keeps the agent safe. The other keeps it from running up a tab.
AI Agent Governance In Action: the same eight queries, a 100x difference in the bill
Arcade’s State of MCP Tools research ran eight identical CRM queries through two Attio toolkits. One consumed 7,426 tokens. The other consumed 747,083, a 100x difference for the same work against the same data. At 100 agents running 200 queries a day, that gap is about $1.97 million a year in token costs at Claude Sonnet pricing. Researchers have a name for the broader pattern, the “unreliability tax”: the compute an agent burns retrying and calling the wrong tools when those tools are poorly defined. For unconstrained agents on complex workflows, it can reach $5 to $8 per task, counting every retry and wrong tool call along the way.
The flip side is where the real prize sits. Cost control goes deeper than just the tokens you don’t waste. A governed agent burns less and succeeds more, and every successful action is work that actually got done. Run the unreliability tax in reverse and the more an agent’s calls land the first time, the more value you pull from every token you spend. That reliability is what makes a workflow worth putting into production.
Approve the foundation once
So far, every new agent, use case, and tool has meant its own security review, and the queue only grows. The way out is to stop reviewing one at a time.
When authorization, policy, and audit are enforced at the one runtime every action passes through, security reviews and approves that foundation once. And it’s the same approval model no matter what changes downstream: a new agent, a new user behind it, a new tool it needs, a new system it connects to. None of them triggers a fresh bespoke review, because none of them changes how authorization, policy, and audit are enforced. They all inherit the foundation security already approved.
With Arcade.dev, the first agent and the hundredth ship the same way, against the same controls, with the same evidence trail. Approval becomes repeatable, which is the only kind of approval that scales.
This is what turns governance from a bottleneck into leverage. The work of proving an agent is safe to act, and cheap enough to run, stops being linear with the number of agents, tools, or systems in play. You do it well once, at the layer where every action lands, and the whole fleet inherits it.

Centralized oversight without centralized bottlenecks
Approving the runtime once holds up in practice because it serves both sides of a tension that I’ve seen pull organizations apart.
On one side, security leaders get what they have been asking for: one place to see what every agent is doing, one set of policies enforced on every action, and an audit trail they can hand an auditor.
At the same time, the teams building agents get to keep shipping. They are no longer waiting in a queue for a custom review of every use case, or for each new tool they want to connect to clear its own integration and sign-off. Both run against the foundation that security already approved. The oversight is centralized but the work isn’t. That combination is what lets an organization move past a handful of pilots without either giving up control or grinding to a halt.
It also settles the arguments about ownership that often come up. When every action is attributed to a real user and a specific agent, the question of who is accountable for an agent’s behavior has a clear answer, which tends to lower the temperature across the whole program.
What approving once actually changes
| When you have to review each time | When you approve the runtime once | |
|---|---|---|
| Security review | A bespoke review for each new agent, tool, and use case | One review of the foundation, inherited by every user and agent after it |
| Path to production | Each project stalls at the same security gate | Cleared against a pattern security has already approved |
| Spend | Each agent runs on whatever tools it was handed. Poorly defined tools guess and retry, with every misstep costing tokens | Every agent runs through the same vetted tools so you pay for the clean path once |
| Value | Agents stay stuck at drafts, summaries, and reads. The workflows that would actually pay off wait in the review queue. | New workflows clear fast against the approved foundation, so agents run end-to-end across systems and the full productivity return shows up. |
| Accountability | The question “Which agent did what, on whose behalf?” is impossible to answer | Every action is attributed to a real user and a specific agent, answering our “which agent did what, on whose behalf?” question |
| What scales | The review queue | The agents, the users behind them, the systems they can touch, and the value they return |
The real question: what would it take to run agents in production?
When a team asks me how to justify the work of governing agents, I turn it around. The question is not whether your agents can do the work. You’ve probably already seen that they can.
The question is, what would need to be true to put those agents into production and leave them there, doing whole workflows, at a cost you can defend? More often than not, the answer is governance, enforced where the action happens.
Get that right once, and the return you invested in finally has a way to show up.