Dynamic Context Reconstruction#
Dynamic Context Reconstruction (DCR) is Nebula's approach to agent context management. Instead of maintaining a running conversation thread, the platform assembles each agent's context window from scratch on every invocation.
The Problem with Conversation Windows#
Every major agent framework treats context as a sequential list of messages. This fails in two ways:
- Context pollution — as agents work, the window fills with irrelevant content: superseded decisions, discarded plans, early clarifications. Signal-to-noise drops.
- Context isolation — when a research agent hands off to a development agent, the dev agent starts cold. Relevant context is locked inside the other agent's thread.
In a multi-agent system, both problems compound. Agents end up simultaneously overloaded with irrelevant history and starved of relevant context from peers.
How DCR Works#
Instead of appending to a conversation, Nebula stores all messages as independent records in a structured database. When an agent is invoked, the system assembles its context window by selecting messages based on:
- Agent role — what this agent is responsible for
- Project scope — which project and milestone is active
- Recency — recent messages weighted higher, but not exclusively
- Relevance signals — messages explicitly addressed to this agent, unresolved tasks, outstanding questions
The agent never sees stale decisions from three hours ago unless they're still relevant. It does see a peer agent's findings if they were directed its way.
Messages as Records, Not Threads#
For DCR to work, messages can't be locked inside conversation threads. Nebula uses conversation-unbound messages — messages that exist as independent records, not inside specific conversation silos.
An agent can @mention a peer, broadcast a finding to a project, or send a direct message — and any of these can surface in another agent's context window if the assembly logic determines it's relevant.
Trade-Offs#
DCR is not free:
- Latency — context assembly adds 50–150ms per call depending on database size
- Complexity — requires a structured message store and assembly logic that understands agent roles and project structure
- Not bolted on — you can't add this to an existing chat API wrapper; it's a fundamental architecture choice
For short, single-agent conversations, a conversation window is fine. For persistent agent teams on long-running projects, DCR prevents the degradation that conversation windows inevitably produce.