Exploring better agent-to-agent communication

[zikajk]

ECA already has spawn_agent: a primary agent delegates work to a linked subagent chat and gets a result when it finishes.

Since subagents already have subagentChatId / parentChatId, maybe ECA could treat them more explicitly as active agent threads: inspectable, steerable, resumable, and able to communicate with linked agents.

Motivating scenario:

A primary agent delegates monitoring to a subagent: watch hot reload, compiler output, tests, logs, or a background job. The subagent stays active until stopped/closed. When it sees a relevant problem, it should be able to hand that information to the primary agent, or another linked agent that can debug it.

Background jobs are only one example. The broader idea is delegated work that may need communication while it is still active.

Possible directions:

• Expose active subagent chats
  Let users switch to, inspect, and interact with active subagent chats, similar to Codex agent threads.

• Steer running/resumable subagents
  Let the user or primary agent send follow-up instructions, ask for status, stop, or close a subagent.

• Agent-visible reporting
  Let a subagent report relevant information to another linked agent, not only to the UI.

• Support finite and ongoing delegation
  Some subagents return a final result; others stay active and report only when needed.

• Peer/team-style coordination
  Should linked agents communicate only through the primary, or also directly with each other?

Open design questions:

• Should a report queue for the target agent’s next turn, wake/steer it immediately, or require confirmation?
• How do we prevent late subagent reports from polluting an unrelated primary task?
• How much context should be included when handing off a problem?
• How do we avoid noisy reporting or agents repeatedly waking each other?

@ericdallo

[zikajk]

A relevant use case:
#309

[ericdallo]

I like the feature idea, and would give a lot of power to ECA, being able to spawn and manage agents swarms, I didn't have much idea of what this would look like but with your example I can see how convenient it is to have manageable and agents that can communicate with themselves.

My biggest concern is that there is a lot of micro features on this whole idea, so maybe we should start discussing what should be in a v0 but also think how to make it extensible for those other additions

[zikajk]

Nice example and discussion, it might come in handy.
https://x.com/ClaudeDevs/status/2074606058128224365
https://clojurians.slack.com/archives/C093426FPUG/p1783609600639719

[zikajk]

@ericdallo Thinking about it (as we might need this soon: #614):

Maybe we can start with a simple approach without a massive refactoring right away.

What if we add two tools? (Names are just initial placeholders):

• steer_subagent - sends a steering message using chat-id to any running chat. I'm on the fence about whether this should be limited to a single chat and its subagents, or if it should be able to call any chat in the session (or even across different sessions). Personally, I'd start with a single chat scope and see if we need more later.
• check_subagents - retrieves status/activity info about subagents (the tricky part).

(It would be nice to skip check_subagents and stream this info automatically, but I don't think that's feasible yet. We'd have to inject messages into the subagent's history and fight cache invalidation.)

I feel like this could be a solid starting point.
Here is the exact scenario I’d love to enable for v0:

1. I start a subagent with a lightweight/cheap model to run my dev server and monitor logs.
2. The main chat works on a feature (e.g., implementing hot-reload).
3. The background subagent catches an error and reports it back to the main chat.
4. The main chat fixes it and either prompts the subagent or consumes the info directly.

---

Hmm, typing this out made me realize this actually requires deeper refactoring after all...

We'd need to support running subagents asynchronously in the background (which seems to be Claude Code's default mode; running in the foreground only when results are needed immediately).

This means we have to address how a background subagent:
a) Reports findings back asynchronously
b) Terminates / cleans up (dies)
c) Deals with the resume (from #614)

...and likely several other cases I haven't thought of yet.

So in the end, I didn't arrive at a immediate solution, but at least I hope I've narrowed down the problem a bit! :-)

[ericdallo]

@zikajk we already have background subagents right? maybe not the best implm but works

[zikajk]

@ericdallo Ah, great. When I wrote it, I was just assuming things that could've been wrong. I'll check it more :-)