Inner Context Plane
The Inner Context Plane gives the delegate first-class awareness of activity inside its own subsystems. Memory recall, memory consolidation, completed Copilot tasks, timers, and future background processors all enter through the same plane as inner signals: context from the delegate’s components, not messages from the user.
This creates one coherent way for the delegate to notice that it remembered something, learned something, reached a scheduled moment, or received the result of delegated work. The single base agent remains responsible for deciding what the signal means and whether to act.
How it works
Delegate 1 keeps user communication and background activity distinct:
- Outer context comes directly from the user through text, voice, phone, SMS, or email.
- Inner context comes from memory and other agent subprocessors.
- Working context combines the relevant parts of both with standing memories, prompt instructions, and time.
An inner signal is never represented as a user statement. Subprocessors report what happened; the single base agent interprets the signal and uses its existing tools when action is useful.
flowchart LR
User[User channels] --> Context[Working context]
Memory[Memory] --> Inner[Inner Context Plane]
Tasks[Copilot tasks] --> Inner
Timers[Timers] --> Inner
Inner --> Context
Context --> Agent[Base agent]
Agent --> Tools[Existing tools]
Attention
Not every background event starts a model run. Each signal declares how it enters awareness:
| Mode | Behaviour |
|---|---|
ambient |
Retained and included only when relevant to later work |
next-turn |
Included the next time the base agent runs |
wake |
Starts an autonomous turn when the base agent is idle |
interrupt |
Interrupts current work; reserved for exceptional, urgent conditions |
The Attention Broker may batch related signals so several subprocess completions produce one coherent awakening rather than competing model calls.
Signal lifecycle
- A subprocessor publishes an inner signal.
- The signal is written to a durable journal.
- The Attention Broker applies timing, priority, deduplication, and batching rules.
- The Context Composer uses the activation, including selected signals and the current time, as a cue for passive memory retrieval.
- The selected signals and recalled memories enter working context separately from user messages.
- The base agent applies its prompt, then acts with existing tools or dismisses the signal.
- The outcome is recorded and failed delivery remains retryable.
Only one base-agent activation may run at a time. A user turn takes precedence over background awareness, except for explicitly permitted interrupt signals.
Activation and recall
Every base-agent activation follows the same context-composition path, whether it begins with a user message or an inner signal. A timer wake therefore carries its identity, scheduled time, recurrence, and purpose into passive memory retrieval before the model runs. Memories such as “when the periodic review wakes, check outstanding commitments” can surface naturally from that cue and guide the agent through its existing tools.
Timers do not encode those behaviours or map schedules to actions. They only publish that a scheduled moment is due. The shared retrieval and prompt path supplies learned intent, so the same mechanism also works for task completions, consolidation events, and future signal sources.
Signal sources
| Source | Typical signals |
|---|---|
| Memory | Consolidation, conflict, and override outcomes |
| Copilot Tasks | Completion, input required, and failure |
| Timers | Scheduled work becoming due |
| External processors | Status or results delivered through trusted HTTP or MCP adapters |
The durable journal gives the delegate a truthful history of its background activity. For example, it can describe recent consolidation runs from recorded memory signals rather than reconstructing them from conversation transcripts.
Brand-new memory inserts do not wake the agent. Consolidated, conflicting, and overridden memories do, because they represent a meaningful relationship with existing knowledge. This avoids a feedback loop where every ordinary extraction starts another autonomous activation.
Logs and UI
- Server logs use structured
[inner-context]lines for publication, deduplication, batch activation, completion, and failure. Each publication includes the stable signal ID, kind, source, and awareness mode. - The conversation timeline is the primary operator view. It shows expandable internal-activity entries in sequence with memory recall, tool calls, tool results, and the assistant’s response.
- Activation entries retain the full claimed batch: stable IDs, kinds, sources, awareness modes, priorities, attempts, creation times, payloads, and the composed inner-context envelope.
- Signals consumed by a genuine user turn appear as
Inner context attached to user turn; autonomous work appears as started followed by completed or failed. - Replayed history rebuilds the same sequence from durable conversation events, including recalled memory content and activation duration or error. Inner context is never rendered as a user message.
The UI also uses the Inner Plane label for internal context operations that are observable but are not themselves wake signals:
| Event | Meaning |
|---|---|
| Memory retrieval | Pending, miss, or recalled memories injected into working context |
context.usage |
Responses or Realtime token usage recorded for the turn |
context.compacted |
Official Responses compaction completed |
context.capsule |
Continuity capsule refresh started, completed, or failed |
This is a presentation category, not a claim that token usage or compaction passed through the Attention Broker. Usage, compaction, and completed capsule events replay from durable conversation events; capsule started and failed notifications are live-only. All remain distinct from user messages.
Prompt and memory
The plane supplies awareness, not behaviour. Code handles persistence, timing, ordering, concurrency, and trust boundaries. The prompt and standing memories determine whether a signal deserves action, which existing tool to use, and whether the user should be contacted.
This allows instructions such as “email me when consolidation teaches you something new” to be learned as memory instead of implemented as a dedicated tool or hardcoded workflow.
Technical details
- Signals carry a stable ID, namespaced kind, source, timestamps, priority, awareness mode, structured data, and processing state.
- Signals are stored separately from user conversation transcripts and never enter the model as user-role input.
- Processing is serialized so background activity cannot replace an active user request.
- Repeated callbacks are deduplicated, failures are bounded and retryable, and context composition is size-limited.
- Untrusted external content is labelled and delimited; it cannot elevate itself into system instructions.
- ThoughtFlow records the signals selected for a run, the agent’s decision, tool actions, and final disposition.