Multi-Agent AI Risk: Fix the Paths, Not the Agents

By Lazar Milicevic · Published October 22, 2026 · 12 min read

You shipped your first AI agent and it works. Then you added a second one to handle follow-ups, a third to read invoices, and now a bug somewhere in the chain is producing wrong answers that nobody can trace back to a single step. The danger isn't any one agent going rogue. It's that nobody owns the connections between them.

This post covers why multi-agent systems fail at the seams, what the available (vendor-sourced) data says about governance gaps, and a concrete set of engineering practices you can apply whether you run three agents or thirty.

The failure mode: complexity grows with paths, not agents

Agent complexity scales with the number of connections between agents, tools, and applications, not with agent headcount. Each new agent adds not just itself but every new route it can call, be called by, or hand data to. That's where debugging time disappears.

The framing comes from a sponsored piece on VentureBeat, written by Gravitee CEO Rory Blundell and published August 27, 2026. Its argument: enterprises don't deploy one agent and watch it run, they deploy fleets, each one calling APIs, calling other agents, and reaching into applications that were never built with a machine decision-maker in mind.

A fair caveat before going further. That article is sponsored content from a company that sells agent-governance products, and its central claim (that complexity "compounds") is opinion, not research. The illustration that a tenth agent adds dozens of connections is arithmetic, not a measurement. I find the underlying logic sound from building these systems, but treat it as a design heuristic rather than a proven law.

Here's the arithmetic, using round example numbers. If every agent could in principle talk to every other agent, the number of possible pairwise paths is n × (n − 1) / 2:

Real systems are never fully connected, and that's the point of this post: you get to choose which paths exist. Most teams don't choose. Paths appear by accident: an agent gets a broader tool list "just in case," a prompt says "ask the research agent if unsure," a shared API key makes everything reachable.

The second part of the VentureBeat piece is the one I'd tape to a monitor. It describes five agents touching one workflow, something breaking at step four, and nobody having been assigned to own that link. That's not an AI problem. That's an ownership problem that AI makes expensive.

What the survey numbers say (and how much to trust them)

The best available data on agent governance gaps comes from Gravitee's own surveys, which are vendor-run and should be read as directional, not as market-wide measurements. They're still useful because they describe symptoms most builders will recognize.

Here is what Gravitee reported, with the caveats attached:

• In its State of AI Agent Security 2026 report, 88% of organizations reported confirmed or suspected AI agent security incidents in the last year. Only 14.4% had full security approval for their agent fleet, and only 22% treated agents as independent identities.
• In its April 2026 update, agent estates roughly doubled in four months, mean monitoring coverage was about 52% (so roughly 48% of production agents ran unmonitored), only 7.2% of organizations had formal named accountability for agent behavior, and only 19.7% said all their agents were fully secured and governed before going live.
• VentureBeat's coverage of the survey reported that 45.6% of teams still use shared API keys, and 25.5% of deployed agents can create and task other agents.
• Per a secondary analysis, 22.5% of organizations have no formal catalog of their agents or MCP servers, and only 7.7% audit agent activity daily; monthly review is the most common cadence at 37.5%.

Read these carefully:

1. The sample is enterprises, not small businesses. I found no comparable data for teams of 1-10 people. Don't extrapolate these rates to your shop.
2. The numbers move between waves. Sample size and dates differ across sources (900+, 919, and 750 all appear), and monitoring coverage and incident rates shift between survey waves. Gravitee itself says its confirmed-incident figure is likely underreported. I'm deliberately not giving you a single "incident rate."
3. The sample likely skews toward Gravitee's customers, so "how many are past planning" is probably overstated for the wider market.

The qualitative pattern is what matters: agents multiply faster than the organization's ability to name an owner, catalog them, or review what they did. The 25.5% figure for agents that can spawn other agents is the one that maps most directly onto path explosion, because an agent that creates agents makes the path count a runtime property rather than a design-time one.

Is the 40% cancellation forecast about this? Not exactly

Gartner's widely quoted "40% of agentic AI projects get canceled" is a forecast about cost, value, and risk controls, not specifically about multi-agent complexity. Citing it as proof that complexity kills projects would be a stretch.

Gartner's June 25, 2025 press release predicted that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. It's a prediction made in 2025, not an observed cancellation rate. Forbes also reports Gartner's estimate that only about 130 of the thousands of vendors claiming agentic capabilities were building anything deserving the label, which Gartner calls "agent washing."

Why mention it here? Because two of Gartner's three causes, escalating cost and inadequate risk controls, are exactly what an unmapped web of agents produces. When you can't tell which agent called which tool with whose credentials, every incident costs more to diagnose and every control is harder to prove. The link is plausible and mechanical, but it's my inference, not Gartner's finding.

