Feature request: forward parent session's Signet memory context to sub-agents at spawn time

[adampaulsen]

Feature Request: Signet Memory Context Injection for Sub-agents

Summary

When a parent agent session spawns a sub-agent, the sub-agent currently starts with zero Signet memory context. It inherits the workspace directory but does not receive Signet's memory injection — no relevant memories, no entity graph context, no anticipatory recall. This means every sub-agent starts from scratch on every task, even when the parent session has rich accumulated context directly relevant to what the sub-agent is doing.

Current Behavior

• Parent session: receives Signet memory injection on every prompt (entities, relevant memories, anticipatory recall)
• Sub-agent session: starts cold — no Signet context, no memory injection
• Parent must manually summarize relevant context in the task description to compensate

Desired Behavior

An option to forward the parent session's Signet memory context to sub-agents at spawn time, so sub-agents can benefit from the same accumulated knowledge without requiring the parent to re-describe everything.

Use Cases

1. Domain-aware sub-agents
When a parent agent spawns a sub-agent to audit Juniper switch configs, the sub-agent should know that this user runs an EX4300 and EX2200, what VLANs are in use, what issues have been flagged before — without the parent having to paste all of that into the task description.

2. Consistent voice/persona
When a sub-agent drafts an email or document, it should know the user's writing style preferences, communication history, and context — the same way the parent agent does.

3. Codebase-aware sub-agents
When a sub-agent is asked to work on a specific project, it should have the same project context that's been accumulated in Signet (architecture decisions, past bugs, conventions) rather than starting blind.

4. Multi-step workflows
In long-running workflows where the parent spawns multiple sub-agents sequentially, each sub-agent currently needs the parent to re-inject context. Signet context sharing would make these workflows significantly more capable.

Proposed Implementation

Option A: Full context forwarding (opt-in)

At spawn time, pass a flag like signet_context: "inherit" that causes the sub-agent's first prompt to include the same Signet memory injection the parent received. This is a one-time snapshot — the sub-agent doesn't get ongoing memory updates, just the parent's current context.

Option B: Scoped context forwarding

The parent specifies which memory/entity categories to forward:

signet_context:
  memories: true
  entities: ["Juniper", "network", "homelab"]
  top_k: 20

Option C: Shared session scope

Sub-agents spawned with signet_scope: "parent" share the parent's Signet session scope, receiving ongoing context injection as if they were the same session. More powerful but potentially more complex to implement.

Option A is the simplest starting point and would cover the majority of use cases.

Configuration Sketch

In agent.yaml or spawn parameters:

memory:
  pipelineV2:
    subagents:
      inheritContext: true      # forward parent context to sub-agents
      inheritTopK: 15           # how many memories to forward
      inheritEntities: true     # include entity graph context

Or as a per-spawn flag in the harness:

sessions_spawn({
  task: "...",
  signetContext: "inherit"   // or "none" (default)
})

Expected Impact

• Significantly reduces the burden on parent agents to manually re-describe context in task descriptions
• Makes sub-agents first-class citizens in the Signet memory system
• Enables more capable multi-agent workflows without context loss at agent boundaries
• Particularly valuable for long-running tasks where the parent has accumulated substantial session context

Related

• Sub-agents currently inherit the workspace directory (~/.agents/) but not the memory injection
• This is consistent with how Signet handles new sessions generally — but sub-agents are a different case since they're explicitly spawned by a context-rich parent, not a fresh user session

---

Reported by: Adam Paulsen via Sam Bridger (OpenClaw agent)

[NicholaiVogel]

hey Adam, thanks for writing this up.

looked into it and went a different direction from the token-based approach. engine-managed, nothing the agent has to explicitly do. the daemon figures out the parent-child relationship automatically using whatever signal the harness exposes natively: CC has agent_id on sub-agent hook payloads, OpenClaw encodes lineage in the session key, OpenCode passes parentID in session events. Codex doesn't expose anything useful externally so that one degrades gracefully.

there's also a prerequisite fix baked in. transcripts currently only get written at session end, so an active session is dark to anything running alongside it including its own sub-agents. fixing that is what makes the rest possible.

spec's written, picking this up next sprint.

[adampaulsen]

Fantastic! Thanks Nicholai!