The Agent Coordination Problem: Why More Agents Doesn't Mean More Intelligence

Ramp’s AI usage is up 6,300% from last year. 84% of the team uses coding agents weekly. Non-engineers account for 12% of all human-initiated PRs on their production codebase. They built 1,500+ internal apps in six weeks, from 800+ different builders. This is a single company. And it’s not an outlier — it’s a preview.

The question most people are asking is: how do we get our company to look like this? The question worth asking is: once you do, what breaks next?

This essay is about that second question.

Abstract

The agent-to-human ratio inside organizations is shifting — from 1:1 today, to 1:many in the near term, to a world where agents significantly outnumber the humans who deploy them. This shift is commonly framed as a productivity story. It is also, less visibly, a coordination infrastructure story. As agent counts scale, the communication overhead between agents grows quadratically. An organization with N agents that each need to share context faces O(N²) potential pairings — the same combinatorial explosion that once made direct-dial telephony unscalable. The solution in networking was a shared protocol layer. The analogous need in multi-agent organizations is a shared context layer: a place where agent findings, session history, and domain knowledge accumulate and become accessible to every agent in the system. Without it, each new agent added to an organization increases coordination cost faster than it increases output.

1. The Ratio Is Already Shifting

A year ago, “AI at work” meant one person with one ChatGPT tab. Today, a single engineer at a company like Ramp might simultaneously run Claude Code on a feature branch, a Cursor session refactoring tests, a Codex agent handling documentation, and a background Gemini CLI job summarizing a PR diff. That’s four agents per person, and the number is growing.

Geoff Charles, VP of Engineering at Ramp, documented how this happened at scale: they built Glass, an internal AI platform built on Anthropic’s Claude Agent SDK, pre-connected to 30+ internal tools (Salesforce, Snowflake, Gong, Slack, Notion, Figma) with a single SSO authentication. Within a month of launch, 700 daily active users. A skills marketplace where anyone can package a workflow and share it company-wide: 350 skills shared. The result was a company where the cognitive boundary between “engineer” and “non-engineer” started to dissolve — not because everyone learned to code, but because everyone could direct agents that knew how.

Box CEO Aaron Levie, speaking on the a16z podcast, framed the directionality clearly: if you have a hundred times or a thousand times the number of agents as you have employees, your software has to be built for agents. Not as a feature addition. As a first-principles architectural constraint.

We are at the beginning of phase two. The infrastructure decisions made now will determine whether phase three is functional or chaotic.

2. What Actually Scales When Agents Multiply

The naive model of “more agents = more output” holds under a specific condition: that each agent operates independently on a well-defined, bounded task. A coding agent that takes a ticket and submits a PR. An analyst agent that reads a dashboard and writes a summary. These agents don’t need to talk to each other. They consume inputs, produce outputs, done.

But the tasks that matter most to an organization are not bounded in this way. A go-to-market motion requires competitive intelligence, customer feedback synthesis, positioning analysis, and content creation — all of which inform each other. A product development cycle requires user research, technical feasibility assessment, spec writing, and implementation planning. These workflows are not pipelines where each stage consumes the previous stage’s output. They are meshes: every node potentially informed by every other node.

In a human organization, this coordination happens through shared context: meetings, documents, Slack threads, team wikis, institutional memory held by senior employees. When a PM briefs an engineer, they’re not just transmitting a task spec — they’re transferring a fragment of the reasoning context that led to the spec. That context allows the engineer to push back, adapt, and make judgment calls the PM didn’t anticipate.

When agents replace or augment humans in these workflows, they need the same thing: access to the reasoning context that gives tasks meaning. Without it, each agent makes locally rational decisions that are globally incoherent.

The Ramp data illustrates what happens when you solve this at the individual level: their “skills marketplace” meant that when one sales rep figured out the best workflow for analyzing Gong calls, every rep inherited that superpower. Context propagated. But this was still mediated by humans packaging and sharing skills. As agent counts scale past the point where human curation is feasible, the propagation mechanism needs to be structural, not artisanal.

3. The N² Problem

Here is the coordination math that determines whether multi-agent organizations scale.

In an organization with N agents, the number of unique pairings between agents is N(N-1)/2 — roughly O(N²). If context needs to flow between any two agents that work on related problems, and there’s no shared infrastructure, then the coordination overhead is quadratic in the number of agents.

