Agents that hire agents: building fleets that do not explode

Abstract

A single agent running a complex process eventually breaks. The prompt gets too large, the context window fills with irrelevant details, and the model forgets what it was supposed to do in the first place. The solution is splitting the work. We built a primitive that lets an agent spawn a sub-agent to handle a specific piece of a task. But letting AI spawn AI introduces immediate risks: runaway execution loops, unconstrained spending, and privilege escalation. We solved this by treating the agent hierarchy exactly like an organizational chart. Budget flows down from the parent, so a child can never outspend its creator. Permissions strictly narrow, ensuring a worker only has access to the exact services it needs to do the job. Spawn chains are capped at three hops to prevent recursive nightmares. Finally, every action rolls up into a unified audit tree, meaning you can trace any API call back to the exact delegation that caused it. This is how we scale from one agent to a functioning fleet.

1 The single-agent ceiling

Everyone starts by packing more instructions into a single prompt. If the agent needs to draft an email, check a database, and update a CRM, you tell it to do all three. For a while, this works. Then the ceiling hits.

Consider a standard research agent. You ask it to find five competitors, scrape their pricing, and draft a comparison memo. It starts strong and finds three competitors. Then the fourth website returns a weird CAPTCHA challenge or an unexpected layout. The agent spends ten turns arguing with the web page, fills its context window with HTML garbage, and completely forgets it was supposed to write a memo. The task dies.

Human organizations do not work this way. A manager does not write the code, review the legal contract, and book the flights. They hire specialists. If we want agents to handle complex, multi-step business logic without losing the plot, they need the ability to hire each other. They need to divide and conquer.

The important detail is not simply parallelism. Parallel tool calls are useful, but they still leave one model responsible for planning, execution, error recovery, and final synthesis. Delegation gives each worker its own narrow objective, its own clean scratchpad, and its own failure boundary. The parent can stay focused on coordination instead of drowning in execution noise.

2 The delegation primitive

We exposed a single, governed platform capability: system.delegate. When an agent realizes it has a discrete task that requires focus, it calls this endpoint. It provides a natural language prompt explaining the job, specifies the tools the worker will need, and sets a dollar budget.

To the parent agent, this feels exactly like calling a normal API. Execution pauses while the worker runs. The platform spins up a fresh, blank-slate worker agent. This worker has one goal and zero distractions. It does not know about the parent's overall strategy. It only knows it needs to execute its specific assignment and return the result.

This is not just a nice abstraction. It isolates failures. If the worker encounters a rate limit while searching the web, the parent agent is not polluted with thirty turns of error-handling dialogue. It just receives the final summary or a clean failure notice, and it can decide what to do next with a clear head.

In practice, this turns large automations into reviewable contracts. The parent does not pass its entire memory to the worker. It writes a compact job description, declares the exact capabilities requested, and names the budget ceiling. That contract becomes part of the run record, so a human can inspect why the worker existed at all.

3 Budget propagation

Allowing an AI to start new AI processes is financially terrifying if left unchecked. A single logic bug in a while loop could spawn ten thousand agents and drain an account in minutes. We fix this by enforcing a strict law of conservation. Money is never created during delegation. It is only moved.

When a parent agent spawns a worker, it must slice a portion of its own remaining budget and hand it down. If the parent has five dollars left and gives three dollars to the worker, the parent now has two.

If the worker runs out of money, it stops immediately. Imagine a web scraper worker that gets caught in an endless pagination loop. It burns through its allocated three dollars and dies. The parent agent receives a timeout error, realizes the worker failed, and still has its remaining two dollars to try an alternative approach.

If the worker finishes early, the unspent change flows back up to the parent. This mathematical guarantee means you can safely ignore how many sub-agents are running. The maximum financial exposure is always exactly the budget you gave the top-level agent.

This also makes pricing intelligible to operators. A failed branch is not a mystery bill; it is a bounded experiment with a visible cap. Teams can raise or lower worker allocations the same way they tune cloud resource limits, and the fleet remains governable even when the internal plan changes dynamically.

