Article reader Listen + reading controls

LISTEN + READ YOUR WAY

Article reader

Preparing the reader…

0:00 0:00

Speed

Reading settings

Typeface

Text size

100%

Reading surface Text spacing

Multi-agent systems need a shared world, not just shared messages¶

The proposal window for the Defense Advanced Research Projects Agency's (DARPA) Decentralized Artificial Intelligence through Controlled Emergence program closed yesterday. DICE asks a difficult systems question: can heterogeneous artificial intelligence agents coordinate through peer-to-peer interaction, adapt when individual agents fail or become compromised, and still remain aligned with commander's intent over long missions?

Two days earlier, researchers released a preprint describing an “ontology as a kernel” for language-model agents. The proposed system makes domain concepts, relationships, evidence, and permissible reasoning operations explicit instead of leaving all of them implicit in prompts and unstructured context.

Those developments come from different research communities, and neither proves the other's architecture. Together, they expose the same design boundary: a collection of agents does not become a system merely because the agents can exchange messages. It becomes a system when they can coordinate around a shared, inspectable, and governed model of the world and the work.

That is a semantic-systems problem.

More agents do not automatically produce more intelligence¶

Multi-agent designs are attractive for good reasons. Separate agents can explore independent lines of inquiry, protect their own context windows, use specialized tools, challenge one another, and perform work in parallel. Anthropic's account of its multi-agent research system reports substantial gains on breadth-first research tasks that can be decomposed into independent searches.

The same engineering account provides an important qualification. Its multi-agent system uses far more tokens than ordinary chat, and tasks with tightly coupled dependencies or a need for shared context may be poor candidates. Multi-agent coding, planning, or operations can become a very expensive telephone game.

Recent research reinforces that caution. A Nature Machine Intelligence study of 260 controlled single- and multi-agent configurations found that the value of collaboration depends on the relationship among model capability, task structure, coordination overhead, and error amplification. No one agent topology dominated every domain. More capable models could even outgrow the benefit of collaboration on some tasks.

A separate study of seven multi-agent frameworks identified 14 recurring failure modes across specification and system design, inter-agent alignment, and task verification and termination. Another team examined failure logs from 127 systems and found that its best method could identify the responsible agent only 53.5 percent of the time and the decisive failure step only 14.2 percent of the time.

This is the coordination tax. Each new agent adds capability, but it also adds another boundary at which intent can be compressed, terminology can drift, evidence can lose provenance, stale state can propagate, authority can be misunderstood, and responsibility can become harder to reconstruct.

The first multi-agent design question should therefore not be, “How many agents should we use?” It should be, “Which parts of this work are genuinely separable, and what must remain true when responsibility crosses the boundary between them?”

Protocol interoperability is not semantic interoperability¶

The agent ecosystem has made rapid progress on connection. The Linux Foundation says the Agent-to-Agent (A2A) protocol now has support from more than 150 organizations. A2A provides conventions for agent discovery, communication, tasks, and artifacts across frameworks. The Model Context Protocol (MCP) standardizes a different boundary: how an agent connects to tools and data.

These are important layers. In an earlier note, I argued that open protocols also need durable stewardship, conformance tests, migration rules, and security response. Yet even a perfectly conformant message can be misunderstood.

The National Institute of Standards and Technology (NIST) has framed interoperability and security as linked problems in its new AI Agent Standards Initiative. Its research agenda includes authentication and identity infrastructure for secure human-agent and multi-agent interaction. Identity can establish who sent a message and under whose authority. A shared domain model is still needed to establish what the message means.

Suppose one agent reports that a software change is complete. Does complete mean the code compiles? The visible tests pass? Independent security checks pass? The customer accepts the result? The release authority approves deployment? The change is operating successfully in production?

The message may be syntactically valid while the workflow is semantically broken.

The same problem appears in ordinary enterprise language:

A system owner may mean a product manager, a data steward, a mission owner, or an official with authorization responsibility.
An approved model may be approved for experimentation, for one data class, for one cloud boundary, or for an operational decision.
A threat may be an observed indicator, an analyst hypothesis, a validated finding, or a formal intelligence assessment.
A requirement may be proposed, funded, baselined, implemented, verified, accepted, or superseded.

