Subagents

[zikajk]

To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.

Opening this ticket to initiate a discussion about the implementation of coding sub-agents.
These are specialized AI agents (focused on writing, reviewing, and modifying code, often used to develop entire features or applications automatically).
We want to understand the community's interest and specific requirements for this functionality.

Attaching a diagram outlining the architecture (subagent should be able to use hooks as well).

[ericdallo]

Thank you a lot for the diagram @zikajk!

1. How the orchestrator would know which agent to call? a description in the agent definition which the main agent would call LLM to then know which agent to call? how that would work is the complet stuff I suppose, maybe we could pass to this orchestrate LLM request a tool that LLM would call explaining the plan or something like that.

2. Shouldn't the subagents report back to orchestrator? or is just a minor detail? as main agent will be awaiting for subagents responses/updates I suppose, my point here is, the main agent maybe is just a await of subagents which just output what subagents report back right? when all are finished, summarize and respond back.

Given 2, I wonder if we should change a little bit arch, is it too crazy to instead of a main agent that spawns subagents we have just a list of agents? so any agent can spawn any other? (we would need to avoid recursive/infinite tho), because I suppose in UX, would be easier to represent those subagents, would be nice to see how claude/cursor shows those

[Kaspazza]

@ericdallo
I've upvoted this after seeing this repo: https://github.com/nyldn/claude-octopus
What I think would be nice is to be able to offload some work to other AI and have an option for Multiple AI to talk to eachother to increase quality - but I think of it more as wishful thinking, because the benefit I would like from it is to have less claude subscription usage as some of the tasks would be delegated to other LLMs which are cheapear and may be good enough.

But I call it wishful thinking, because I don't know how it could be done well, as delegation of what should go where and what should be discussed by many LLMs seems not obvious to me and would need a lot of testing with specific models to know that or continous upgrades.
Maybe it could be somehow delegated to the user to tell which other APIs/connections to LLMs to use for which tasks, just like we can have different eca or third party tools llm calls to e.g. edit text, maybe we could have similar mechanism for that, which will be more from user configuration and prompt guidance?

[ericdallo]

@Kaspazza yeah that makes sense, in my discussions with @zikajk we are heading to a path where subagents would be behaviors, so you could have different models used by a subagent behavior type, being able to delegate tasks to different LLMs.

About subagents communicating with each one, I think this is harder and probably not the best way to handle that, subagents should be independent and stateless, not sure how we would manage to make that work if we wanted

[zikajk]

Just adding it here as it is nice story showing how Agents can be orchestrated:
https://cursor.com/blog/scaling-agents
or Agent swarm here
https://www.kimi.com/blog/kimi-k2-5.html

[ovistoica]

Just posting my thoughts on this subject. I would love specialized sub-agents. The biggest use-case for me is when you want exploration of a big codebase or section in order for the main agent to understand what pieces are required without having the context polluted. The main agent can dispatch 2-3 sub agents to explore certain subsections and come back with an overview and files involved.

If you would do this exploration in the main agent that does the actual coding, you'd have extra context from files that were explored but not needed.

This type of behavior, where the main agent dispatches many exploring agents that just need to summarize a specific part of codebase is very handy during planning phases. As @ericdallo said, communication between sub agents would not be required. They are simply sub processes that are started for the purpose of saving context on the main work.

[zikajk]

I think we should support collaboration:
https://www.youtube.com/watch?v=6omInQipcag

I would improve (WIP) TODO tool to support the workflow from the video

[ericdallo]

Hum I was aware of beads but never tried.
How do you see this affecting subagents besides the TODO?

[zikajk]

I think It affects them in a way that it is not just "Fire and forget" and there is ongoing communication between them.

[ericdallo]

Update: I managed to make foreground agents work in ECA. This is a huge start to have agents working smoothly!