Draw the boundaries before you add the next agent

The cheapest complexity control is a written boundary for each agent: what it may read, what it may call, what it may write, and who owns it. If you can't write that on half a page, the agent is too broad.

Here's a manifest format you can use as a starting point. It's plain YAML, kept in the repo next to the agent code:

# agents/invoice-reader.yaml
name: invoice-reader
owner: lazar@yourcompany.example       # a named human, not a team alias
purpose: Extract line items from supplier invoice PDFs
inputs:
  - source: email-inbox/invoices-label
    format: pdf
tools_allowed:
  - pdf.extract_text
  - ledger.draft_entry      # draft only, no posting
tools_denied:
  - ledger.post_entry
  - email.send
may_call_agents: []          # explicit empty list: this agent calls nobody
may_be_called_by:
  - ap-orchestrator
credentials: svc-invoice-reader   # its own identity, not a shared key
review_cadence: weekly
escalation: ap-orchestrator -> human approval queue

Three fields do most of the work:

• may_call_agents and may_be_called_by turn implicit paths into explicit ones. If a path isn't in both lists, it doesn't exist.
• owner answers the "step four broke, who's responsible" question before it's asked. Gravitee's reported 7.2% rate of formal named accountability suggests this is rare in practice.
• credentials forces the question of identity. Forty-five point six percent of surveyed teams still use shared API keys, which means an incident can't be attributed to a specific agent.

Then enforce the manifest instead of just documenting it. A thin check in CI that fails the build if an agent's code references a tool not in tools_allowed is worth more than a wiki page nobody reads:

# check_manifest.py - fail CI if an agent uses undeclared tools
import sys, yaml, pathlib, re

def declared_tools(manifest_path):
    m = yaml.safe_load(pathlib.Path(manifest_path).read_text())
    return set(m.get("tools_allowed", []))

def used_tools(source_path):
    # naive: find tool("name") calls; adapt to your framework
    text = pathlib.Path(source_path).read_text()
    return set(re.findall(r'tool\("([\w\.]+)"\)', text))

bad = 0
for manifest in pathlib.Path("agents").glob("*.yaml"):
    src = pathlib.Path("src") / f"{manifest.stem}.py"
    extra = used_tools(src) - declared_tools(manifest)
    if extra:
        print(f"{manifest.stem}: undeclared tools {sorted(extra)}")
        bad += 1
sys.exit(1 if bad else 0)

It's crude, and your framework will dictate the real detection method. The principle is the point: boundaries that aren't checked drift.

Give every agent an identity and a trace

You can't govern what you can't attribute. Each agent needs its own credential, and every cross-agent call needs a trace ID that survives the whole workflow. Without both, "which link broke" is a forensic exercise.

Practical minimum:

1. One service identity per agent. No shared keys. When an agent is compromised or misbehaves, you revoke one credential, not the whole fleet's access.
2. A workflow ID minted at the entry point and passed through every hop as metadata.
3. A structured log line per call, written by the caller and the callee, so mismatches are visible.

{
  "ts": "2026-10-22T14:03:11Z",
  "workflow_id": "wf_8f2c1a",
  "step": 4,
  "caller": "ap-orchestrator",
  "callee": "invoice-reader",
  "tool": "pdf.extract_text",
  "status": "error",
  "error_class": "schema_mismatch",
  "input_hash": "sha256:9d1e...",
  "latency_ms": 840
}

Log the hash of the input rather than the input itself if it contains customer data. With this one line schema, the VentureBeat scenario (five agents, failure at step four) becomes a single query: filter by workflow_id, sort by step, read the first non-OK status.

Two cadence points. First, Gravitee's data puts monthly review as the most common audit rhythm and daily as rare (7.7%). For a small fleet, a weekly 15-minute read of error classes and denied-tool attempts is realistic and catches most drift. Second, keep a catalog. Twenty-two point five percent of surveyed organizations had no formal list of their agents or MCP servers; for you, the agents/ directory of manifests is the catalog, as long as you delete manifests when you delete agents.

Use MCP to make the tool layer boring

The Model Context Protocol gives agents one standard way to reach tools, which turns a tangle of bespoke integrations into a single surface you can inspect, permission, and log. That's the real value for complexity control: fewer unique connection types.

Some recent facts worth knowing:

