Skip to content

SubAgentActor: tool file paths don't contribute to parent session WorkingContext #600

@Aaronontheweb

Description

@Aaronontheweb

Summary

SubAgentActor runs an independent LLM turn loop (ephemeral child of the parent session actor) and executes tool calls within its own _history list. File paths touched by sub-agent tool calls (file_read, file_write, file_edit, or any future path-taking tool) are discarded when the sub-agent stops — they never reach the parent session's WorkingContext.RecentFiles.

This is a gap discovered during investigation of the working-context-grounding change (PR #598). The fix for durable WorkingContext grounding applies only to LlmSessionActor; sub-agents (Task/Explore/etc. style delegations) have no integration with it.

Concrete impact

If a parent session delegates work to a sub-agent that reads 5 files to produce a summary, then the parent compacts:

  • Pre-fix (today): Zero file paths from the sub-agent show up in [working-context] after compaction. The parent agent loses all grounding on what the sub-agent looked at.
  • Post-fix (this issue): Paths touched by the sub-agent flow back into the parent session's WorkingContext before the sub-agent stops.

This matters most when sub-agents are used for exactly the tasks they're designed for — compressing high-volume tool work into a single summary handed back to the parent. The parent then has no idea what the sub-agent looked at, and compaction destroys any trace.

Source locations

  • src/Netclaw.Actors/SubAgents/SubAgentActor.cs — ephemeral actor with its own _history list, no WorkingContext field
  • src/Netclaw.Actors/Protocol/SubAgentMessages.csSubAgentResult protocol message returned to parent; no working-context field
  • src/Netclaw.Actors/Sessions/WorkingContextUpdater.cs — current updater, hardcoded to consume SerializableChatMessage tool results from session history

Proposed design (not binding)

Two options worth considering:

Option A — sub-agent emits a recent-files list in its result.
Add ImmutableList<string> RecentFiles (or a minimal WorkingContext) to SubAgentResult. SubAgentActor runs the same path-extraction logic as LlmSessionActor against its ephemeral history. On SubAgentResult receipt, parent session actor merges the sub-agent's list into its own WorkingContext (each path threaded through AddRecentFile in order, so the head-short-circuit and ring-buffer behavior still apply).

Option B — refactor WorkingContextUpdater to be shared, sub-agent merges via separate message.
Factor out a WorkingContextAggregator (or similar) that both actors call. Sub-agent emits a SubAgentWorkingContextUpdate message to parent during execution or on stop.

Option A is smaller and matches the existing return-value contract. Option B is more flexible if sub-agents need to stream updates.

Acceptance criteria

  • Sub-agent file reads/writes/edits contribute to parent session's WorkingContext.RecentFiles in the same order they were touched
  • Paths appear in [working-context] block on the next turn after sub-agent completion
  • Survives compaction on the parent session
  • Integration test: parent spawns sub-agent that reads 3 files, parent's next FireLlmCall includes those paths in the context block
  • No behavior change for sessions that don't use sub-agents

Out of scope

  • Preserving the sub-agent's full summary/grounding across compaction — that's conversation content, and sub-agent results are designed to be compressed into a single message anyway
  • Multi-level nesting (sub-agent spawning sub-agent) — follow the same merge contract transitively if it already works

Reference

Discovered during review of PR #598 (working-context-grounding). Related issues on milestone 0.12: #595 (CWD tracking), #596 (tool path resolution against session CWD).

Metadata

Metadata

Assignees

No one assigned

    Labels

    subagentsspawn_agent, SubAgentActor, definition loader, discovery context layer, and related features

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions