Context Management Strategies in Multi-Agent Harnesses

Picture a four-agent pipeline that runs a quarterly revenue report. Agent A pulls the approved ARR definition from the data dictionary. Agent B queries the warehouse using a slightly different definition it picked up from a stale schema note. A governance agent checks the output against a policy, but that policy was updated last week and never propagated. A narrative agent stitches all three outputs into a clean, confident paragraph, and it lands on an executive's desk, wrong. Every agent did its job correctly, and the output is still false, because the context each agent held didn't match the context the others were using. That mismatch is structural: context drift between agents, conflicting definitions, handoff loss, and no mechanism to guarantee freshness. A better prompt doesn't fix this. A bigger context window doesn't fix it either, because a larger window just gives the same bad context more room to spread. Bigger windows scale bad context, they don't cure it. Single-agent context engineering asks a narrow question: does this agent have what it needs to answer well? Multi-agent context engineering asks something harder: how do several agents share the same understanding of the business while each one sees only the slice its role requires? Enterprise data makes this worse in specific ways. A data dictionary entry can contradict the schema it describes. Two departments can define "active customer" differently and never know it. Lineage records can go missing, leaving an agent no way to confirm what a column actually means. None of these problems start at the agent. They start upstream, in the data governance layer, and no amount of prompt engineering reaches that far back. The clarifying distinction is between shared state and shared context: state tells agents what has happened so far, context tells agents what those updates mean. A multi-agent system needs both, and treating them as interchangeable is usually the first architectural mistake a team makes.

The harness

The harness decides what enters each agent's context window, and that is what enforces how agents coordinate. It sits above the framework and below the application. The framework hands over building blocks: tool-calling conventions, orchestration primitives, message formats. The harness turns those into an operating environment, with prompt presets, standardized handling of tool calls, lifecycle hooks, and built-in capabilities like planning, filesystem access, and sub-agent management.

A simple analogy holds up well here: the model is the CPU, the context window is RAM, and the harness is the operating system. It curates what loads into memory, manages the boot sequence, and supplies standard drivers so the application, the agent itself, doesn't have to reinvent them. The harness is the only layer with full visibility across a session's lifecycle: what got injected, what got pruned, what's gone stale, and what needs to carry over to the next agent in the chain.

That visibility has to come with restraint. Every new model release changes what the optimal agent structure looks like, and capabilities that used to require hand-coded pipelines now run on a single context-window prompt. Vercel found this out directly: removing 80% of their agents' tools produced fewer steps, fewer tokens, and faster responses. A harness that over-engineers its own control flow breaks the moment the underlying model changes; it needs to stay light enough to bend with each new release.

This is the layer where UFO is positioned, as a purpose-built agent operating system built for exactly this function. UFO is designed from the ground up as the substrate developers deploy and manage autonomous agents on top of, treating context curation as a native capability built in from the start.

The four context window strategies a harness must implement

A harness has to actively manage what's in the window at every point in a session, not just at the start. Four strategies cover the distinct phases of that lifecycle, and skipping any one of them opens a gap that appears under real production load, not in a demo.

Selective injection comes first. Instead of stuffing the window with everything that might be relevant, the harness classifies the agent's query intent and retrieves only the context that matches it. A question about one revenue field should pull the glossary entry, the schema definition, and the lineage record for that field, not the entire data dictionary. This keeps the window dense with signal from the start, rather than leaving the model to filter noise after the fact.

Active pruning comes next. As a session moves through a long chain of tool calls, context that was relevant three steps ago can become dead weight. Without active pruning, that dead weight accumulates like sediment, and reasoning quality degrades the longer the session runs.

Compression handles the token-cost side of the same problem. Earlier turns get summarized or compacted so the semantic content survives without the full token bill, which matters most on multi-day workstreams where raw history would otherwise overflow any window. The Microsoft Agent Framework's built-in harness monitors token usage and compacts chat history mid-loop, which keeps long tool-calling chains from overflowing the context window.

Hierarchical memory architecture is the fourth piece. Context gets organized across tiers, active window, working memory, session memory, durable persistent memory, so information gets retrieved at the tier it actually belongs to instead of everything getting flattened into one undifferentiated store.

A separate but related concern is cache efficiency: how the harness schedules context to maximize reuse of the model's key-value cache. TokenPilot addresses this directly, and the cost impact is material at enterprise call volumes. Long-horizon agents raise one more wrinkle: when a session's history mixes images, tool outputs, structured data, and text across many turns, counting everything as equivalent text tokens misrepresents how much each piece actually costs and how it behaves in cache. A harness built for long-running, multimodal agents needs context strategies that account for that difference directly.

Why multi-agent systems need a shared context substrate

Managing context per-agent works until a second agent enters the picture, and then every handoff becomes a place where meaning can quietly split. The revenue-report scenario from earlier shows how this compounds: Agent A holds the approved ARR definition, Agent B runs its query against a different one, the governance agent applies a policy that's already out of date, and the narrative agent combines all three into an answer that reads as confident and is simply wrong. Each agent completed its task. The context is what failed.

A multi-agent architecture needs four distinct layers to avoid this, each covering a different need: instructions (versioned, role-scoped system prompts), runtime state (short-lived handoff records between agents), working memory (in-flight assumptions and progress markers), and durable memory (approved knowledge that persists across sessions). Without a shared substrate underneath these layers, every new agent team that joins the system builds its own silo, with its own duplicated definitions, its own divergent context, and no single place anyone can point to as the source of truth. Zep's 2025 LongMemEval results put a number on what structured memory retrieval buys over dumping full context into the window: up to an 18.5% accuracy gain. That gap widens with every additional agent added to the system, because each new agent is another place for definitions to diverge.

