SEMANTIC DRIFT IN MULTI-AGENT ORCHESTRATION: ONTOLOGY DEGRADATION UNDER DISPATCH

Andres G. and the PaxLabs Research Team PaxLabs Inc. Correspondence: legal@paxeer.app

ABSTRACT

When tasks are dispatched across multiple autonomous agents, shared meaning degrades at each inter-agent boundary. We term this phenomenon semantic drift and argue that it is not random but follows predictable patterns tied to context compression, implicit ontology assumptions, and untyped message passing. We present a formal model of semantic drift in multi-agent orchestration pipelines, define drift metrics grounded in information-theoretic measures, and identify four principal mechanisms by which ontology coherence erodes through chains of sub-agents. Drawing on recent evidence from multi-agent coordination failures and tool-calling pipeline degradation, we propose a set of architectural mitigations: a shared typed ontology, content-addressed messages, provenance binding, and replay testing across agent boundaries. We also outline an evaluation protocol for measuring drift in production orchestration systems. Our analysis suggests that without explicit ontological commitments at dispatch boundaries, multi-agent systems accumulate meaning loss at a rate that compounds with pipeline depth.

Index Terms: multi-agent systems, semantic drift, ontology alignment, LLM

orchestration, message typing, provenance, dispatch architecture.

I. INTRODUCTION

Large language model (LLM) orchestration has moved rapidly from single-agent tool use to multi-agent pipelines in which a dispatcher delegates subtasks to specialized agents [1]. Frameworks such as AutoGen [2], LangGraph [3], and CrewAI [4] now support complex workflows where a planner agent breaks a task into fragments, assigns each fragment to a sub-agent, and reassembles the results. While this architecture scales capability, it introduces a failure mode we have not seen formally characterized: the progressive degradation of shared meaning as tasks pass through agent boundaries.

We call this phenomenon semantic drift. When agent A produces an output that agent B consumes, the interpretation B assigns to that output may diverge from what A intended. This divergence is not a simple encoding error. It reflects a mismatch in the ontological commitments each agent makes, implicitly or explicitly, about the domain of discourse. A research assistant agent may understand "risk" in terms of financial volatility; a compliance agent may understand the same token as regulatory exposure. When the dispatcher passes a summary containing "risk" from one to the other without typing or grounding the term, the pipeline accumulates unacknowledged ambiguity.

In this paper we make three contributions. First, we formally define semantic drift in terms of ontology alignment and information loss across agent boundaries (Section III). Second, we identify four mechanisms by which drift arises in practice: context compression, implicit ontology assumptions, tool description ambiguity, and model vendor differences (Section IV). Third, we propose a mitigation architecture based on shared typed ontologies, content-addressed messages, and provenance binding (Section VII), and we outline an evaluation protocol for measuring drift in production systems (Section VIII).

Our core thesis is that semantic drift in multi-agent orchestration is structural, not incidental. It follows from the fact that current dispatch architectures pass untyped natural language between agents that hold incompatible implicit models of the task domain. The fix is not better prompting but better typing.

II. BACKGROUND

A. Multi-Agent Systems

The study of multi-agent systems (MAS) has a long history in distributed artificial intelligence [5]. Classical MAS research focused on coordination protocols, negotiation, and emergent behavior in populations of simple agents. The current wave of LLM-based multi-agent systems differs in an important respect: agents communicate via natural language rather than formal message protocols. This flexibility is also the source of the problem we address.

Modern LLM orchestration frameworks treat agents as nodes in a directed graph. A dispatcher node receives a high-level task, decomposes it, and routes subtasks to specialist agents. Each specialist processes its subtask using its own LLM instance, tool access, and system prompt. The results flow back through the graph, often through aggregator or verifier agents [2], [3].

B. LLM Orchestration

Orchestration frameworks manage the lifecycle of multi-agent interactions. AutoGen [2] supports conversational patterns between agents with defined roles. LangGraph [3] models workflows as state machines with conditional routing. CrewAI [4] organizes agents into crews with shared goals and sequential task handoffs. In all these systems, the interface between agents is, at bottom, a string of natural language. The orchestration layer may add metadata, role labels, or conversation history, but the semantic content flows as text.

This design choice has a consequence that is underappreciated in the engineering literature. When two agents share an ontology, natural language is an efficient interface. When they do not, natural language is a lossy, ambiguous channel that silently absorbs ontological mismatches.

