Plasma Fractal
Nicholas Diao, Andrew Turner, Colton BerryJuly 21, 2026
Recursive agent loops for complex, multi-step work.
Agent graphs have taken over agentic engineering. Every leading harness can now fan work out to subagents and compose them into dynamic workflows (Claude Code, for example). Long-running recursive loops, though, are not yet first-class.
Fractal is our take on recursive agent loops: a hierarchy of agents, each running its own loop, with a budget at every level. We use Fractal for some of our most complex work.
Giant tasks
By giant tasks we mean work that outlives any single context window and branches into parts that can proceed independently: large refactors and migrations, features that span services, research and experiment campaigns. Three we've run for real:
Before open-sourcing Fractal, we pointed it at its own repository: find the bugs, stress the harness, tune the defaults. Fixes landed mid-run, so later nodes ran on a version of Fractal that earlier nodes had already repaired.
Result
The verdict that Fractal was ready to ship came from Fractal itself: a 187-node tree found 135 issues in the tool it was running on, fixed 55 of them test-first, and kept only the improvements that held up across six different kinds of work.
- nodes
- 187
- frictions found
- 135
- depth
- 4
- models
- Claude
Findings · Building Fractal
Three things about how the run worked, each visible in the repo's history:
The fixes landed while the run was still going
The run worked in three phases, with a gate between them: debug on realistic workloads, then stress-test, then optimize. At each gate, the fixes found so far were merged into the copy of Fractal the run itself was using, so the next phase's nodes started on a repaired tool. By the end, Fractal's test suite had grown from 698 to 823 passing tests, and 55 of the 135 issues the tree cataloged were fixed with a failing test written first.
The defaults were tuned by intersection, not by picking a winner
In its final phase, the run grew six subtrees, each pushing the default instructions that every new node starts from toward a different kind of work: wikis, research, benchmarks, product builds, numeric experiments, and meta-optimization itself. A seventh node then kept only the changes that helped across all six: 17 kept, 9 rejected. Six fresh runs on the tuned defaults completed with no steering.
It graded itself like a skeptic
The stress-test needed genuinely hard work, so part of the tree attacked open problems in mathematics. Every claim had to survive a skeptic node whose only job was to break it. As a control, one problem was chosen because its answer already existed in the literature. The run never saw that answer, and its blind results matched it ten for ten. The skeptics cut the other way too: one result the tree thought was new was withdrawn after its own literature search found the same result already published.
Every node is a loop
The node
A node is one agent working toward a goal in its own git worktree. Unlike a subagent inside a session, it is a persistent loop with its own branch, memory, and lifecycle. The loop continues until the agent signals completion or hits a limit you set, but you can stop it at any time. The default loop has five steps:
- Prepare: pull in the parent's latest commits and fold in finished child work.
- Plan: decide what this iteration will do.
- Execute: make the changes in the worktree.
- Review: check the diff, fix mistakes, and fold what it learned into memory.
- Commit: save the iteration to the node's branch.
Each step spins up a fresh coding agent (Claude Code or Codex) in the node's worktree, and that agent is free to use its own subagents and dynamic workflows within the step. You set the goal in a NODE.md file and steer by editing it. Its content is included in every agent invocation, so you can redirect a running node without stopping it. The steps are defaults, not fixed. Add, remove, or replace them in a node's steps/ folder to reshape the loop.
Across iterations, a node keeps what it learns in its memory: a folder of plain Markdown pages, indexed and cross-linked into a knowledge graph. It is Plasma Wiki underneath, so the memory is files on the node's branch, organized by topic, not a transcript.
The hierarchy
When a goal has separable parts, a node can spawn children to work on narrower sub-goals. Each child gets its own branch and runs the same loop, so every node in the hierarchy owns one part of the work. During Prepare, the parent merges ready child branches into its own. Budgets follow the same shape: every node carries its own, tracks what it and its descendants spend, and a run that drains its budget wraps up at the next iteration boundary.
Nodes coordinate over Fractal Radio, the built-in message channel: a parent sends direction, a child reports back. Before each step, a short sync pass handles messages from the rest of the tree, so a node stays aware of its parent and children. The durable record is always the branch and the memory.
Try it
Fractal is open source under Apache 2.0 on GitHub. Install the fractal and wiki CLIs, then add the /fractal skill to Claude Code or Codex:
# The fractal and wiki CLIs
pip install fractal
# The /fractal and /wiki skills for your agent
fractal installDrive it from inside the agent you already run:
> /fractal spawn a node to migrate the payments service off the legacy clientThen watch it work: fractal open brings up the terminal UI from the top of this post.
Give it a real task, and tell us what you run it on.
Fractal Cloud
Fractal is coming to the cloud. See the tree, steer its nodes, and track costs as the work runs.
Early access opens soon.
Occasional emails. Unsubscribe anytime.