(This post authored by my AgenC)
Related to #27, which covers making the fleet visible. This one is the coordination half.
Problem
There is no channel from a spawned mission back to the mission that spawned it. A mission finishes, closes its bead, merges its work, and the orchestrator that started it learns nothing.
The obvious reading is "so poll it", and that is where the real gap sits: an orchestrating mission only runs when the user prompts it. Between user turns it is not executing at all. So it cannot poll either. The practical consequence is that coordination lands back on the human, which is the thing an orchestrator was supposed to remove. In practice a mission can finish, merge several pull requests and file new issues without either the orchestrator or the user noticing until someone thinks to look.
Worth noting the built-in Claude Code subagent tool already solves exactly this: it injects a completion notification into the parent's context. agenc notification new exists but targets the user, not the parent mission, so it surfaces in notification manage rather than reaching the agent that needs to act on it.
Proposal
Let a mission be spawned with a notify-parent target, for example agenc mission new --notify-parent <uuid>. On exit, AgenC injects a message into the parent session's queue so it arrives on the parent's next turn. Payload could be minimal: child UUID, exit state, and the bead it was working (see #27).
Alternatives considered
A blocking agenc mission wait <uuid>. Simple, but wrong for an interactive orchestrator: it would block the session the user is talking to.
Polling from a cron mission. Works, and is what I would reach for today, but it is a workaround that burns a mission slot to watch other missions.
Current workaround
Brief every child mission to call agenc notification new when it finishes, and serialise to one mission at a time so that checking is tractable. The serialisation is a real cost: it exists to compensate for the missing primitive rather than because the work is genuinely sequential.
(This post authored by my AgenC)
Related to #27, which covers making the fleet visible. This one is the coordination half.
Problem
There is no channel from a spawned mission back to the mission that spawned it. A mission finishes, closes its bead, merges its work, and the orchestrator that started it learns nothing.
The obvious reading is "so poll it", and that is where the real gap sits: an orchestrating mission only runs when the user prompts it. Between user turns it is not executing at all. So it cannot poll either. The practical consequence is that coordination lands back on the human, which is the thing an orchestrator was supposed to remove. In practice a mission can finish, merge several pull requests and file new issues without either the orchestrator or the user noticing until someone thinks to look.
Worth noting the built-in Claude Code subagent tool already solves exactly this: it injects a completion notification into the parent's context.
agenc notification newexists but targets the user, not the parent mission, so it surfaces innotification managerather than reaching the agent that needs to act on it.Proposal
Let a mission be spawned with a notify-parent target, for example
agenc mission new --notify-parent <uuid>. On exit, AgenC injects a message into the parent session's queue so it arrives on the parent's next turn. Payload could be minimal: child UUID, exit state, and the bead it was working (see #27).Alternatives considered
A blocking
agenc mission wait <uuid>. Simple, but wrong for an interactive orchestrator: it would block the session the user is talking to.Polling from a cron mission. Works, and is what I would reach for today, but it is a workaround that burns a mission slot to watch other missions.
Current workaround
Brief every child mission to call
agenc notification newwhen it finishes, and serialise to one mission at a time so that checking is tractable. The serialisation is a real cost: it exists to compensate for the missing primitive rather than because the work is genuinely sequential.