C. Semantic Interoperability

The problem of semantic interoperability, ensuring that two systems interpret shared data consistently, has been studied extensively in database integration [6], the Semantic Web [7], and service-oriented architectures [8]. The core insight from this literature is that shared syntax does not guarantee shared semantics. Two services may exchange well-formed JSON with identical field names and still assign different meanings to those fields.

LLM-based agents inherit this problem in a new form. Their "schema" is implicit in the system prompt, training data, and tool descriptions. When a dispatcher routes a task to a sub-agent, it does not transmit an explicit schema. The sub-agent infers the expected structure from context, and that inference may differ from what the dispatcher assumed.

III. THE DRIFT PROBLEM

We now formalize the drift problem. Let us define the key concepts.

Definition 1 (Agent Ontology). For agent a, we define its ontology O_a as the set of typed concepts, relations, and inferential commitments that agent a applies when processing a task. Formally, O_a = (C_a, R_a, I_a) where C_a is a set of concept types, R_a is a set of typed relations over C_a, and I_a is a set of inferential rules.

In practice, O_a is not explicitly represented. It is an emergent property of the agent's system prompt, its LLM's training distribution, its tool definitions, and the conversation history. This implicitness is the root cause of drift.

Definition 2 (Dispatch Boundary). A dispatch boundary is a point in a multi-agent pipeline where task context passes from agent a to agent b. We denote this boundary as delta(a, b).

Definition 3 (Semantic Drift). Given a dispatch boundary delta(a, b), semantic drift is the information loss that occurs when the ontological commitments of agent a are not preserved in the processing of agent b. We quantify drift as:

D(a, b) = 1 - |O_a intersect O_b| / |O_a|

where the intersection is measured over aligned concept types, relations, and inferences. When O_a and O_b share all commitments, D(a, b) = 0. When they share none, D(a, b) = 1.

This metric is defined with respect to a reference alignment. In practice, we do not have access to explicit ontologies, so we estimate drift through behavioral proxies: disagreement on task-relevant inferences, divergence in output structure, and failure to preserve constraints stated in the original task.

Definition 4 (Cumulative Drift). For a pipeline of agents a_1, a_2, ..., a_n connected by dispatch boundaries, cumulative drift is:

D_total = 1 - product_{i=1}^{n-1} (1 - D(a_i, a_{i+1}))

This quantity grows monotonically with pipeline depth and approaches 1 as n increases, assuming each boundary has nonzero drift. In the degenerate case where each boundary has drift epsilon, cumulative drift after n boundaries is 1 - (1 - epsilon)^{n-1}, which converges to 1 geometrically.

Proposition 1 (Drift Accumulation). If every dispatch boundary in a pipeline has drift D(a_i, a_{i+1}) >= epsilon > 0, then cumulative drift after n agents is bounded below by 1 - (1 - epsilon)^{n-1}. For epsilon = 0.1 and n = 8, cumulative drift exceeds 0.5.

This result is conservative. In practice, drift is not uniform across boundaries. Early boundaries often have higher drift because they carry more ontologically dense context (task decomposition, domain framing), while later boundaries carry more constrained outputs. But the accumulation property holds regardless of the distribution.

IV. MECHANISMS OF DRIFT

We identify four principal mechanisms by which semantic drift arises at dispatch boundaries. These mechanisms are not mutually exclusive; they interact and compound.

A. Context Compression at Boundaries

When a dispatcher routes a subtask to a specialist agent, it must compress the full task context into a message that fits within the specialist's context window and role specification. This compression is lossy. The dispatcher must decide which aspects of the original task are relevant to the specialist, and that decision embeds the dispatcher's (possibly flawed) model of the specialist's ontology.

For example, consider a pipeline where agent A summarizes a legal contract and passes the summary to agent B, which checks for compliance issues. If A's summary omits a clause that B would have flagged, the omission is not a hallucination. It is a compression decision made under A's ontology, which did not encode the relevance of that clause to B's task.

This mechanism is related to the information bottleneck principle [9]. The dispatcher acts as a bottleneck that must preserve task-relevant information for all downstream agents simultaneously. As the number of downstream agents grows, the compression required increases, and the probability that any single agent's needs are inadequately served rises.

B. Implicit Ontology Assumptions

