Databricks State of AI Agents: what 327% multi-agent growth means

When one agent reads your data, the hard problem is retrieval. When several agents can change it, the hard problem is deciding which of them gets to be right.

The Databricks State of AI Agents report gives a sense of how fast companies are heading toward that second problem. Databricks says use of multi-agent systems on its own platform grew 327% in about four months of 2025, with its Supervisor Agent coordinating specialized agents. The direction is believable. The number needs its qualifiers attached before anyone puts it in a board deck.

What the 327% measures

It is a growth rate from vendor telemetry. The report is built from aggregated, anonymized data on how Databricks customers use its platform, and as a whole it draws on more than twenty thousand organizations worldwide. That population is one company's customer base. Companies on other platforms sit outside it.

The window is short and opens near a launch. The report says four months, and the landing page says less than four. Agent Bricks, the product whose usage the analysis examines, launched in June 2025, so the report's usage chart runs June through October 2025. Supervisor Agent, the type that builds systems of multiple agents, followed in July by the report's account. Databricks prints no exact start and end dates beside the 327%, and it doesn't say how many of those organizations used Agent Bricks.

Three things are missing. The report gives no base, so a reader can't tell whether the growth is in the hundreds of systems or the hundreds of thousands. The unit is unsettled: the methodology page says usage is measured by the number of active, engaged customers, while the chart beside the figure counts agents. And nothing separates systems that only read from systems that change records, which is the distinction my argument depends on.

A steep curve from a launch month is what a successful new product looks like, and this one succeeded on Databricks' own terms. Its blog summary calls Supervisor Agent the top agent use case, and the report puts it at more than a third of Agent Bricks usage in October 2025. Use is uneven, though. On the report's per-company chart for July through October 2025, technology companies build nearly four times more multi-agent systems than any other industry. A bank or a carrier should not read this curve as the pace of its peers.

The report's conclusion sits closer to my argument than its headline does. It names the challenge now as "how to effectively use agents with enterprise context." I agree. The question I would add is where in the system that context has to show up.

Why the bottleneck moves

A reading agent fails locally. It searches documents or queries a table and answers a person, and a wrong answer sits in a reply that someone can ignore. Spending on storage, retrieval and read permissions is the right response to that failure, and for a while it was the whole job.

A supervisor changes the shape of the work. The report describes it as orchestrating agents and tools to carry out complex tasks. Now one specialist's output is another specialist's input, and some of those outputs can be writes to records that other agents treat as fact.

Retrieval quality stops being the limit at that point. Every agent can read fresh, correctly permissioned data, every write can commit, and the result can still be wrong, because two sound local moves can add up to a decision nobody would have made. A database can tell you both writes succeeded. Whether both should have happened is outside its job.

Routing doesn't close that gap. A supervisor decides which worker gets which task and in what order. Whether the credit team's goal outranks the sales team's this quarter is a different kind of question, and the answer tends to live in an earlier decision or an exception someone granted last year.

Illustrative example (fictional): A supervisor receives a goal to reduce overdue receivables. A collections agent reads an aging table, flags a customer as overdue against standard terms, and lowers the customer's credit status. An order agent reads the new status and holds an open shipment. A notice agent writes to the customer. A forecasting agent sees the held shipment and trims next quarter's number. Every read was current and every write succeeded. The account manager agreed to extended terms for this customer last spring, and that agreement sits in an email thread no agent can see.

Nothing in the data layer failed. The company had no place where that exception, and the authority to override it, could reach the agent about to act.

The path a change should take

I use decision layer to mean whatever sits between an agent's intent and a system's state. Treat the five parts below as a design pattern for evaluating any multi-agent system, ours included. They describe no specific product's runtime.

Shared company context. A knowledge graph connecting records, relationships, human judgment, decisions and outcomes, which we call a context graph. This is where the extended terms and the person who granted them would sit, readable before the collections agent proposes anything.
Proposals in place of direct writes. A specialist states the target record, the before and after, its evidence, and the upstream outputs it relied on. That last field makes repair possible later.
A conflict check. Two specialists proposing opposing changes to one account should surface before either commits, with an owner named to settle it.
A policy check outside the planner. OWASP's agentic Top 10 recommends separating planning from execution with an external policy engine. A supervisor that grades its own plans is a reviewer with a conflict of interest.
An approval gate and a narrow executor. Consequential changes wait for a named person who can approve, edit or decline. Only the executor holds write credentials.

After execution, something has to verify the effect and keep the record open until the later outcome arrives. We call that record a Decision Trace: the evidence, alternatives, rationale, human judgment, authorized action and later outcome, kept together. An execution log shows what ran and stops there.

Identity, permissions and the boundary

The tempting shortcut gives the supervisor the union of its workers' permissions, since it has to delegate to all of them. That turns the component most exposed to bad input into the most privileged identity in the system. A supervisor should hold the right to delegate and little else. Each run should get short-lived, task-scoped credentials, as OWASP also recommends, and delegation can narrow authority without ever widening it. Ask a vendor what a child agent inherits, and whether you can tell which agent took the action.