• A 10-person team with 3 agents each = 30 agents. Pairwise coordination channels: 435.
• A 100-person company with 10 agents each = 1,000 agents. Pairwise channels: 499,500.
• A 1,000-person company at the same density: ~5 million pairings.

No organization consciously manages 5 million communication channels. Humans don’t do this either — the reason functional teams don’t devolve into O(N²) chaos is shared infrastructure: a single source of truth for decisions, a common understanding of context, a team wiki that everyone reads instead of everyone briefing everyone else.

The agent coordination problem is precisely this, at higher speed and lower legibility. An agent in a long-running research session has accumulated 40 minutes of context about a customer segment. A second agent, briefed on a different aspect of the same customer, starts from scratch and reaches contradictory conclusions. A third agent, generating content, operates from neither set of findings. The output of these three agents is less than the sum of its parts — not because the agents are poorly built, but because the context that would make them coherent has nowhere to live.

This is not a hypothetical future problem. Box’s Aaron Levie described running a Claude Code session that got stuck in a loop, recursively creating nested directory structures because it had no shared state telling it what prior sessions had already done. Multiply that across 50 agents operating in a shared workspace without coordination infrastructure and you get the enterprise IT nightmare he described: agents making conflicting writes, no audit trail, no rollback, no mechanism to detect that three agents are trying to simultaneously restructure the same folder hierarchy.

The solution architecture is the same one that solved N² problems in networking, in team communication, and in distributed systems: a shared layer that every node reads from and writes to.

Instead of N agents each maintaining N-1 bilateral context relationships, you have N agents each maintaining 1 relationship to a shared context store. The coordination complexity drops from O(N²) to O(N).

4. The New Infrastructure Stack for Multi-Agent Organizations

If you accept that agent counts will grow by an order of magnitude in the next few years, several infrastructure categories become load-bearing that aren’t fully solved today.

Context persistence across agent sessions. Most agents today operate within a single session window. When the session ends, the context is gone. A researcher who discovers that a particular customer segment is under-served by competitor X needs that finding to be available to the content agent writing the positioning piece next week, to the product agent planning the roadmap next month, and to the sales agent preparing a demo next quarter. Context that doesn’t persist doesn’t compound.

Agent identity and access control. Levie raised a problem that doesn’t have a clean solution yet: agents, unlike employees, require complete transparency for safe operation. You need to be able to inspect an agent’s context, revoke its access, and undo its actions — which means agents cannot have the same privacy expectations as human employees. But if every agent is fully transparent, how does it participate in workflows involving confidential information without being a prompt-injection surface? The identity model for agents is not the same as for humans, and the infrastructure for managing it doesn’t exist at scale.

Cross-agent knowledge accumulation. When one agent discovers something, the finding should be available to other agents working on related problems. This is different from simple data sharing — it requires semantic indexing, relevance scoring, and a model of what “related” means across agent tasks. It looks less like a database and more like a team’s institutional memory: structured enough to be queryable, rich enough to carry reasoning context, and maintained well enough that agents trust it rather than ignoring it.

Coordination without direct communication. The alternative to a shared context layer is agent-to-agent messaging — agents explicitly briefing each other. This is how early multi-agent frameworks like AutoGen and CrewAI approached orchestration: a manager agent dispatching to worker agents via explicit message passing. The problem is that it recreates O(N²) coordination overhead at the message level, and it doesn’t solve the problem of context that spans sessions or that needs to be available to agents that weren’t in the original conversation.

Harness systems as the interface layer. MCP servers and skill harnesses — like the one Ramp built internally with Glass — are emerging as the practical implementation of context infrastructure. A harness pre-connects agents to organizational data sources, provides typed tool interfaces, and manages the context that makes those tools meaningful. But most harnesses today are built for a single agent or a small agent team. The design question for the next phase is: how do you build a harness for an organization where the agent count is an order of magnitude larger than the human count?

5. Lessons from How Human Organizations Solved This

The coordination problem in multi-agent organizations is new in its specifics but not in its structure. There are historical analogues worth examining.

The shift from direct-dial to switched telephony. Before telephone exchanges, connecting N telephone users required N(N-1)/2 physical cables. The exchange introduced a shared routing layer, reducing connections to N. This is structurally identical to the shared context layer argument: you don’t need every agent to directly know about every other agent’s findings. You need one place where findings land and from which they can be retrieved.

