The Short Answer
Governing agents at scale requires owning the infrastructure they run on. On ibl.ai you own all the code and the data, so every agent's permissions, tool calls, and outputs are logged in systems you control rather than a vendor's. The platform is model-agnostic and has no per-seat pricing, so you can deploy anywhere — and an agent working overnight is not another subscription.
The Agentic AI Summit at UC Berkeley drew more than 5,000 attendees on August 1–2, hosted by the university's Center for Responsible Decentralized Intelligence and co-led by Haas professor Christine Parlour.
Berkeley faculty including Sergey Levine, Ion Stoica, and Dawn Song shared the stage with Andrej Karpathy, OpenAI co-founder Wojciech Zaremba, Databricks CEO Ali Ghodsi, and Andrew Ng.
The scale is not the interesting part. The change in the questions is.
What actually changed in the enterprise conversation?
A year ago the recurring question at events like this was whether to adopt agents at all — a question about belief.
This year it was operational: how do you govern several hundred agents across dozens of departments? Who approves what an agent may touch? What happens when one writes to a system of record overnight and no human reviewed it?
That shift is a reliable maturity marker. Conferences stop being inspirational and become operational at exactly the point where the technology has shipped and the problems have become somebody's Tuesday.
It also reframes what the hard part is. Model capability is no longer the constraint for most enterprise workloads. Permission design is.
Why are so few organizations actually running agents at scale?
Because the gap between a working agent and a governed one is where most programmes stall.
Capgemini Research Institute's World Cloud Report in Financial Services 2026, published in November 2025 from a survey of 1,100 leaders across 14 markets, found that only 10% of financial institutions have deployed AI agents at scale. Eighty percent remain in ideation or pilot.
That distribution is not a story about model quality. Every one of those organizations can build an agent that works in a demo. What separates the 10% is whether they can answer the questions a risk committee asks before it goes live.
Namely: what may this agent read, what may it write, what happens when it is wrong, and can you show me the log.
What does governing agents at scale actually require?
Four things, none of which are model features:
Scoped permissions. An agent should hold the narrowest set of capabilities that lets it finish its job, defined centrally rather than per application. The useful question is not what the agent can do but what it can never do.
Sandboxed execution. Anything an agent runs — code, tool calls, retrieval — needs isolation, because the failure mode of an autonomous system is not a wrong answer but a wrong action taken quickly.
Prompt-injection defense. An agent that reads untrusted content is an agent that can be instructed by it. This is the security problem that has no clean analogue in earlier software.
Complete audit trails. No human witnessed the run, so the log is the only account of what happened. It has to be produced in a form a reviewer will accept, not reconstructed after an incident.
The pattern across all four: they are properties of the platform underneath the agents, not of the agents themselves. Buy them separately for each agent and you get forty inconsistent implementations, which is the same as none.
We covered the architectural side of this in Why AI Agent Infrastructure Matters More Than the Model You Choose.
Why does governance get harder when you do not own the stack?
Because every one of those four controls is exercised by whoever operates the platform.
If agents run in a vendor's cloud, your permission model is whatever their product exposes, your audit trail is whatever they choose to log, and your incident response begins with a support ticket.
That is workable for low-stakes automation and uncomfortable at 500 agents touching systems of record.
Owning the deployment inverts it. Permissions, isolation, and logging are configured by you and enforced in infrastructure you already secure, so an agent programme inherits the controls your organization has spent years building rather than substituting a vendor's.
There is a cost dimension too, and it is the one most agent programmes discover late. Per-seat licensing — roughly $30 per user per month for Microsoft Copilot, about $60 for ChatGPT Enterprise — prices a human sitting at a keyboard. An agent working overnight occupies no seat.
Charging per named user for autonomous work is the wrong unit, which we worked through in Enterprise AI with No Per-Seat Pricing and in the per-seat vs usage-based comparison.
What should you take from a conference like this?
Not the demos. The questions people asked between sessions.
"How do we govern 500 agents across 40 departments" is a question only asked by someone who already has agents in production and has discovered that the second hundred is harder than the first. That is a more useful signal about where the market actually is than any keynote.
The practical read: if your organization is still debating adoption, you are answering last year's question. If you are debating permissions, isolation, and audit, you are in the right conversation — and those are decided by where the agents run and who controls that.
For a deeper treatment of the operational side, see AI Agent Management: Running Agents at Scale and AI Agents vs Copilots, which covers why autonomy changes the infrastructure requirement rather than just the capability.