More agents also mean more boundary crossings. Each specialist may call a different model or tool server, so a review of one agent says little about the whole system. Trace each route, including telemetry and backups. In Nodes Cloud, Nodes manages the boundary. In a single-tenant customer VPC or customer-managed on-premises deployment, the boundary sits in the customer's environment, and the approved model connections decide what can cross it.

How it fails, and what a gate can't do

OWASP lists the failure as ASI08, Cascading Failures: one fault, whether a hallucination, a malicious input, a corrupted tool or poisoned memory, spreads across agents and compounds into harm across the system. The entry is about propagation and amplification, with the original defect treated separately. That is the right frame for design. You won't stop every bad input, so judge the architecture by how far one travels.

OWASP's scenarios are written as examples, and so is mine. I am not citing a documented incident. What makes the entry useful is its detection hooks: one decision fanning out to many downstream tasks in a short time, spread beyond the original domain, retry loops between agents, queue storms and repeated identical intents. A monitoring system can count all of those.

A human gate helps, and OWASP's text points at two limits on it. The first is speed. Faults can spread faster than people can keep up, and OWASP says some unmitigated risk remains for the enterprise to weigh. That is the case for machine brakes that don't wait on a person: rate limits, circuit breakers between planner and executor, automatic pauses on anomalies.

The second limit is drift, and it worries me more. One of OWASP's examples has oversight weakening after repeated success, through bulk approvals and relaxed policy. Favorable results feel like a reason to widen an agent's scope, and they are no such thing. Rising volume with a falling decline rate can mean the agents improved, or it can mean nobody is reading.

Rollback has its own multi-agent problem. Reversing one write is easy to picture. The harder question is what else read that write before you caught it. In the example above, correcting the credit status doesn't release the shipment, restore the forecast or retract the notice. OWASP calls for lineage on every propagated action for this reason. A system that can't list what depended on a bad record leaves you repairing it by hand, from memory.

Where this argument stops

Gates cost time. Putting one on every step would defeat the reason to use agents, so reads, drafts and work inside an already approved scope can keep moving, while material changes to effects, scope or authority go back for approval.

Many jobs need no supervisor at all. One agent with good tools has fewer handoffs to fail, and a known sequence of steps is better written as an ordinary workflow than rediscovered by a planner on each run. Multi-agent earns its cost when the domains differ enough that one agent would do them badly.

My argument weakens when agents only read. A team of agents that researches and drafts for a person has nothing to cascade into a system of record, and retrieval may well remain its limit. The report's own worked example, a system that detects intent, retrieves documents, runs checks and replies to clients, sits close to that case. Storage keeps mattering too. The same report argues that agents are driving a new kind of database, and I have no quarrel with that.

Platform-native governance is a serious alternative. Databricks argues that unified governance is the precondition for deploying agents at scale, and it reports that companies using AI governance put more than twelve times more projects into production. I like that finding, which is why I distrust it. The report describes no controlled comparison, and telemetry can't separate governance enabling production from companies with many projects buying governance tools. Platform controls may cover what you need when the work stays on that platform. Check whether they reach business authority that lives in systems and approvals outside it.

Shared context is also a target

Shared context widens what one bad entry can reach. OWASP's examples include corrupted persistent memory that keeps shaping new plans after the original source is gone, and a wrong fact in a graph every agent reads will travel further than a wrong fact held by one. So writes to shared context need the same discipline as writes to a system of record: a source, a scope, evaluation and a version before reuse. A local preference does not become company policy because one agent saw it work.

Nodes Engine, our main product, creates the company context graph, compares options and carries out approved work. The company defines what each person and agent may read, recommend and change. Nodes works within configured permissions. Actions requiring approval remain gated by the customer's policy. Monitoring and Decision Traces show the work, and a team can pause the work or remove access. Current permissions govern work; prior approval never expands them. The architecture and security and deployment pages carry the detail.

Our public production evidence is a Fortune 1000 insurance carrier, live since January 2025, across hiring, licensing progress and educational support. That evidence covers those workflows. It does not prove the full pattern above for every multi-agent design, ours included, so verify enforcement in the workflow you are buying. See the evidence and its limits.

Three checks before the next supervisor goes live

Pick a record an agent changed last week and ask for everything that read it afterward. If the answer takes a meeting, you have no lineage.

Give two specialists conflicting goals in a test environment and watch where the conflict appears. Before the write, you have a control. After the write, you have cleanup.

Pull a quarter of approvals and sort by decline rate and review time, per reviewer. A gate that declined nothing for a quarter deserves a closer look than the agents behind it.

Two older tests still apply: how long a chain of actions can run without a person, and whether the new worker overlaps one you already have.

Databricks counted how fast agents are multiplying on its platform. No report I have read prints the other number: how many of those changes a person could still explain six months later. Each company has to count that one for itself.

Sources

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.