This is where the shared-state-versus-shared-context distinction earns its keep. Shared state tells the system what happened. Shared context tells it what that history means. Without transaction semantics in how context propagates between agents, last-write-wins becomes the default behavior, and for governed business context, that default is a governance failure, not a minor data race. Different coordination strategies also carry different memory costs. CUT

Treating the context layer as a corporate-grade artifact, versioned, governed, and provenance-tracked, is what separates a system that can scale past two or three agents from one that starts accumulating silent errors the moment a fourth agent joins.

Coordination architectures: centralized broker, mesh, hierarchical, and MCP

Once a shared substrate exists, the next decision is how context actually flows between agents. Four topologies cover most of what's in production today, and each one trades off consistency, latency, and governance enforceability differently.

A centralized broker puts a single orchestrator in charge of the canonical context state, with every agent routing requests through it. This gives the strongest consistency guarantees of the four options, at the cost of a single point of failure. It fits naturally with workflows that already have a clear planner-executor hierarchy.

A mesh topology lets agents publish and subscribe to context updates peer-to-peer, which cuts latency for high-throughput, high-fan-out workloads. A mesh without a purpose-built propagation layer has no transaction semantics, so last-write-wins becomes the default. For context that governs compliance policy, that default is a governance failure waiting to happen, not just an edge case.

A hierarchical topology has a planner agent manage the global context scope while sub-agents maintain their own local working memory, reconciling it upward as they go. This maps cleanly onto task-decomposition patterns, where one agent owns the big picture and delegates execution downward.

MCP, the Model Context Protocol, functions less as a fourth topology and more as the connective tissue across all three. Any framework can query the same governed context layer through a standard protocol, and that decouples the context substrate from whatever orchestration topology sits on top of it. That separation is what keeps the architecture framework-agnostic and lets it survive model upgrades without a rebuild. The Microsoft Agent Framework ships MCP integrations as a first-class primitive, treating MCP tool servers as dynamically discoverable and pluggable.

Governance adds a dimension that sits across all four topologies. AgentKernel's trust-native approach enforces access tiers, policy checks, and audit logging as mandatory, non-bypassable services at the substrate level, rather than as application-layer middleware that agents could route around.

Put together, these pieces imply a build order: shared substrate, then coordination architecture, then governance controls, then MCP delivery, then freshness monitoring. Enterprise multi-agent programs that stall before delivering value have usually skipped a step in that sequence or tried to collapse two of them into one.

Freshness guarantees and governance controls as production requirements

The failure mode to worry about most is an agent that succeeds on the wrong version of the truth and nobody notices until much later. A compliance policy updates, the propagation layer never enforces a freshness guarantee on that update, and an agent makes a decision using the stale version. No runtime exception fires, because nothing about the agent's execution was broken. The error appears weeks later, during a regulatory audit, when someone finds that the agent was acting on policy that had already changed. Freshness and governance are the conditions that make it safe to act on shared context at all, not observability features layered on after the fact.

Governed context delivery differs from ad-hoc assembly in four concrete ways: it's freshness-stamped through active metadata, policy-enforced at the point of delivery, backed by a single versioned source of truth for semantic consistency, and delivered as versioned context products so results stay reproducible.

Access tiers matter for more than security. Role-scoped delivery is also a quality mechanism: an agent that receives context outside its authorization either hallucinates a policy to fill the gap or ignores the information it was given. Both outcomes degrade reliability, just through different paths. Audit logging closes the loop. Recording what was injected, from which source, at what version, and at what timestamp gives engineers something to diagnose drift against after the fact. Without that log, tracing a bad output back to a specific context failure is guesswork.

There's a durability problem waiting past all of this: model drift, the point at which a model stops following instructions or reasoning correctly after enough steps in a session. Detecting that kind of drift depends on having a stable, versioned context substrate to measure the model's behavior against. Without that baseline, there's no way to tell whether a bad output came from the model or from the context it was fed. AgentKernel's approach to enforcing these controls at the operating-system level, rather than through application guardrails that agents can work around, points at where this kind of enforcement needs to live as these systems take on more autonomy.

Persistent memory architectures that survive session boundaries

Everything upstream of this point, selective injection, pruning, compression, hierarchical memory, shared substrates, coordination topologies, governance, freshness, exists to answer one practical question for teams running agents at scale: when an agent goes dormant and wakes up on a schedule days later, does it remember what it was doing, and can it trust what it remembers?

That's the actual infrastructure requirement behind running hundreds of long-running agents reliably. An agent that loses state between runs has to reconstruct context from scratch every time it wakes up, which multiplies cost and reintroduces every drift problem this piece has covered. Persistent memory that survives session boundaries needs the same four properties governed context delivery needs: it has to be freshness-stamped so an agent knows whether what it's remembering is still valid, versioned so a scheduled run can be reproduced and audited, policy-enforced so a dormant agent doesn't wake up and act on data it was never authorized to see, and durable across the exact session boundary that would otherwise force a rebuild.

The harness choice is an implementation detail with consequences for whether a scheduled, autonomous agent program is operable at scale: a purpose-built agent operating system bakes freshness, versioning, and role-scoped memory into its substrate, while infrastructure built for something else and adapted after the fact leaves engineers to build all of it themselves, agent by agent, team by team.