Walk through any enterprise software conference today, and you will hear the same word repeated in every keynote, every breakout session, every vendor booth conversation: agents. AI agents that handle customer inquiries, process invoices, manage schedules, write code, and operate software on behalf of humans. The vision is seductive. The operational reality is considerably more complicated.
Neel Somani has spent time on the complicated part. A researcher and builder with a background spanning quantitative finance, formal methods, and machine learning systems, Somani has worked on agentic tooling at a depth that most people selling the agent vision have not. His perspective on where organizations are getting tripped up is grounded in the specifics of how these systems actually behave in production, and it is worth paying attention to.
The Gap Between the Demo and the Deployment
The gap between an impressive AI agent demo and a reliable AI agent deployment is wider than most organizations expect. Demos are curated. Deployments encounter reality.
Neel Somani describes the core issue as an authorization problem. When an agent is deployed into a real business environment, it is operating in a system that was not designed for it. The permissions model, the audit trail, the escalation procedures, and the rollback logic: none of these exist by default. They have to be built deliberately, and most organizations do not build them before deployment.
The consequences of that gap tend to surface slowly. An agent sends a communication that was not intended. It creates a record in a system that was not in scope. It chains together a sequence of individually reasonable actions that produces an outcome nobody intended. Each of these incidents is recoverable, usually, but only if the organization has the infrastructure to catch it quickly and the procedures to reverse it cleanly.
Without that infrastructure, the failures accumulate. And the cumulative effect of many small, undetected agentic errors in a production system is a problem that is very expensive to untangle.
What Neel Somani Actually Builds
To understand why Neel Somani's perspective on this differs from typical commentary, it helps to understand what he has actually built.
His work on adcock-agent and the web2mcp framework involves the unglamorous infrastructure that sits underneath agentic workflows: the interfaces that let models interact with real systems, the logging that captures what agents do, and the design patterns that make those interactions predictable and auditable. This is not the layer of the stack that gets featured in product announcements. It is the layer that determines whether a production deployment is trustworthy or fragile.
That background gives Somani a specific kind of credibility when he talks about what breaks. He is not extrapolating from first principles. He is describing patterns he has encountered in systems he has built.
The Permission Model Problem
The most common failure pattern Neel Somani identifies is what he calls the permission model problem. Organizations deploy agents with a detailed prompt that specifies the task, the tone, and the general intent. Then they discover that a prompt is not a permission model.
A permission model is a formal specification of what an agent can do, under what conditions, with what limits, and with what escalation path when it reaches the edge of its authorized scope. A prompt is an instruction. The two are related, but they are not the same thing, and conflating them is how organizations end up with agents making decisions that were never explicitly authorized.
The fix, according to Neel Somani, is straightforward in principle and requires real organizational work in practice. Before any agent is deployed, the organization needs a written answer to a set of specific questions: What can this agent do without human approval? What requires a checkpoint? What is categorically out of scope? And what happens when the agent encounters a situation that does not fit neatly into any of those categories?
These questions need to be answered by people who understand both the technology and the business context. They cannot be delegated entirely to the team building the agent, because that team may not have full visibility into the downstream systems that the agent can affect.
Who Is Accountable When the Agent Gets It Wrong?
One of the questions Neel Somani pushes organizations to answer early is the accountability question. When an AI agent makes a consequential mistake, who is responsible?
The intuitive answer is that it depends on the circumstances. The more useful answer, in Somani's view, is that accountability follows configuration. The humans who designed the agent's task, specified its scope, and approved its deployment are accountable for its behavior, in the same way that a manager is accountable for the actions of the team members they have authorized to act on the organization's behalf.
This framing has practical implications. It means every agent deployment needs a named human owner with real authority and real accountability, not a diffuse sense of shared responsibility spread across a team. It means that authorization decisions need to be documented before deployment, not reconstructed after an incident. And it means that the governance infrastructure for agentic AI needs to be treated as a first-class concern, not an afterthought.
Neel Somani notes that this is not a new problem. Organizations have managed the accountability challenges of delegated authority for as long as they have existed. What is new is that the delegate is now a software system that can act faster, at a greater scale, and with less predictable behavior than any human delegate. The governance frameworks need to account for those differences.
The Staffing Question Nobody Is Asking
Beyond the governance framework, Neel Somani raises a staffing question that most organizations in the early stages of agentic deployment are not yet confronting: who manages the agents?
The assumption built into most business cases for agentic AI is that the technology reduces headcount. The more accurate near-term picture is that it changes the headcount. Running agents in production requires people who can monitor system behavior, catch drift from the intended specification, update workflow configurations safely, and diagnose failures without necessarily having deep software engineering expertise.
This is a role that does not exist at most organizations today, and that will need to exist at most organizations within the next few years. Somani describes it as a workflow engineering function: a team that sits between the business units and the technology teams managing the underlying infrastructure, defining what agents should do. Building that function proactively, before the deployment has scaled beyond what informal oversight can handle, is one of the clearest markers of organizational readiness for the agent economy.
The Agent Economy Is Already Here
The agent economy is not coming. It is here. The organizations that will benefit most from it are not the ones moving fastest. They are the ones moving with the most deliberate attention to the governance, accountability, and operational infrastructure that makes agentic deployment trustworthy at scale.
Neel Somani's argument is not that organizations should slow down. It is that they should build the right things while they are moving. The permission model, the audit trail, the named ownership, the rollback procedures: none of these are obstacles to deployment. They are the infrastructure that makes deployment durable.
The companies that treat them as optional today will be building them reactively tomorrow, under circumstances that are considerably less forgiving.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
