From Agents to Networks

A First Network of Agents

December 25, 2025

Over the Christmas break in 2025, I created a demo project where a netowrk of AI agents can create their own tools and spawn more AI agents, each with access to all of the tools they created before.

A Recursive Network of Dynamic MCP Agents

In techncial terms, my basic idea was to create what I called a 'dynamic MCP server'. Instead of serving a tool (or some kind of API) over the MCP protocol, so an agent can interact with it, my idea was that agents could use this MCP server to do two extra things:

The network starts with a single AI agent. If you ask it to solve a problem (like calculate the 100th prime number), it can write Python code and create its own tool on the MCP sever. This it can then use to try to solve the task. When it gets stuck, it can also create an new sub-agent (which inherits access to all of the earlier ccreated tools on the MCP server), that will try to solve a specific part of the problem (either by using all of the avaialble tools, creating additonal tools, or by creating additional sub-agents).

This recursive component, makes it that as each of the sub-agents can create more tools and spawn other agents, the network keeps growing. As more agents and tools are added, the network keeps slowly evolving to solve more complex tasks as you give it more complex problems.

More details on Github

I included the 'Recursive Network of Dynamic MCP Agents' project into a larger template project on GitHub, where I am showcasing various examples on how to set up agents and connect them to MCP servers, with increasingly more complex patterns. Starting from how to work with structured output, function calling, building up to tool use, how to set up an MCP server, and build an agent that can work with multiple tools. And continuing with how to include these patterns into larger workflows, building up to the Recursive Network of Dynamic MCP Agents pattern. [https://github.com/JeroenVanGorsel/agentic-LLM-example]

Is any of this useful?

Now, having build this, the most important questions is of course: is any of this actually useful? Is a network of agents better than a single agent that can create all the tools it needs? Does this recursiveness with agents being able to create sub agents buy us anything more?

Multi-agent systems burn roughly 15× the tokens of a chat and add coordination failure surfaces; they win decisively only when the task decomposes into independent, parallel, read-heavy threads (Anthropic measured a multi-agent system outperforming single-agent Claude Opus 4 by 90.2% on breadth-first research) and lose on tightly-coupled, sequential, write-heavy work (Cognition's "Don't Build Multi-Agents").

The main initial variable that are relevant when deciding if it is worth to use a network of agents, or subagents at all is context. Every multi-agent patterns is in essense a decision about how context is partitioned and passed: who shares what context with who, and who holds the control loop.

Shared continuous context (single agent) maximizes coherence; partitioned context (multi-agent) maximizes scale and parallelism. I will adress these questions, and how and when to best design networks of agents, in more detail in the upcomming articles in this section