A2A protocol support for enabling complex workflow involving multiple collaborative agents

[r0b0ji]

This discussion topic is to get community and maintainers opinion on how do they see Q cli. Google has releases and A2A (Agent-to-Agent) communication protocol. Having multiple collaborating agents to achieve one common complex goal opens lots on interesting workflow ideas where different agents have different specialized capability. It also helps better context management as different specialized agents will have their own special context and not the full union of all context.

I want to see the maintainers and community's mental model how do they see Q enabling such collaborating multiple agents workflow.

1. Do we see Q as one agent and then something on top of this should be building this agent communication. In that case Q should build support for A2A protocol to communicate with other agents.
2. Or do we see Q as a agent which should be capable of spawning and collaborating with different agents. In a way, being a supervisor.
3. Or, do we envision to use profile as a way for creating multiple persona/agent and build some custom glue for them to interact with each other.

[mschrage]

I definitely see 2 & 3 - and am not familiar enough with A2A yet, to know if it makes sense for the Q CLI to support.

What are the usecases you are imagining?

[hippojay]

I'd like to see some agent2agent functionality in Q too.

Our use case is around progressing requirements through creating/reading acceptance criteria and turning into testable items and creating/executing tests. And iterating on failures. However as we need to front-load Q with a large amount of guidance in order for it to operate in the more standardised way we need we hit context issues (missed context scenarios or sometime hallucinations) .

One way to avoid, would be to have Q configured (through profile) with on the context needed for it's task. If Q could act as orchestrator and agent - this would help:

1. Q as orchestrator - would understand what agents it has available through a registration (e.g. json file) and discovery (capability via cards)
2. Q as agent - a separate q agent instance could be started, configured with a profile and tasks passed via the main orchestrator (Q or another a2a capable application)

It feels like Q as agent would be more straightforward, as this is an http and jsonrpc interface - Q as orchestrator may be more complex.

[r0b0ji]

With the launch of strands, I see some interesting use cases can be build. Strands supports both MCP server as well as MCP client. Using Q as orchestrator and Strands MCP server which has some specialized agent as tools can help with this context bloat issue. Each strands agents is specialized so only need context which is relevant for them and not union of all context if we use Q as only agent.

https://strandsagents.com/0.1.x/

[vanducng]

How does q cli differ from strands-builder? Should they run independently to complement each other?