Each agent in a pipeline operates with an implicit ontology derived from its system prompt, tool descriptions, and training distribution. These ontologies are rarely documented or compared. When agent A produces output intended for agent B, A makes assumptions about B's interpretive framework. When those assumptions are wrong, drift occurs silently.

We have observed this pattern in production orchestration systems. A planning agent might dispatch a task described as "analyze the financial health of company X" to a data retrieval agent. The planning agent assumes "financial health" means a specific set of metrics (revenue growth, debt-to-equity ratio, cash flow). The data retrieval agent, lacking this assumption, returns a broader or narrower dataset. The mismatch is invisible until the final output fails to meet expectations.

This problem is a variant of the frame problem in AI [10]. Each agent has a limited model of what is relevant, and those models are not coordinated.

C. Tool Description Ambiguity

Agents interact with external tools through natural language descriptions provided by the orchestration framework. These descriptions are the primary mechanism by which an agent's capabilities are defined. When tool descriptions are ambiguous, imprecise, or inconsistent across agents, the agents develop divergent understandings of what operations are available and what they do.

Recent work on tool-calling in LLMs has shown that tool description quality directly affects calling accuracy [11]. We extend this observation: tool descriptions also affect inter-agent semantic alignment. If agent A's description of a database query tool uses different terminology than agent B's description of the same tool, the two agents will develop incompatible models of the data available to the pipeline.

D. Model Vendor Differences

Multi-agent pipelines increasingly use heterogeneous LLM backends. A planner agent might run on a frontier model from one vendor, while specialist agents run on smaller or fine-tuned models from another. Each model has a different training distribution, different instruction-following behavior, and different implicit ontology [12].

This source of drift is architectural. Even if two agents receive identical prompts, their processing will differ because their underlying models differ. The differences are most pronounced in edge cases: ambiguous terms, implicit quantifiers, temporal references, and domain-specific jargon. These are precisely the cases where ontological alignment matters most.

V. A FORMAL MODEL

We now present a formal model of multi-agent dispatch that makes drift measurable and, in principle, controllable.

A. Typed Message Passing

Definition 5 (Typed Message). A typed message m is a pair (c, t) where c is the content (a string, structured data, or artifact) and t is a type drawn from a shared type system T. The type t encodes the ontological commitments that the sender makes about c: its domain, structure, intended interpretation, and constraints.

In current orchestration frameworks, messages are untyped. The content c is transmitted as a string, and the type t is implicitly assumed by both sender and receiver. When those assumptions align, the pipeline works. When they diverge, drift occurs.

Definition 6 (Ontology Alignment). Given two agents a and b with ontologies O_a and O_b, an alignment function A: O_a -> O_b is a partial mapping from concepts, relations, and inferences in O_a to their counterparts in O_b. The alignment is total if every element of O_a has a corresponding element in O_b.

When the alignment is total, typed messages can be transmitted without loss. When it is partial, some ontological commitments in the message cannot be expressed in the receiver's ontology, and drift occurs at those points.

B. Drift Metrics

We define three operational metrics for measuring drift in a multi-agent pipeline.

Metric 1 (Conceptual Overlap). For agents a and b processing a shared task, conceptual overlap measures the fraction of task-relevant concepts that both agents identify. We estimate this by comparing the entities, relations, and constraints each agent extracts from the same input.

Metric 2 (Inferential Consistency). Given the same premises, do agents a and b draw the same conclusions? Inferential consistency measures agreement on downstream inferences. Two agents may share concepts but differ in the rules they apply, leading to divergent outputs.

Metric 3 (Structural Preservation). When agent a produces output of a certain structure (e.g., a list of findings with severity ratings), does agent b preserve that structure in its own output? Structural preservation measures the fidelity of format and organization across boundaries.

C. Content-Addressed Messages

Definition 7 (Content-Addressed Message). A content-addressed message is a typed message (c, t) augmented with a hash h = H(c, t) that uniquely identifies the content-type pair. Any modification to either content or type changes the hash, providing an integrity check.

Content addressing serves two purposes. First, it detects drift: if agent b receives a message with hash h_1 but processes content that hashes to h_2, some transformation occurred at the boundary. Second, it enables provenance binding: each message carries a verifiable record of its origin and type.

VI. EVIDENCE

We draw on several lines of evidence to support our characterization of semantic drift.

A. Multi-Agent Coordination Failures

