Messaging between the agents

[amitschendel]

One thing that is currently a bit missing is a way to route messages between the agents without manually setting this up.
I would love to have a system where we can set "sender" and "receiver" and the system will know how to route it to the correct agent.
Currently this needs to be implemented by the user but it would be nice if there was a way to wrap it so it will be a "no brainer" task.

[KennyVaneetvelde]

Hmm I personally don't see a way to make it easier without losing verbosity

Any suggestions in how you'd expect to use it?

[OnlyC]

I create OutputSchema with action field and tell agent to fill it in prompt, indicate next agent, or tool's name and in the while loop use simple if else through a list of agents & tools, last one is agent_answer:
if response.action == "agent_x":

I still feel something wrong about it but not yet have another solution.

[NicolaiLolansen]

Surprised there’s no built-in pattern for multi-agent orchestration. Right now you can chain agents, but you can’t easily let a “coordinator” agent call several specialised sub-agents and aggregate their results (the Deep Research demo is still a single agent with tools).

I used @OnlyC’s workaround: the coordinator emits an action that either triggers a sub-agent or stops. The coordinator itself has no tools. It works, but feels clunky.

Is there a cleaner way to run multiple agents concurrently that I’ve missed in the codebase?

[KennyVaneetvelde]

See the thing is that what you are requesting is a CrewAI-style, autonomous multi-agent orchestration, right?

You can make this is you want, and we can even have it added as an example - maybe some day I'll have a crack at it if I encounter a use case where this is actually something we need for a client.

The reason we don't have anything in-built into the codebase for this is to keep it lightweight, I'd rather have an example in the codebase that you can copy-paste on how to do this yourself, than provide abstractions. Why? Well, quite simply put, it easily turns into the proverbial hammer that makes everything look like a nail... And 99% of the time this way of orchestrating is detrimental to the final outcome.

In practice, clients often need things like being able to benchmark & optimize small components within the system, think of having a local, fine-tuned question-answering agent trained on company data, based on deepseek, while using gpt-4o-mini to do simple query generation, while having another model that specializes in deciding whether or not to even do a search at all. If a ticket comes in, as a developer you can now look at each of these parts individually, modify them, benchmark them individually... As business, if I need to plan a roadmap, I can now allocate budget to the further fine-tuning and improvement of our question-answering agent, and so on...

But once you have something more CrewAI-like in place, it becomes "too easy" to think of it instead as: "I will have an orchestrator agent that can call other agents, and then I will have a research agent that has a search tool and uses that to answer questions, I will have an editor agent, an ..." but following that paradigm completely blocks you off from all of the benefits (mostly in debugging capability and developer control) of making everything atomic, by NOT having a "research agent" but rather a "research pipeline consisting of a query generating agent, a question-answering agent, a decision agent that decides if we need a search at all".

If you want more autonomy, I recommend learning from the MCP example here but simply replace the Union of tool schemas that is dynamically generated, with a Union of agent input schemas, alongside a "final answer" schema that can be used

Something like:

class OrchestratorOutputSchema(BaseIOSchema):
    """Combined output schema for the Orchestrator Agent."""

    agent_params: Union[AgentOneInputSchema, AgentTwoInputSchema, FinalAnswerSchema] = Field(
        ..., description="The parameters for the selected agent. Use the final answer schema to present a final answer"
    )

You could then, similarly as to the MCP example, have a loop that keeps going until we hit a final answer.

But, I do not recommend this approach really. You are way better off, 99% of the time, if you just spend a bit more time thinking of the flow yourself, and implementing it manually, rather than having some orchestrator agent figure it out on the fly, because often it will not go exactly as you want it.

For the deep research example, to make it deeper and more autonomous, here is what I'd do:

• You introduce a new agent that takes the user's input/question and generates a list of sub-questions (kinda like a research plan)
• You take the query generating agent, make it generate queries for each of the subquestions
• You query, you scrape
• You parallelize a few question-answering agents and make them answer each of the subquestions
• You have a report synthesis agent that has as input the original question, the sub-questions, the answers from the question-answering agents and outputs a report.

That should be a good basis, of course there are ways to improve this, but you could really only do that as a developer if with full control. Let's say it's running but your client says "I want the report to be more structured in our company structure that we always use". You could then introduce a step where you have a ToC generation agent that generates a ToC based on the input & sub-questions. If it is not detailed enough you can introduce an agent that evaluates the report and decides whether or not to do a followup search until some final condition is reached...

But that is all going to depend on a case-by-case basis, which is why we don't allow a single paradigm to be implemented into the framework as it would make a lot of our current real-life business use cases a lot harder and less maintainable.

For now I'll close this ticket, however anyone is of course free to create a multi-agent orchestration example for the atomic-examples folder!

[NicolaiLolansen]

Super good answer, thank you so much. I'll read everything you wrote here and familiarize myself with the pattern. Thank you!