In classical software the call graph is static: you know at build time which function calls which. An agent doesn't work that way. Given a goal large enough, it decides mid-task that it needs help — spawns a sub-agent, hands off part of the work, and merges the result back when it returns. That dynamism is most of what makes agents useful on real work. It is also all of what makes them dangerous without the right structure around the spawning.
Why a goal turns into a tree
Long-horizon work decomposes. "Prepare the quarterly business review" is not one task; it's a financial summary pulled from the accounting system, operational highlights from the CRM and project tracker, a headcount view from the HRIS, and a risk register built from open items. Those branches are largely independent. An agent that recognizes the decomposition can spawn a specialist for each branch, run them in parallel, and assemble the results — which is both faster and better than grinding through them sequentially in a single context that gets more overloaded with every step.
This is real delegation, and it's the same move a competent manager makes: see the shape of the work, parcel it out to people suited to each piece, and integrate what comes back. The Claude Agent SDK that Harnyss runs on supports exactly this — an agent can spin up sub-agents as the work demands. The question Harnyss has to answer is not whether to allow it. It's what that spawning happens inside.
The execution graph is decided at runtime — that's the risk
Because the tree is shaped at runtime rather than design time, you cannot reason about it the way you reason about a flowchart. You don't know in advance how wide it will get or how deep. Left unchecked, a single top-level goal could spawn an unbounded tree — each agent consuming model calls, touching tools, and running up cost — and no human asked for any of it directly. The power and the hazard are the same property: the system decides its own structure as it goes.
So the structure has to come from the harness around the agents, not from the hope that a model improvising under a deadline will be conservative.
The rails come in two kinds
Resource rails keep the tree finite. Spawning is bounded — there's a limit on how deep the tree can go and a budget for how many agents a single goal can spin up. A spend cap escalates to a human instead of silently burning through credits. A time-to-live keeps a forgotten sub-agent from running forever; if it expires, its partial work is surfaced rather than discarded. None of this makes the agent less capable on the work that matters. It makes the failure modes bounded instead of open-ended.
Authority rails are the ones that actually matter, and they're the part most discussions of "agents spawning agents" skip. A spawned sub-agent inherits a scoped subset of its parent's authority — never the full set, and never more than its parent had. A research sub-agent the CMO agent spins up can read what it needs to do the research and nothing else; it does not get write access to the CRM just because somewhere up its lineage an agent had it. Authority narrows as you descend the tree. It never widens.
And the approval gates still apply. A sub-agent three levels down that reaches for a gated action — sending external email, moving money — pauses for the same human sign-off a top-level agent would. Depth doesn't dilute governance. A gate is a gate no matter how it was reached.
The harness runs the tree, not the agent
Inside Harnyss, an agent calling another agent looks, from inside its reasoning loop, exactly like calling a tool — it's a capability exposed over the same protocol. That's deliberate. The agent doesn't manage the tree: it doesn't handle routing, doesn't enforce the policy, doesn't write the log. The harness does all of that at the boundary. The agent just asks for help.
Two things follow. First, every spawn, every delegation, and every merge is a logged event in the same audit trail as everything else — the dynamic tree is fully reconstructable after the fact, even though it was never specified in advance. Second, escalation has somewhere to go: when something exceeds a sub-agent's authority, it walks up the tree until it reaches an agent — or a human — with the standing to decide. The structure that contains the spawning is the same structure that routes the exceptions.
Why this is an organization and not a flowchart
A flowchart routes a task along a path fixed before the task ran. It cannot decide, halfway through, that the work needs a shape nobody drew. Emergent delegation is precisely that ability — handling the unscripted by reorganizing on the fly — and it's one of the things that separates a running organization from a conveyor belt. The catch is that the same ability is what makes an improvising system dangerous, which is why the authority model and the audit trail aren't optional extras. They're what make dynamic delegation safe enough to let run.
For the deeper version of that argument, see when the org chart becomes software.