How it works
One task in.
One answer out.
Between those two points, a team that did not exist is written into being, does the work, and is asked to leave. Ten seconds, start to finish. Here is every one of them.
01 The topology
One architect.
Nobody underneath it.
Until you ask. One permanent process decides the team and writes it out of nothing - and never once does the work itself.
Each agent is a real Python file with one function in it. It reads a task and its upstream results on stdin, returns plain text on stdout, and that is the entire contract. No shared memory. No message bus. Nothing travels between agents except what the one before it actually returned.
Which is exactly why they can be deleted without loss. The architect holds the plan. The agents hold their slice and nothing else.
02 The pipeline
Seven stages.
Not one of them
trusts the last.
Each stage does one thing and knows nothing about the others. The planner has never seen a line of Python. The executor has never seen a prompt. A factory line - not one mind holding the whole problem at once.
Planner
Grades the task simple, standard or deep, decides the team - one to four agents - and wires who feeds whom. The grade then sets the reasoning effort of every call that follows.
A translation stops deliberating. An acquisition analysis stops rushing. It budgets like a person would.
Generator
Writes every new agent as real source code - all of them at once, in parallel. It is forbidden from writing your subject into the prompt, so the agent it builds today works on a different topic tomorrow.
The research_agent built for solar panels contains the
word “solar” exactly zero times.
Codeguard
Reads that function before it is allowed to become a process - import by import, call by call. The whole standard library is available, minus the thirteen modules that would undo everything else.
Rejected code is rewritten, up to three times. It does not get to argue.
Executor
Runs the graph in waves. Agents the plan proves independent go side by side; dependent ones wait. Files, subprocesses and deadlines - and not one model call.
When an agent crashes, its own error becomes the instruction for rewriting it. Twice, then it is excused by name.
Merger
Collapses every output that survived into one voice. An agent that could not be repaired is named in the report - its error is never passed downstream dressed up as a result.
Council
Deep tasks only. An adversarial critic reads the answer the way its toughest reviewer would - unsupported claims, reasoning that does not carry its conclusion, the counter-case nobody weighed.
Real faults drive exactly one refinement pass. A sound answer stands, unbilled.
Judgement, then release
The answer is read back against the request. A 200-word brief that came out at 600 sends the agents round again with the gap named. When it holds, you get it - and then AgentGod asks whether the agents it just built are worth keeping.
This is the step that makes it an agent rather than a pipeline. A run used to end wherever the merger happened to stop.
03 The board
You watch
the whole machine.
One live board shows which phase is active and what every agent is doing right now - written, reused, running, repairing itself, done, failed.
It animates while the system works and disappears when it is finished, leaving the answer and a compact transcript. Pipe it, redirect it, or run it in CI and the same run degrades to clean aligned plain text - same information, nothing that fights a log file.
The pipeline itself never prints. It emits events; the interface decides what they look like.
What stops the thing it just wrote
| Property | Behaviour |
|---|---|
| Names | Every identifier is reduced to a safe token before it goes near the filesystem. |
| Imports | Read before execution. subprocess, socket, pickle, importlib and their neighbours are refused. |
| Packages | ~80 vetted names only, installed into an isolated venv - never yours. An invented name is refused, not resolved. |
| Deadline | Every agent runs against a hard clock. Default 300s. |
| Repair | Two rewrites for a crash, three for invalid code. Then it is excused by name. |
| Honesty | This is static validation, not a sandbox. Treat the task string as a trust boundary. |
04 Where it earns its name
Work that is
too wide for one.
If one mind could hold the whole problem you would not need a god to staff it. Bring it something that splits.
Research that fans out
Several angles, chased at the same time, collapsed into one voice. Agents can search the web - server-side, so the code they run stays standard-library clean.
Chains where order matters
The planner declares who feeds whom. Provably independent agents run side by side; the rest wait their turn. A chain still runs as a chain.
Analysis that must hold up
Graded deep, an answer faces an adversarial critic before it faces you - unsupported claims, the counter-case nobody weighed.
The same job, forever
Run one report and it builds the agents. Run the next and they come back free. By run three you are paying for the answer, not the machinery.
05 What stops the thing it just wrote
It writes code.
Then something
reads it back.
A machine that writes its own workers, in a real language, and then runs them owes you one answer before any other: what stops the thing it just wrote?
- Namesare reduced to safe tokens.
../../../pwnedbecomespwned. - Codeis parsed import by import before it becomes a process. No
eval. Noexec. No shelling out. - Packagesinstall only from ~80 vetted names, only into an isolated venv - never yours.
- Timeruns out. Every agent works against a hard deadline or dies holding it.
Now the reason it kills them.
Why the destruction is the whole point, and never the footnote.