4 Permission narrowing

Financial limits are not enough. We also have to limit the blast radius of a mistake or a compromised sub-agent. If a top-level agent has permission to read the database and send emails, and it hires a worker just to summarize a text file, that worker should absolutely not inherit the database access.

This is how you stop prompt injection from becoming a catastrophe. If the summarizing worker reads a malicious document that instructs it to email all users, the attack fails at the platform level. The worker literally does not have the email tool.

Our rule is simple: permissions can only narrow, never expand. When the parent calls system.delegate, it must explicitly list the capabilities the worker needs. The platform intercepts this request and intersects the requested list with the parent's actual permissions. If the parent tries to grant a permission it does not hold, the delegation is blocked instantly. This creates a default state of least privilege.

The narrowing rule matters most when a worker reads untrusted inputs. A research worker can browse webpages without holding payment tools. A ticket triage worker can read Jira without being allowed to close incidents. A draft-writing worker can compose a customer reply without being allowed to send it. Each worker is useful precisely because it is incomplete.

5 Spawn chains and depth limits

Even with strict budgets and narrowed permissions, an agent that spawns an agent that spawns an agent is a debugging nightmare. Infinite loops do happen. An agent might decide the best way to summarize a long book is to hire a worker for each chapter, and those workers might try to hire workers for each paragraph.

We enforce a hard, platform-level depth limit on spawn chains. Currently, it is set to three hops. The parent is depth zero, the worker is depth one, a sub-worker is depth two, and anything beyond that is blocked by the orchestrator.

When an agent attempts to spawn a worker at the limit, the API call rejects with a clear platform error. It tells the agent it must finish the work itself or return what it has. Three hops is deep enough for a manager to hire a researcher, and for the researcher to hire a web scraper. It is not deep enough to bring down the system.

A depth limit is deliberately blunt. We could build clever heuristics that try to detect runaway recursion, but cleverness is the wrong layer for a safety guarantee. A hard ceiling is explainable, testable, and visible in the audit tree. If a workflow needs deeper decomposition, it should probably be redesigned as an explicit workflow rather than an emergent spawn chain.

6 The audit tree

When you have ten agents working on a problem, reading a flat log of API calls is useless. You need to know exactly why an action occurred and whose budget paid for it. Because delegation is a first-class platform primitive, we capture the exact hierarchy.

Every service request, whether it is sending a message or spending a cent, is tagged with its parent agent, its grandparent agent, and the original user request that started the whole tree.

In the dashboard, this renders as a unified visual tree. If a worker fails a task, you can expand the branch and see the exact prompt the parent used to hire it, the budget it was given, and the errors it hit. This makes AI failures fully reproducible. You can adjust the parent's instructions and try again with complete visibility into the black box.

The audit tree is also the foundation for accountability. A service request is no longer an isolated event that says "an agent called GitHub." It says which user initiated the run, which parent agent delegated the work, which worker held the permission, which budget funded it, and which policy checks passed before execution. That chain is what makes agent fleets operable inside real organizations.

7 What this unlocks

Multi-agent orchestration transforms how you approach automation. Instead of trying to write the perfect, all-knowing prompt, you write highly specialized, reliable micro-agents.

The parent agent becomes a planner and a router. It reads the user request, breaks it into discrete steps, hires the right workers, and synthesizes the results. Over time, these worker agents build their own specialized memories and competence records for specific tasks, meaning the fleet literally gets smarter at division of labor the longer it runs.

This is how we move from fragile scripts to resilient, scalable intelligence. And because of the budget, permission, and depth constraints, you can deploy these autonomous fleets into production with actual peace of mind.

The long-term shape is an internal labor market for software agents: planners, researchers, reviewers, schedulers, support triage workers, finance clerks, QA agents, and code graph specialists, all hired through one governed substrate. Upivia's job is not to make every worker smarter than every model provider. It is to make the fleet safe enough, legible enough, and financially bounded enough to run in the open.

Upivia is in open beta. Delegation and multi-agent orchestration are live today. For a broader look at the operating system running these agents, see the control layer post.