• The MCP 2026-07-28 specification was released on July 28, 2026. Its headline change is a stateless protocol core, replacing the earlier bidirectional stateful design.
• All four Tier 1 SDKs (TypeScript, Python, Go, C#) support it, and Cloudflare notes that MCP servers can now run in just a Worker with no stateful infrastructure.
• Anthropic donated MCP to the Agentic AI Foundation at the Linux Foundation on December 9, 2025; the foundation was co-founded by Anthropic, Block, and OpenAI, and MCP's governance model was said to remain unchanged (timeline).

Why does stateless matter for the topic of this post? Stateless servers are easier to reason about: a call carries everything the server needs, so there's less hidden session state quietly coupling one agent's behavior to another's. That's a property I'd verify against the final spec for your specific use case. I have not read the final changelog on the MCP site, so check it directly before relying on details such as which features were deprecated or what deprecation windows apply. Some descriptions I saw came from release-candidate notes and a secondary timeline.

One way to structure an MCP-based setup for a small fleet:

mcp-servers/
├── ledger/        # draft_entry (read/write draft), get_balance (read)
├── mailbox/       # read_labeled, draft_reply  (no send)
├── crm/           # find_contact, log_note
└── gateway.yaml   # per-agent allowlist of server+tool pairs

# gateway.yaml - the only place agent→tool permissions live
invoice-reader:
  - ledger.draft_entry
  - mailbox.read_labeled
followup-writer:
  - crm.find_contact
  - crm.log_note
  - mailbox.draft_reply

Rule of thumb: tools are shared; permissions are per-agent. Separate "can this agent reach this tool" from the tool's own code, and keep that mapping in one file you can diff in a pull request. Splitting write-capable tools into "draft" and "commit" variants gives you a natural human-approval point without changing the agent.

Design for the break: step four will fail

Assume every hop fails sometimes. Complexity becomes dangerous when a failure in one link silently produces plausible-looking output for the next. The fix is to make failures loud and local.

Four patterns that have paid for themselves:

1. Validate at every boundary. Each agent checks its input against a schema and refuses malformed data rather than guessing. A refusal at step four is better than a confident wrong answer at step five.
2. Return structured status, not just text. {"status": "needs_human", "reason": "total_mismatch"} is routable. A paragraph of prose isn't.
3. Cap depth and fan-out. Set a hard maximum on call depth (say, 3) and a rule that agents cannot create other agents without a human-approved manifest. Given that 25.5% of surveyed deployed agents can create and task other agents, an explicit "no" here is a cheap control.
4. Prefer deterministic code where the task is deterministic. If a step is "parse this CSV and sum column C," that's a script, not an agent. Every step you demote from agent to function removes paths and removes nondeterminism. (I wrote about when a plain script beats an agent in a separate post on Python scripts vs. AI agents.)

A simple orchestration guard might look like this:

MAX_DEPTH = 3

def call_agent(caller, callee, payload, ctx):
    if ctx["depth"] >= MAX_DEPTH:
        raise RuntimeError(f"depth limit hit: {caller}->{callee}")
    if callee not in MANIFESTS[caller]["may_call_agents"]:
        raise PermissionError(f"{caller} may not call {callee}")
    ctx = {**ctx, "depth": ctx["depth"] + 1}
    log_call(ctx["workflow_id"], caller, callee)
    return AGENTS[callee].run(payload, ctx)

Fifteen lines, and it converts "emergent path" into "denied and logged."

A pre-launch audit checklist for your own fleet

Before adding agent number N+1, spend 30 minutes answering these questions for the existing ones. If you can't answer one, that's your next task, not the new agent.

• Does every agent have a named human owner?
• Does every agent have its own credential (no shared keys)?
• Is there one list of all agents and tool servers, and is it current?
• For each agent, can you state which other agents it can call and which can call it?
• Can you take any single workflow run and reconstruct every hop from logs in under 10 minutes?
• Which tools can write, send, delete, or spend, and which agents reach them?
• What happens when a hop returns garbage? Does the chain stop or continue?
• When did a human last read the logs?

These questions deliberately avoid asking whether the agents are "smart enough." The failures that hurt are structural.

Where this fits in practice

I'm a senior engineer who builds AI automations for solopreneurs and small teams, and the pattern above is how I think about the problem: MCP as a shared tool layer, a per-agent permission map in one reviewable file, and explicit ownership and boundaries written down before the second agent ships. When something breaks in production, the goal is that you find the failing link from one workflow ID rather than by re-reading five prompts.

If you already have several agents running and aren't sure what can call what, the first step is the audit above: map your agents, look for undeclared paths, shared keys, and write-capable tools without a human gate, and write down a boundary and ownership plan you can run yourself. I'm not claiming the enterprise survey numbers above describe your business; they don't, and I haven't seen SMB-specific data. The structural problem, though, shows up at every size.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.