Capability · Delegation
Sub-agents that inherit the gate
Big jobs fan out to sub-agents that run in parallel — every one of them inheriting the same approval gate, and all of them stoppable at once.
When a job has independent parts, monopea does not work them in sequence. It delegates each part to a sub-agent, runs them at the same time, and wakes to integrate the results — so a morning of work takes as long as its slowest piece, not the sum of all of them.
Scaling the workers does not multiply your risk surface, because governance is inherited, not re-configured: every sub-agent runs under the same tenant policies and the same default-deny gate as the agent that spawned it. More hands, one set of rules.
Fan out, run in parallel, integrate
Give the agent a job with several independent parts — research three markets, draft five variants, clean a pipeline while writing the weekly update — and it spins up a sub-agent for each, running side by side in isolated contexts. When they finish, the delegating agent wakes, integrates the results, and decides the next step.
Work is split so the parts do not overlap, and agents can claim shared resources before touching them — so two strands never silently overwrite the same thing.
- Independent work runs at the same time, not one after another
- Each sub-agent works in its own isolated context
- Shared resources are claimed before they are touched
Every sub-agent inherits the gate
A sub-agent has no special powers. It runs under the same tenant, the same tool policies, and the same default-deny gate as the agent that delegated to it: its mutation-capable calls become pending proposals in the same queue, and unknown tools fail closed for it exactly as they do at the top level.
That inheritance is the difference between delegation and dilution. Parallelism multiplies throughput; it does not multiply the set of things that can happen without you.
- Same policies, same proposal queue, at every depth
- No privilege escalation through delegation
- Unknown tools fail closed for sub-agents too
Steer mid-run, stop everything at once
You stay in command while the fan-out is live. A message folds new instructions into work already in flight, and a stop command halts an agent and everything it spawned, immediately — no orphaned sub-agent keeps running in the background after you have said stop.
Interrupted work is preserved, not discarded: the delegating agent can read partial progress, judge it, and continue from where things stopped rather than from zero.
Checked results, full trace
Every delegated task carries a definition of done. The sub-agent checks its own output against that bar, and the delegating agent independently validates the result before accepting it — work that misses the goal is sent back with the reason, not waved through. And every step each sub-agent took is on the record.
The trace matters as much as the check: you can reconstruct exactly how any piece of parallel work happened — which tools were called, what was produced, and what was approved along the way.
Why it matters
Faster without being looser
Independent work runs simultaneously while every strand obeys the same approval gate.
One stop stops everything
Halting an agent halts all of its sub-agents instantly. Nothing runs on behind your back.
Results are validated
Sub-agent output is checked against an explicit definition of done before it is accepted.
FAQ
Delegation & sub-agents, in short
- Do sub-agents bypass the approval gate?
- No. Every sub-agent inherits the same tenant policies and default-deny gate as its parent. Its mutation-capable calls land in the same proposal queue, and unknown tools fail closed for it too.
- Can I stop a parallel run?
- At any time. Stopping an agent stops everything it spawned, immediately — and the work completed so far is preserved for you to review.
- Do parallel agents overwrite each other’s work?
- They are built not to: the job is split into non-overlapping parts up front, agents can see what the others are doing, and shared resources are claimed before they are touched.
- How do you know a sub-agent did the job right?
- Each delegated task carries a checkable definition of done. The sub-agent self-validates against it and the delegating agent re-checks the result — failing work goes back with feedback.
Keep exploring
Goals & autonomous runs
Hand the agent an objective and it plans and runs the work — on schedules, around the clock — while you steer, stop, and approve.
Approval gate
Default-deny control: mutation-capable tool calls become pending proposals and wait for your decision before anything is dispatched.
Audit trail & live activity
Every proposal, decision, and dispatch on a signed, tamper-evident record — with a live view of what is running right now.