Fractal Delegation

Principle III: Fractal Delegation

Tasks decompose into self-similar subtasks, recursively.

The most interesting property of complex problems is that they contain smaller versions of themselves. A system architecture is composed of subsystems. A document is composed of sections. A deployment is composed of stages. The structure is fractal — and your orchestration system should acknowledge this.

The Delegation Pattern

When an agent receives a task too complex for direct execution, it does what any competent manager does: it breaks the task into subtasks and delegates them. But unlike most delegation systems, Obsidian’s delegation is structurally recursive.

Each sub-agent operates under the same constitutional framework as its parent. Each can delegate further, creating hierarchies of arbitrary depth. The result is a tree of agents that mirrors the structure of the problem being solved.

Why Fractals

Because the alternative — flat task lists with manual dependency management — does not scale, and everyone who has tried it knows this but builds it anyway because “we’ll add hierarchy later.” You will not add hierarchy later. You will add workarounds.

Obsidian builds hierarchy in from the start. Not as a feature you might use. As a fundamental structural principle that shapes everything else.

Constitutional Inheritance

When an agent delegates to a sub-agent, the sub-agent inherits its parent’s constitutional obligations plus any additional constraints the parent specifies. Constraints can only be added during delegation, never removed. This ensures that constitutional compliance flows downward through the entire delegation tree without gaps.

The Warden verifies this inheritance at delegation time. If a parent attempts to delegate without proper constraint propagation, the delegation fails. This is strict. This is correct.