Context Compaction
In a multi-agent system, every agent maintains its own context window — and that context grows with each message exchanged between teammates. A team of five agents discussing a problem generates five times the context pressure of a single agent working alone. Without management, conversations quickly exceed the LLM's token limit and agents lose access to earlier information.
Context compaction solves this by progressively compressing conversation history while preserving essential facts, decisions, and discoveries. It runs automatically — agents are not aware that compaction is happening.
The net result: endless conversations without catastrophic forgetting. By selectively compressing what matters and dropping noise, the system effectively triples or quadruples the usable context window — a model with a 1M token window handles the dense, actionable equivalent of 3–4M tokens of raw conversation. And because relevant findings are routed into permanent memory, nothing of value is ever lost, even across sessions.
Why Per-Agent Context Matters
Each agent in a team sees a different conversation. When Agent A sends a private message to Agent B, only those two agents see it. Agent C sees the team-wide messages but not the private exchange. This means every agent has its own unique view of the conversation history.
Compaction respects this. Each agent's context is managed independently — summaries are tailored to what that specific agent actually saw. This is especially important for side conversations that break out of the main round table: two agents can have a detailed private discussion, and only their context windows absorb the cost.
How It Works
Compaction works in layers, each handling a different kind of context pressure. Earlier layers are cheap and reduce pressure so the more expensive ones fire less often.
-
Stale tool results are set aside first. Tool calls often return large payloads (API responses, search results, file contents) that are critical when fresh but become noise once they're old. These are set aside automatically as they age — a cheap step with no AI cost. The system keeps the results an agent is still relying on and clears the ones that have served their purpose, so important findings stay available longer while spent lookups are cleared faster. Anything set aside can be restored in full the moment it's needed again, so nothing is lost.
-
Older messages are selectively compressed. Rather than blindly summarizing the oldest messages, the platform assesses each message's relevance: substantive content is compressed into a dense summary, while low-signal chatter — routine acknowledgments, redundant status updates — is dropped entirely. The summaries preserve what matters: the facts and decisions reached, who said or discovered what, specific details like numbers and references, and narrative continuity so each summary builds on the last. The agent keeps working with full awareness of what happened — it just reads a summary instead of the raw transcript.
-
Task transitions get clean boundaries. When one workflow stage completes and the next begins, each agent starts the new task with a focused summary of what was accomplished rather than the raw history. This prevents cross-task context bleeding — a common failure where agents see completion messages from an earlier task and prematurely conclude the current one is done too.
-
Relevant findings persist beyond the session. The first three steps manage context within a single run. When a project has Long-Term Memory enabled, the knowledge discovered during a run is also routed into the permanent knowledge graph — so a team six months later can query it and find what an earlier team learned. This is what turns per-session compression into lasting organizational memory.
Session-to-graph persistence only activates when the project's knowledge source is set to Open. In Curated Mode, only user-uploaded documents feed the knowledge graph — workflow activity is excluded. This is useful for projects like documentation chatbots where the graph should contain only verified content.
Why Multi-Agent Stays Affordable
Multi-agent teams are powerful, but naively they multiply cost: five agents re-reading a growing shared history every turn would burn several times the tokens of a single agent. Context management is what keeps a team economical, and it works on three fronts:
-
Less to process. Compressing history into dense summaries and shedding noise means each agent works from a fraction of the raw transcript — the same effect that expands the usable window 3–4× also shrinks what has to be sent on every turn.
-
Reuse instead of re-read. Over the many turns of a conversation, the settled part of an agent's context doesn't change from one turn to the next — so it's reused rather than reprocessed from scratch. You pay full rate for genuinely new content and only a small fraction for everything the agent has already seen. On long, multi-turn runs this is the single biggest cost lever.
-
Scoped conversations. A side conversation between two agents only touches those two agents' context windows — the rest of the team pauses and spends nothing. Cost tracks the work actually being done, not the size of the team.
Together these mean a five-agent team doesn't cost five times a single agent: the shared, settled context is compressed and reused, so much of the team effectively runs at the cost of one.
Compaction Presets
Each agent is assigned a compaction preset that controls how aggressively compaction fires — a trade-off between how much recent context the agent keeps verbatim and how lean its context stays. Choose based on how much history the agent needs versus how long its conversations run.
| Preset | Behavior | Best For |
|---|---|---|
| Aggressive | Compacts most often, keeps the fewest recent messages verbatim | Long iterative stages, cost-sensitive runs |
| Strong | Compacts often | Multi-cycle stages with moderate context needs |
| Standard | Balanced (default) | General-purpose agents |
| Careful | Compacts rarely, keeps the most recent history verbatim | Detail-sensitive analysis, complex reasoning |
| None | Never compacts — full history retained | Short tasks where the whole conversation fits |
Choosing a preset
- Aggressive/Strong — Use for agents in long-running iterative loops (e.g., a coding agent that runs many tool calls per stage). Token costs stay low and the agent keeps a working summary of what happened.
- Standard — The safe default. Works well for most conversational agents with moderate interaction counts.
- Careful — Use for agents doing complex analysis where losing earlier details would degrade quality (e.g., a research agent cross-referencing multiple sources).
- None — Use only for short tasks where you know the conversation will fit in the context window.
Setting compaction to None on an agent assigned to long-running stages risks context window overflow. When the window fills, messages are hard-truncated from the beginning — which is worse than compaction because no information is preserved at all.
Context Window Sizing
There are no hardcoded limits. The platform reads the agent's resolved LLM model to determine its actual context window, and compaction paces itself to how full that window actually is — not to a fixed message count. Assign a model with a large window and the agent holds more history before compacting, so it compresses less often and works from more raw context; put the same agent on a smaller model and it tightens up automatically. This is configured per agent, so an agent assigned to multiple stages uses the same compaction settings everywhere.
- Configure an Agent — includes compaction preset selection
- Communication Flow — how agents talk and why per-agent context matters