Natural language absorbs this ambiguity because people use institutional knowledge, professional judgment, and clarification. Agents can generate fluent agreement while operating from incompatible meanings.

Transport answers, “Can these agents communicate?” Semantics answers, “Are they referring to the same thing, under the same conditions, with the same consequences?”

The answer is not one universal enterprise ontology negotiated before any useful work begins. Large organizations contain legitimate bounded contexts: a term can carry different meanings in acquisition, operations, cybersecurity, intelligence, and engineering. The system needs explicit namespaces, mappings, ownership, and translation rules so those differences become manageable data rather than invisible prompt ambiguity.

The shared world needs more than a vector store¶

Embeddings are useful for finding material that appears semantically similar. Retrieval can provide an agent with relevant context. Neither mechanism establishes what the retrieved material means for the present decision.

A working semantic substrate for multi-agent workflows should make at least seven kinds of information explicit:

Shared element	Question it must answer
Identity	Which real-world entity, system, requirement, user, agent, or artifact is this?
Type and relationship	What kind of thing is it, and how is it related to the rest of the mission or enterprise?
Provenance	Who or what produced this claim, from which source, using which process and version?
Status and time	Is it observed, inferred, proposed, approved, disputed, expired, or superseded—and when did that become true?
Authority	Who may read, assert, modify, approve, disclose, or act upon it?
Constraint	What conditions must hold before this state transition or action is valid?
Acceptance	What evidence establishes that the work is complete for this purpose?

The word claim matters. An agent output should not enter shared memory as truth merely because another agent produced it confidently. It should enter as an attributable assertion with evidence, scope, status, and a route for validation or correction.

This extends the argument I made in Stateful agents make memory a governance problem. Persistence is not yet organizational knowledge. In a multi-agent workflow, ungoverned persistence can turn one agent's provisional inference into every other agent's hidden premise.

A knowledge graph can become an operational coordination surface¶

Knowledge graphs and ontologies are useful here because they can represent named entities, typed relationships, constraints, provenance, and multiple views of a changing domain. They can let an agent traverse an explicit chain rather than rely only on similarity across text.

The new OaK preprint is interesting because it treats the ontology not as a passive glossary but as a computational kernel. The framework constructs a task-oriented schema, instantiates a knowledge graph from task data, and generates typed functions for retrieval, filtering, traversal, aggregation, and multi-step reasoning. A language-model agent selects among those bounded functions rather than inventing every reasoning path in free-form language. The authors report consistent gains across three benchmarks and two model backbones.

That is early research, not proof of a universal architecture. The ontology is automatically constructed and refined for benchmark tasks; production organizations would still need domain review, security boundaries, lifecycle management, adversarial testing, and evidence that the representation survives real operational change.

Another August preprint offers a more domain-specific example. Researchers working on biomedical data integration describe an AI-semantics workflow that combines a multi-agent curation system grounded in biological ontologies, an embedding service that maps terminology across databases, and a knowledge graph exposed through MCP for cross-database queries. The design does not ask one method to do everything. Ontologies provide controlled domain meaning; embeddings help align heterogeneous terminology; the graph preserves relationships; and the protocol gives agents a consistent way to use the capability. The authors also warn that ontology grounding does not establish biological correctness, especially when agents participate in developing the ontology itself.

That layered design is more instructive than the familiar argument about whether knowledge graphs are “better” than retrieval-augmented generation. A mature semantic system will often need documents, search, embeddings, graph traversal, rules, event histories, and human expertise. The architecture should assign each mechanism the job it can actually perform.

Not every team needs RDF, OWL, SPARQL, or a graph database. A carefully governed relational model, typed event schema, state machine, and policy engine can provide shared semantics for a bounded workflow. The design principle is more important than the storage brand: agents need stable identifiers, defined relationships, validated state transitions, and inspectable evidence outside their private context windows.

Treat each handoff as a typed state transition¶

Many multi-agent diagrams show boxes labeled planner, researcher, coder, reviewer, and operator, with arrows between them. The arrows deserve more design attention than the boxes.