Recent empirical studies of LLM-based multi-agent systems have documented coordination failures that are consistent with our drift model. In the ChatEval benchmark [13], multi-agent debate systems showed degraded accuracy when agents had different base models, a finding consistent with the model vendor difference mechanism we described in Section IV-D.

The AgentBench evaluation [14] tested agents across multiple task types and found that performance dropped most sharply in tasks requiring inter-agent information transfer. Agents that worked well in isolation failed when their outputs were consumed by other agents, a pattern consistent with drift at dispatch boundaries.

Hong et al. [15] developed MetaGPT, a multi-agent framework that assigns standardized operating procedures to agents. They reported that encoding explicit role specifications reduced coordination failures, which is consistent with our claim that implicit ontology assumptions are a primary drift mechanism.

B. Behavioral Drift in Tool-Calling Pipelines

Work on tool-calling in LLMs provides indirect evidence for drift. Gorilla [11] showed that LLMs exhibit significant variance in how they interpret tool descriptions, and that small changes in wording lead to different calling behavior. When two agents in a pipeline interpret the same tool description differently, they develop divergent operational models, a form of drift.

Schick et al. [16] demonstrated that tool-augmented LLMs can be sensitive to the format and ordering of tool descriptions. This sensitivity means that even minor differences in how an orchestration framework presents tools to different agents can cause drift in their understanding of available operations.

C. Context Window Compression

The practical limits of context windows force compression at every dispatch boundary. Liu et al. [17] studied the effects of context compression on LLM performance and found that compression strategies that preserve semantic content for one task may discard content critical for another. In a multi-agent pipeline, the dispatcher must compress for multiple downstream tasks simultaneously, a strictly harder problem.

Lost in the Middle [18] demonstrated that LLMs attend unevenly to different parts of their input context, with information in the middle of long contexts being systematically underweighted. When a dispatcher places subtask instructions within a long context, the specialist agent may not attend to all relevant constraints, causing drift.

VII. MITIGATION STRATEGIES

We propose four architectural mitigations for semantic drift. These are not alternative solutions but complementary layers of defense.

A. Shared Typed Ontology

The most direct mitigation is to make the pipeline's ontology explicit and shared. Rather than allowing each agent to develop its own implicit model of the domain, we define a shared type system T that all agents reference. Every message passed across a dispatch boundary is typed according to T, and every agent declares which types it consumes and produces.

This approach borrows from the Semantic Web tradition of shared ontologies [7] but applies it to LLM agent communication. The type system does not need to be a full formal ontology. A well-designed set of JSON schemas or a structured type hierarchy can capture the domain-specific commitments that would otherwise be implicit.

The key design requirement is that the type system must be expressive enough to capture the distinctions that matter for the pipeline's tasks. If two agents distinguish "revenue" from "profit" but the type system conflates them under a generic "financial metric" type, the type system fails to prevent drift at that point.

B. Content-Addressed Messages

As defined in Section V-C, content-addressed messages attach a hash to each (content, type) pair. This provides three guarantees:

1. Integrity: any modification to the message is detectable. 2. Provenance: the hash links the message to its origin and type. 3. Replay: the exact message can be reconstructed and reprocessed.

Content addressing does not prevent drift, but it makes drift visible. When a downstream agent produces output inconsistent with the hash of its input, the discrepancy can be detected and traced to the specific boundary where it occurred.

C. Provenance Binding

Provenance binding extends content addressing by recording the full chain of transformations a message undergoes as it passes through the pipeline. Each agent that processes a message appends a provenance record: its identity, the input hash, the output hash, and the transformation applied.

This creates an audit trail that makes drift traceable. When the final output of a pipeline is incorrect, provenance binding allows the system to identify which boundary introduced the error and which drift mechanism was responsible.

In practice, provenance binding can be implemented as a wrapper around the orchestration framework's message-passing layer. Each message carries a provenance header that accumulates records as it traverses the pipeline.

D. Replay Testing Across Agent Boundaries

Replay testing is a validation technique in which the same input is presented to a pipeline multiple times and the outputs are compared. Variability in output across replays indicates drift: the pipeline is not deterministically preserving meaning.

More targeted replay testing focuses on individual boundaries. We replay the same message through a single dispatch boundary and measure whether the receiving agent produces consistent interpretations. High variance at a specific boundary identifies it as a drift hotspot.

Continue reading

Explore more research from PaxLabs on reliable agentic systems.