--- title: "What 306 agents in production taught me about enterprise AI" description: "Leverge runs 306 agents across 13 functions. Where they cluster, why the process is the unit rather than the agent, and the rule that makes enterprises say yes." type: Essay url: https://sunilkumar.ai/writing/what-306-agents-in-production-taught-me-about-enterprise-ai/ author: Sunil Kumar (https://sunilkumar.ai/about/) datePublished: 2026-09-03 pillar: Architecture tags: [agentic-ai, production, approvals, orchestration, leverge] license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) --- # What 306 agents in production taught me about enterprise AI Leverge runs 306 agents across 13 functions. Where they cluster, why the process is the unit rather than the agent, and the rule that makes enterprises say yes. ## In short - Agents cluster where the work is high-volume, well-defined and lives in a system of record: sales, finance, procurement and customer service hold 235 of Leverge's 306 agents. Legal and IT hold two each, and that is not a mistake. - The agent is the wrong unit of design. The process is. 306 agents cover 93 processes, roughly three agents per process, each with its own tools and its own refusal list. Monolithic agents fail because they ask one model to be three. - One rule makes enterprises say yes: nothing irreversible happens without a named human approver. It costs some autonomy and buys the signature. - Six weeks from selection to monitored production is the honest number, and most of the six weeks is integration and approval, not model work. Leverge, the agent platform my team at Ailoitte built, runs 306 agents in production across 13 business functions. I do not say that as a boast. I say it because a catalogue that size is a dataset, and a dataset tells you things a single project cannot. This essay is what the catalogue has taught me about where agents actually work in an enterprise, how they should be cut, and what makes a buyer sign. ## Where the agents are The distribution is not even, and the unevenness is the first lesson. Sales has 113 agents. Finance has 43, procurement 40, customer service 39. Marketing and human resources have 20 each, billing 14. Then the tail: operations and documents with four each, healthcare with three, and legal, IT and real estate with two apiece. Four functions hold 235 of the 306. They share three properties. The work is high-volume, so a run that saves four minutes is worth automating. The work is well-defined, because it has been done the same way by the same role for years, often with a template. And the work lives in a system of record: a CRM, an ERP, a ticketing queue, a billing system. An agent that reads from and writes to a system of record has a place to stand. An agent that has to invent its own context every run does not. The tail is the more interesting half. Legal has two agents, not because legal work does not matter but because almost every legal action is irreversible or close to it, and an agent whose every step needs a signature is a form with extra steps. IT has two for a similar reason: the actions are cheap to take and expensive to undo. The catalogue is honest about this in a way that a slide deck never is. Agents go where the work is repetitive and the mistakes are recoverable. Where mistakes are not recoverable, the right design is a person with a very good assistant, and that is a different product. > **Named approver**: A specific person, not a role or a queue, who must approve any action an agent proposes that cannot be reversed by the agent itself, and whose approval is recorded in the run's trace. ## The process is the unit, not the agent The number I find most useful is not 306. It is 93. That is the number of distinct business processes the 306 agents cover, which means a process takes roughly three agents to run. This is not accidental. When we built the early agents as single, capable actors that could take a request from intake to outcome, they failed in a specific way: the same model was being asked to classify, to retrieve, to decide and to write, with one prompt and one set of tools, and the prompt grew until nobody could say what it did. Splitting the process into steps, each with its own agent, its own tools and its own refusal list, fixed more failures than any model upgrade did. The intake agent may read anything and may write nothing. The decision agent may write a recommendation and may call no external system. The action agent may call exactly one system and must stop at anything irreversible. Three small agents with narrow permissions are easier to test, easier to trace and easier to replace than one large one. They are also easier to price, because each step has a budget. When a client asks for "an agent for accounts payable", the first thing we do is draw the process and count the steps. The number of agents falls out of the drawing. ## The rule that makes enterprises say yes Every agent in the catalogue runs under the same rule: nothing irreversible happens without a named human approver. Not a role, not a queue, a person, recorded in the trace of that run. I resisted this rule for a while. It costs autonomy, and autonomy is what the demos sell. What changed my mind was watching who reads a proposal. The engineer reads the architecture. The CISO and the head of compliance read one sentence, and it is this one. If it is there, the conversation moves to scope and price. If it is not, the conversation ends politely and does not resume. The rule also does something for the design that I did not expect. Deciding which actions are irreversible forces you to list the actions at all, and the list is the refusal list by another name. Agents built under this rule have a written boundary from day one, because the boundary is what the approver is approving. That is why I now put the refusal list before the prompt on every project, whether or not the client asks for it. ## Publish the workflow Each agent ships with its runtime workflow published: the steps, the tools each step may call, the points at which a human is asked, the conditions under which the agent stops. A buyer can read it before they buy. A reviewer can read it during an audit. An engineer can read it when something goes wrong at two in the morning. Publishing the workflow was uncomfortable at first because it exposes how ordinary the agents are. That discomfort is the point. An agent that cannot be described in a page of steps is not ready to run in someone else's company, and an agent that can be described that plainly is much easier to trust. It is the same discipline as fixed pricing: if you can write down what "done" is, you can commit to it. If you cannot, you are selling hours. ## Six weeks is the honest number From selecting an agent in the catalogue to running it in production with quality metrics, the typical deployment takes about six weeks, in three stages. Select the agent or define the process. Configure the workflow and the guardrails, which means the refusal list, the approvers, the budget, and the connections to the systems of record. Deploy, and watch the metrics until the numbers hold. Almost none of the six weeks is spent on the model. It is spent on integration, on getting the right people to own the approvals, and on the evaluation set that decides whether the agent is good enough to leave on. Anyone who quotes two weeks for an enterprise deployment is quoting the first stage. Anyone who quotes six months is planning to rebuild your systems of record, which is a different project with a different price. The other honest number is the retirement rate. Some agents get switched off. The quality metrics say the process changed, or the volume never arrived, or a person turned out to be cheaper. A catalogue that never retires anything is not being measured. ## What this changes about the architecture If you take the four lessons together, an architecture falls out of them, and it is the one in my [reference architecture playbook](/playbooks/agentic-ai-reference-architecture-for-enterprise/). Small agents with narrow tools, composed into processes. A refusal list per agent, enforced at the tool layer. A named approver on every irreversible action, recorded in the trace. A published workflow that a person can read. A budget per step and a ceiling per month. It is not a novel architecture. It is a boring one, applied 306 times, and boring is the highest compliment I know for a system that runs in someone else's company. ## If you are doing this in your company Start with a process, not an agent. Draw the steps, mark which ones are irreversible, and count. That count is the number of agents you are actually building, and the irreversible steps are where your approvers go. Write the refusal list for each agent before the prompt. If you cannot say what an agent must never do, you cannot say what it may do either. Pick the first process from the high-volume, well-defined, system-of-record end of your business. Accounts payable before contract review. Ticket triage before incident response. The tail of the catalogue is a good guide to what to leave for later. And plan for six weeks, most of it on integration and ownership. If the model is where your time goes, you are building a demo. The catalogue itself is at [leverge.ai](https://leverge.ai/ai-agents), with the function counts and the deployment stages published, and the [vendor evaluation playbook](/playbooks/how-to-evaluate-an-agentic-ai-vendor/) has the questions to ask anyone who offers you an agent, including us. --- Sunil Kumar, Co-founder and CEO, Ailoitte Technologies. https://sunilkumar.ai/about/