A reliable handoff should specify:

The object of work. A stable identifier points to the same case, requirement, code change, finding, or mission task for every participant.
The current state. The receiving agent knows what has been observed, attempted, rejected, approved, and left unresolved.
The evidence. Important claims remain linked to sources, versions, tool results, and the agent or person responsible for them.
The contract. Required fields, preconditions, invariants, and acceptance tests are machine-checkable where practical.
The authority envelope. The next agent receives only the tools, data, resources, and actions required for its part of the workflow.
The failure route. Ambiguity, conflict, missing evidence, policy denial, or low confidence creates a defined escalation rather than a plausible improvisation.

The World Wide Web Consortium's (W3C) standards offer mature building blocks for this kind of thinking. OWL 2 defines formally meaningful domain vocabularies. PROV-O represents entities, activities, agents, derivation, and responsibility. SHACL validates graph structures against explicit constraints. A new SHACL 1.2 working draft, published this month, explicitly describes uses that include validating data, modeling domains, generating ontologies to inform other agents, generating code, and integrating data.

These standards will not make a language model deterministic. They can move important assumptions out of prompts and into artifacts that ordinary software can inspect, validate, version, and test.

Keep shared semantic state separate from private working context¶

Agents do not need to share every token of their reasoning or every item in memory. Doing so would increase cost, leak unnecessary data, entangle contexts, and allow one compromised participant to contaminate the entire collective.

A stronger pattern separates three layers:

Private working context: temporary notes, exploration, model-specific reasoning, and tool results needed by one agent.
Shared semantic state: versioned claims, entities, task status, decisions, evidence, constraints, and unresolved conflicts that other participants may rely upon.
Authoritative record: human- or system-approved requirements, policy, configuration, accepted artifacts, and decisions that govern external action.

Movement between those layers should be deliberate. An agent may propose a new relationship or correction to the shared graph. Validation can check structure and policy. A responsible person or trusted process can approve consequential changes. The authoritative record should not be writable merely because an agent possesses a persuasive explanation.

This is also where agent jurisdiction becomes part of semantic design. Authorization is not only a token attached to an API call. The system needs to understand the relationship among the acting agent, the delegating human, the purpose, the resource, the permitted operation, the time window, and the state of the work.

Multi-agent observability must reconstruct meaning, not just traffic¶

Traditional distributed tracing can show that service A called service B and service B returned an error. An agent trace must answer harder questions:

Which goal and approved plan caused the call?
Which version of the domain model did the agent use?
Which claims and sources influenced the decision?
What did the sending agent mean by the task it delegated?
What authority did the receiving agent believe it possessed?
Which constraint passed, failed, or was bypassed?
Where did an incorrect belief first enter shared state?
Which later outputs and actions inherited that belief?

Without semantic lineage, operators can collect enormous traces and still fail to explain the outcome. That is one reason the low failure-attribution results matter: debugging a multi-agent trajectory after the fact is not a problem we should assume a stronger model will solve for us.

Design the evidence chain while designing the workflow. Give each campaign, task, artifact, claim, policy decision, tool action, test result, and approval a stable identity. Record how they relate. Keep the control plane outside the agents' reach, and let that plane preserve the account of what the collective actually did. As I argued in Long-horizon agents need short feedback loops, oversight must arrive while intervention is still useful—not after semantic drift has propagated through the entire trajectory.

The public-sector case is especially semantic¶

Public-sector and defense environments combine exactly the conditions that make semantic drift dangerous: multiple organizations, specialized vocabularies, legacy systems, contractual definitions, formal authorities, changing mission context, access restrictions, and consequences that extend beyond an application's immediate user.

DARPA's DICE program makes the challenge visible at a demanding scale. It seeks decentralized coordination, long-horizon role coherence, resilience to failure or compromise, and behavior aligned with commander's intent. Its public material does not prescribe a knowledge graph or ontology, and a semantic layer would not by itself solve consensus, adversarial control, or distributed planning.

It would, however, help make the collective's operating assumptions inspectable:

What mission, doctrine, constraint, and commander's intent does each agent believe is current?
Which object or target does a local identifier refer to?
Which observation is direct, which is inferred, and which is disputed?
Which agent role may act on which resource under which conditions?
How does a correction propagate without erasing the historical record?
What does mission completion mean, and who has authority to declare it?

The same pattern applies to less dramatic government workflows. In a software factory, a planning agent, coding agent, security agent, test agent, and release agent need a shared definition of the requirement, affected system, acceptance evidence, and release authority. They also need a trustworthy representation of the existing technology estate; the first deliverable from generative coding should be understanding before agents begin changing systems they cannot yet explain. In grants administration, case management, logistics, regulatory review, or scientific research, specialized agents need to preserve source authority, data rights, records obligations, and the difference between a recommendation and an official decision.

This is why knowledge infrastructure is AI infrastructure. Multi-agent systems inherit not only the organization's documents but also its unresolved definitions, invisible exceptions, and fractured authority. More agents can make that institutional ambiguity execute faster.

A practical minimum for semantic multi-agent design¶

Before building a committee of agents, I would want a team to answer ten questions:

What valuable work is genuinely parallel or specialized enough to justify multiple agents?
What are the stable identities for the people, agents, resources, tasks, claims, and artifacts in the workflow?
Which domain terms require formal definitions because misunderstanding changes the outcome?
What state machine describes the work from proposal through acceptance?
What evidence and provenance must travel with every consequential claim?
Which information is shared, which remains private, and which becomes authoritative only after approval?
What authority is delegated to each agent for each task, resource, action, and time period?
Which constraints can ordinary deterministic software validate before another agent relies on the result?
How are disagreement, uncertainty, correction, supersession, and rollback represented?
Can an operator reconstruct why the collective acted and contain every downstream result of a bad assertion?

Those answers form a minimum viable semantic control plane. The implementation may include a schema registry, ontology service, entity-resolution pipeline, knowledge or property graph, event store, provenance ledger, policy decision point, constraint validator, workflow engine, and observability platform. It may start much smaller.

What matters is that the meaning of the work does not live only inside model context.

The mature design will look less like a chat room¶

The current visual metaphor for multi-agent AI is often a group conversation: several artificial personas discuss a problem until one produces an answer. That can be useful for exploration. It is a weak foundation for consequential work.

Real multi-agent systems will look more like distributed systems organized around governed knowledge. Agents will have bounded roles. Handoffs will carry typed artifacts. Claims will retain provenance. Shared state will distinguish hypothesis from authority. Constraints will be executable. Human decisions will be visible. Corrections will propagate without rewriting history. The system will be evaluated not only on final answers but on coordination cost, error containment, failure attribution, and accepted mission outcomes.

Protocols are making it easier for agents to speak. Better models are making each participant more capable. The next engineering task is giving the collective a world it can share without pretending that shared language guarantees shared meaning.

Sources and research trail¶

Defense Advanced Research Projects Agency, “Decentralized Artificial Intelligence through Controlled Emergence” and DICE Proposers Day presentation (June–August 2026).
Zhang et al., “Toward Effective and Reliable LLM Agents via Dynamic Ontology” (preprint, August 24, 2026).
McLaughlin et al., “AI Semantics for Biomedical Data Integration” (preprint, August 3, 2026).
Kim et al., “Capable Language Models Can Outgrow the Benefits of Collaboration”, Nature Machine Intelligence (2026).
Cemri et al., “Why Do Multi-Agent LLM Systems Fail?” (2025).
Zhang et al., “Which Agent Causes Task Failures and When? On Automated Failure Attribution of LLM Multi-Agent Systems”, Proceedings of the 42nd International Conference on Machine Learning (2025).
Anthropic, “How We Built Our Multi-Agent Research System” (June 13, 2025).
National Institute of Standards and Technology, AI Agent Standards Initiative and concept paper on software-agent identity and authorization (2026).
Linux Foundation, “A2A Protocol Surpasses 150 Organizations” (April 9, 2026).
World Wide Web Consortium, OWL 2 Web Ontology Language Overview, PROV-O: The PROV Ontology, Shapes Constraint Language, and SHACL 1.2 Core (Recommendations and August 3, 2026 working draft).