Is tool-calling all you need?Interaction patterns in multi-agent systems

This is the final piece in our series on multi-agent orchestration, discussing the minimal set of key patterns and components we think are needed to cover the vast majority of orchestration cases.

In the first and second pieces of the series we discussed the anatomy of AI agents, and the powerful agents-as-tools pattern. We showed how some apparently different patterns are either really similar, or fully equivalent, to agents-as-tools.

We also introduced the concept of a Task as something distinct from an agent, and of a directed graph relationship between tasks.

In the third part of the series, we looked at other interaction patterns between agents that don’t naturally map to the tool-calling pattern.

Armed with the knowledge of what’s possible, what choices did we make in Motleycrew to combine maximum power with maximum convenience in multi-agent orchestration?

First of all, we made the agents-as-tools pattern explicit and easy – you can just pass motleycrew agents (including Langchain, LllamaIndex, and CrewAI agents inside simple motleycrew wrappers) inside the tools list to other motleycrew agents, along with other kinds of tools, and this will just work.

Secondly, we are working to distill the key useful patterns that are not easy to implement in the other agent frameworks, and making them available out of the box – the first example being output handlers, a special kind of tool that allows users to enforce hard constraints on an agent’s output.

If a user needs a very specific flow pattern that can only be implemented with a custom state machine, that is easy too: motleycrew tools and agents all implement the langchain Runnable interface, and are thus fully compatible with LangGraph.

Arguably, those are all neat usability features, but hardly groundbreaking; but now we come to the next motleycrew innovation, namely orchestration via builtin knowledge graphs. Any motleycrew orchestrator object (called a crew :) ) automatically comes with a knowledge graph instance, which can be used for global information sharing much like, for example, MetaGPT’s group chat.

This knowledge sharing is done via Task classes, which have a more powerful interface than similar concepts elsewhere. A motleycrew Task comes with two methods: one that sees whether there are any instances of that task (called “task units”) available to be worked on right now; and another that returns an agent that is best suited to execute a given task unit (generated by the same Task). Both Tasks and agents (via tools) can read and write to the shared knowledge graph.

This setup takes orchestration to the next level as new task units can be created on the fly by the agents working on other task units, by writing to the knowledge graph. An example is the research agent, where a first Task starts with a research question and builds up a tree of followup questions, each with its own retrieved context; and a second Task rolls that tree back up, first using the retrieved context on the leaf questions to answer these, then using these to better answer their parent questions, etc.

In our opinion, this combination of explicit agents-as-tools, information-sharing and orchestration via a shared knowledge graph, and LangGraph compatibility for really complex cases hits the sweet spot of being really natural and easy to use for more common use cases, yet powerful and flexible enough for almost any of the more complex ones.

Give it a try at motleycrew.ai, and please let us know if you discover any gaps!