The database as organizational memory. Before relational databases, enterprise software encoded business logic in procedural code, with data scattered across files and application-specific formats. The database layer introduced a shared, queryable representation of organizational state that any application could access. Agents need the equivalent: a shared, queryable representation of organizational knowledge and context that any agent can access regardless of when it was created or which session it’s running in.

The team wiki problem. Every fast-moving engineering team eventually discovers that the knowledge in people’s heads is a liability: it walks out the door when people leave, it doesn’t propagate to new team members, and it can’t be queried at 2am when something breaks. The wiki is the shared context layer for human teams. It works when people actually write to it, which is the hard part. For agent teams, the write discipline is less of a problem — agents can be instrumented to automatically surface findings — but the schema design and retrieval quality become critical.

None of these historical solutions were adopted quickly or without friction. The database didn’t displace application-specific data formats overnight. The team wiki didn’t replace hallway conversations immediately. The telephone exchange required rearchitecting an industry. What they share is that they reduced coordination overhead by introducing a shared layer that scaled better than the N² alternative.

6. The Emerging Demand Landscape

What does this create in terms of product opportunity? Several categories are becoming distinctly visible.

Persistent agent memory. Systems that allow agents to accumulate knowledge across sessions, with semantic retrieval that surfaces relevant prior findings automatically. This is different from simple session history — it requires chunking, embedding, and intelligent retrieval that understands task context.

Multi-agent observability. When multiple agents operate in a shared workspace, you need visibility into what each agent is doing, what context it’s operating from, and how its actions relate to other agents’ actions. This doesn’t exist in mature form for multi-agent systems. The tooling that exists for monitoring individual agents doesn’t compose well.

Context-aware harness systems. MCP servers and skill harnesses that aren’t just routing layers but active context managers — systems that know what an organization has learned, can inject relevant context automatically into agent sessions, and can prevent agents from duplicating work or reaching contradictory conclusions.

Agent coordination protocols. Standards for how agents signal intent, reserve resources, and communicate findings without requiring direct pairwise channels. The closest thing that exists is MCP’s tool invocation model, but it’s designed for human-to-agent interaction, not agent-to-agent coordination at scale.

Shared context stores with organizational semantics. Not a generic vector database, but a knowledge layer that understands what a company knows: which analyses have been done, what conclusions were reached, what questions remain open, what findings from one domain are relevant to another. The organizational equivalent of working memory.

7. What We’re Building at CrowdListen

The shared context problem is exactly what CrowdListen is designed to address.

CrowdListen is building the context layer for multi-agent organizations — specifically focused on the domain where agent coordination most visibly fails today: understanding what’s happening in the world outside your organization, and making that understanding persistent and shareable across agents.

The core insight is straightforward. When an agent researches a competitor, analyzes customer sentiment, or synthesizes a market signal, that analysis has value beyond the session that produced it. The next agent working on a related question should start from what the last one found, not from scratch. The product manager briefing the positioning agent should be able to say “use what we’ve already learned about segment X” and have the agent actually access that prior work.

Without a shared context layer, every agent session in an organization starts from zero. The competitive analysis done last Tuesday is inaccessible to the product spec being written today. The customer feedback synthesized last month doesn’t inform the content being generated next week. The work compounds only in the heads of the humans who were present for it — which means it doesn’t really compound at all.

CrowdListen creates the infrastructure for that compounding. Analyses are stored as structured knowledge, semantically indexed for retrieval. New agent sessions can query prior findings rather than re-running the same research. Multiple agents working on related problems share a common view of what the organization knows. The context that makes agent output coherent is maintained outside any single session.

This is the N² → N reduction in practice. Instead of each new agent in an organization needing to independently build context about its domain, every agent shares access to a growing body of organizational knowledge. The cost of adding the tenth agent to a workflow is lower than the cost of adding the second, because the context the tenth agent needs is already there.

As the agent-to-human ratio shifts from 1:1 to 1:many to many:1, the organizations that build this infrastructure early will accumulate a compounding advantage. Their agents will start from a richer context base. Their analyses will build on prior work instead of duplicating it. Their coordination overhead will scale linearly rather than quadratically.

The agents are multiplying. The question is whether the infrastructure for making them coherent will keep up.

References

Geoff Charles. “How to get your company AI pilled.” Ramp Engineering Blog, 2026. Link

a16z podcast. “The Future of Enterprise Software with Aaron Levie.” 2026. Link

Anthropic. “Introducing Claude Agent SDK.” 2025. Link

Model Context Protocol. “Specification — 2025-11-25.” 2025. Link