AI Agents Dynamic Subagent Creation & Agent Registry Live Demo! | Humanitarians AI Fellows
A Humanitarians AI student fellow demonstrates how a parent agent can dynamically spin up subagents with assigned roles, then checks a ChromaDB and Neo4j registry to avoid recreating an agent that already exists.
A single AI agent handling one task is straightforward. A system where agents can create other agents on demand, assign them roles, and avoid redundantly building the same agent twice, is a genuinely different kind of architecture. This live demo, built by a Humanitarians AI student fellow, walks through exactly how that kind of self-expanding agent system works, and shows it running against real problem statements.
Two modules, one goal
Scaling an AI agent infrastructure to handle a wide range of tasks requires two connected pieces working together. The first is dynamic subagent creation and role assignment: given a problem statement from an external agent, typically a "super" parent agent, the system needs to decide whether a new subagent is required, and if so, generate that subagent along with a role, a description, and a task prompt. The second piece is the agent registry and metadata database, which keeps track of every agent that already exists so the system is not constantly recreating agents that could already solve the problem at hand.
How a new agent gets built
When a parent agent hands off a problem statement, the system assigns a role description and a task prompt to the resulting subagent, using structured JSON output from the underlying language model to keep agent creation consistent and machine-readable. Before actually creating anything new, the system consults the agent registry to check whether an existing agent could already handle the problem, which avoids the waste of spinning up duplicate agents for tasks that are functionally the same. Every agent created this way carries a defined set of fields: an agent ID, an assigned role, a role description, a task prompt, the parent agent ID that created it, any dependencies, and metadata like a timestamp and which language model was used to generate it.
Where the registry actually lives
The registry itself is split across two different databases, each doing a different job. ChromaDB stores the metadata for every agent in the ecosystem, the kind of information that benefits from vector-based similarity search. Neo4j stores the relationships between agents, specifically the parent-child dependencies that map out which agent created which. When a new problem statement comes in, the system checks ChromaDB first using similarity search against a defined threshold; if a sufficiently similar existing agent is found, that agent is reused and mapped to the new parent rather than triggering a new build. If nothing similar enough exists, a new subagent gets created, registered in ChromaDB, and linked into Neo4j as a new node under its parent.
Watching it run
The live demonstration uses Llama 3.1 as the underlying model, with FastAPI handling the input layer, and the codebase organized into a main file, a ChromaDB integration, a Neo4j integration, and a dedicated agent creation module. The first test submits a brand-new problem statement, "create a data analysis report," under a parent labeled "parent A." Since no similar agent exists yet, the logs confirm no sufficiently similar agent was found, and a new subagent is created with the role of data analyst, which then shows up in Neo4j as a node connected to its parent.
The second test submits a new problem statement that is deliberately similar in meaning to the first one, under a new parent ID. This time the logs report that an existing agent was found and reused, meaning no new agent was created at all, the new parent is simply mapped to the previously created data analyst agent. A third test introduces a genuinely different problem statement under a new parent, "parent C," and the logs again confirm that no sufficiently similar agent exists, triggering the creation of an entirely new subagent, which then also appears correctly connected in Neo4j.
Why this matters for scaling agent systems
The core value of this architecture is that it lets an agent ecosystem grow only when it actually needs to. Without a registry and similarity check, a system that creates subagents freely would end up with redundant agents doing the same work under slightly different names, wasting compute and making the resulting agent graph impossible to reason about. By checking against existing agents before creating new ones, the system keeps its agent population efficient while still being able to expand to handle genuinely new problem types as they appear.
Key takeaways
- The system splits into two modules: dynamic subagent creation with role assignment, and an agent registry with a metadata database.
- ChromaDB stores agent metadata and supports similarity search; Neo4j stores parent-child relationships between agents.
- New agents are created with structured JSON output, including a role, description, task prompt, parent ID, dependencies, and metadata.
- Before creating a new agent, the system checks the registry via similarity search to avoid building redundant agents for similar problems.
- The live demo, built on Llama 3.1 and FastAPI, showed both correct new-agent creation and correct reuse of an existing agent for a similar problem.
Who this is for
This demo is aimed at developers and students interested in multi-agent AI architecture, particularly anyone trying to understand how to prevent agent sprawl in systems that can create their own subagents. It was created by a student fellow through the Humanitarians AI Fellows program, which supports students and recent graduates in developing and teaching technical AI skills.
Full transcript(auto-generated, with timestamps)
[0:12]Hi. Uh so today we will be uh studying about dynamic sub agent creation and role assignment and we will also be going through agent registry and metadata database. So AI agents are autonomous systems designed to perceive their environment, process the information and take actions to achieve specific goals. So uh they can either be rule based or can be driven by various machine learning models or they can often create and interact with different agents as well. So in in an agentic architecture AI agents can you know dynamically create, configure and deploy other agents based on the task requirements. So this is uh basically done using a
[0:56]Self-replicating task allocating or or a hierarchal based system. So to scale a super AI agents infrastructure we need uh two different modules. The first one is dynamic sub agent creation and role assignment and the second thing is agent registry and the meta data database. So uh now coming to the key requirements the key features and requirements of an AI agentic universe. So the first thing that is dynamic sub aent creation and role assignment module. So in this basically a problem statement or query is given from an external agent probably a super parent agent. Output is a list of newly created sub aents if needed with their rows, their
[1:42]Descriptions and their different task prompts. So uh basically uh dyn uh a parent agent is there and a problem statement is given. Now the now different roles are assigned uh role descriptions and task prompts are assigned to each sub agent. Now we will be using JSON output from LLMs to ensure structured and aligned agent creation. Then we will consult the agent registry which is uh we will be using uh chromb for the agent metadata storage and neoforj for graph based agent agent relationship management. So to consult the agent registry and metadata database to avoid uh duplicate agents. Now uh we will be using the following fields
[2:27]For agent creation. So every agent should have an agent ID, a role, um a certain role which has been assigned to an agent and it is supposed to perform that, a role description, a task prompt, a parent agent ID which is the ID of the parent agent which has created a subsequent agent, various dependencies and obviously some metadata like timestamp or the LLM used to create that agent. Our second thing is agent registry and metadata database module. So basically we maintain a database for all the agents in the ecosystem. We use chromod to store metadata agent metadata and we use neoforj to store agent agent
[3:06]Relationships you know parent child dependencies and all. Now we check for existing agents if if there's a problem that is given and if there is an existing agent that that can solve that problem then we will be using that agent to solve the problem otherwise we will create a new agent. So these newly created agents will be registered with their meta meta data in the chromb and the relationships in the new fallj. So this is uh the designed workflow. So basically a problem statement input is given. So an external agent sends a problem statement or query with dynamic sub aent creation and role assignment module. Now the second thing that
[3:50]Happens is we consult the agent registry. Now the model consils the agent registry to check if existing agents are there or not. Now comes the agent creation. So if there are no existing agents found that can handle the task, the module will dynamically create new sub aents. Assign roles, descriptions and task prompts to each sub aent and this uses JSON output from the LLMs to structure agent creation. Third thing is the module may require multiple terms to create agents. considering the context of existing agents. Now if we need new agents to be created. So once all the new agents are created the modules final list of the
[4:32]Metadata and the relationship to the agent registry and then the list of agents is stored in meta. Uh so yeah agent registry ensures that the agent dependencies which is like the parent child relationships are correctly stored in Neo 4j and all the metadata of the newly created agents is stored in chromob. uh so I will be showing a demo as well. So basically this is the code base that uh I have designed. So the llm that we are using for creating the agent is uh llama 3.1. You can use llama 3.2 as well. And I'm using fast API to give the input. So this codebase basically has a main py
[5:23]File. Then we have a chromb database, new 4j database and also agent creation file. Uh okay. So I will just give a demo. Yeah. So the fast API is started. Now I have a I have created a validation file since I was trying this earlier. So um I will give parent A as the first parent ID. So this is the master agent that is being created. parent is the first parent ID [snorts] and I'm giving this problem statement as
[6:34]The first problem statement. So ideally this is the first agent that is being created in the entire agent agent AI universe with a parent ID of parent A and a certain problem statement. Now this is the first time we are giving this problem statement. So this means there's no existing agent that uh there's no existing agent which can solve this problem. So ideally it should create a new agent. So let's see what happens. We can check the logs over here.
[7:44]The lock says no sufficiently similar agent found which means a new agent will be Yeah, it usually takes a bit time to create a new for the first time. Yeah, here. So, a new agent has been created and mapped and we can check for
[8:56]The same in Neo4j. Yeah. So, this is a query which we use in Neo4j to get the graphs. Yeah. So this is a parent A that is the dummy agent that was there with the parent with the agent ID as parent A and this depends on a newly created agent which can solve the problem. The problem statement is create a data analysis report. Basically the problem statement that we gave and the role assigned to this agent is data analyst. Now we will check for some new ones. Now if we give a similar problem. So if I give a new problem statement. So this is a new problem statement and I
[10:06]Will change the pairing title. So now ideally what should happen? So since this is a new problem statement but it is very similar to the previous one. So the previous created agent should be able to solve this problem. So ideally the new parent should be mapped to the already previously created agent. Now coming to how we are deciding if new agent is needed or not. So we are using the similarity search uh which is there in vector databases since we using chrom. So we are using similarity search and we have defined a certain threshold. Uh let's see what happens. Yeah. So this says existing agent is
[10:49]Found in map. So no new agent was created. The already existing agent could solve this problem. Let's check this in. Yeah. So the new agent is mapped to the already existing agent. I will show one more example. So okay let's give one more new problem statement. So ideally there should be a new agent created for this problem statement. So the parent agent for this statement would be parent C
[12:09]If you check the lot, it says that it is creating a new agent since no sufficiently silver agent found. Yeah. So it has created a new agent. We can check the same in your 4G. Yeah. So for this parent a new agent has been created. So uh that was all from my site and this was the demo of uh about how agents AI agents can be used to create new agents. Thank you.
More videos
2:08Bridging the Pixel Gap in Browser Automation.
2:23How One Narrow Safety Rule Can Make an AI Less Safe Everywhere Else.
2:04Why splitting a chunk from its document makes it retrieve for the wrong question
4:20Three You Can Take Back. One You Can't.
2:21Why a 50-turn agent pays for the same screenshot 35 times unless it caches the pixels
1:53