Context Engine — agent-core to Exo Mapping

Epic: 4 — Context Engine Enhancements Date: 2026-03-10

This document maps agent-core’s (openJiuwen) context engine to Exo’s enhanced exo-context package, helping contributors familiar with either framework navigate both.

1. Agent-Core Overview

Agent-core’s context engine lives in openjiuwen/core/context_engine/ (also referenced as context/) and provides layered context management for long- running agent conversations.

Key Components

ContextManager — The central orchestrator that coordinates all context operations. Manages the conversation history buffer, delegates to specialized managers for offloading, compression, and windowing, and enforces token budgets before LLM calls.

OffloadManager — Handles message-level offloading for oversized content. When a message exceeds a configurable character threshold, the manager replaces it with an [[OFFLOAD: handle=<id>]] marker and stores the original content for on-demand retrieval. This keeps the active context small while preserving access to full content when needed.

CompressManager — LLM-based dialogue compression. Detects verbose tool-call chains (sequences of assistant messages with tool_calls followed by tool results) and replaces them with concise summaries generated by an LLM call. Dramatically reduces context size for multi-step tool use without losing semantic content.

RoundManager — Round-level windowing that understands dialogue structure. Defines a “round” as a user message through the next assistant response without tool calls. Trims history to the most recent N rounds while preserving complete round boundaries, preventing mid-conversation truncation that confuses models.

TokenBudgetManager — Accurate token counting and enforcement via tiktoken. Supports two encodings:

Counts tokens for all messages in history and trims oldest messages when the total exceeds a configurable budget, acting as a final safety net.

ContextConfig — Configuration dataclass controlling all context behavior:

Processing Order

Agent-core applies context management in this sequence before each LLM call:

1. Offload oversized individual messages
2. Compress verbose tool-call chains
3. Window to recent N rounds
4. Summarize if threshold exceeded
5. Enforce hard token budget

2. Exo Equivalent

Exo’s context engine lives in the exo-context package (packages/exo-context/) and implements the same capabilities as event-driven ContextProcessor subclasses that plug into a ProcessorPipeline — no monolithic manager needed.

Architecture Difference

Where agent-core uses a single ContextManager that calls specialized managers in sequence, Exo uses a composable processor pipeline:

# Agent-core: monolithic manager
context_manager = ContextManager(config)
context_manager.process(history)  # calls all managers internally

# Exo: composable pipeline
pipeline = ProcessorPipeline()
pipeline.register(MessageOffloader(max_message_size=10_000))
pipeline.register(DialogueCompressor(summarizer=my_summarizer))
pipeline.register(RoundWindowProcessor())
pipeline.register(SummarizeProcessor())
pipeline.register(TokenBudgetProcessor(max_tokens=100_000))
await pipeline.fire("pre_llm_call", ctx, {})

Each processor is independent, opt-in, and can be registered in any order (though the recommended order matches agent-core’s sequence).

Component Mapping

Key Exo Additions Beyond Agent-Core

Hierarchical Context (Context + ContextState) — Exo introduces a fork/merge lifecycle for task decomposition. A parent context can fork() child contexts that inherit state but write in isolation. On merge(), the child’s state changes and net token delta flow back to the parent.

Automation Modes — ContextConfig.mode supports three presets:

Context Tools — Agents can self-manage their context via built-in tools: reload_offloaded(handle) retrieves offloaded content, planning tools manage a task checklist, knowledge tools search workspace artifacts, and file tools provide safe filesystem access.

3. Configuration Comparison

Agent-Core ContextConfig

# openjiuwen/core/context_engine/config.py
@dataclass
class ContextConfig:
    max_history_rounds: int = 20
    summary_threshold: int = 10
    offload_threshold: int = 50
    max_tokens: int = 100_000
    encoding: str = "cl100k_base"

Exo ContextConfig

# exo-context: config.py
@dataclass(frozen=True)
class ContextConfig:
    mode: AutomationMode = "copilot"    # pilot / copilot / navigator
    history_rounds: int = 20            # ≡ max_history_rounds
    summary_threshold: int = 10         # same semantics
    offload_threshold: int = 50         # same semantics
    enable_retrieval: bool = False      # RAG integration toggle
    neuron_names: tuple[str, ...] = ()  # prompt composition neurons
    extra: dict[str, Any] = field(      # extensible — token_budget, encoding, etc.
        default_factory=dict
    )

Field Mapping

Factory Function

Exo provides make_config(mode, **overrides) to create configs with sensible defaults per automation level, avoiding manual threshold tuning:

from exo.context import make_config

config = make_config("navigator")  # aggressive compression settings
config = make_config("pilot")      # minimal processing, large context window

4. Migration Table

All public symbols are re-exported from exo.context (the package __init__.py), so from exo.context import MessageOffloader works as a convenience import.

Processor Event Mapping