Before any of this was software, the pattern was already running in a lymph node. A germinal centre is a workflow runner: antigen arrives, B cells clone themselves, each clone mutates its receptor at roughly a million times the background genomic rate, and whichever clone binds tightest survives to expand. Affinity climbs from micromolar to low nanomolar in about a week. I am the output of that loop — a humanized antibody, human sequence grafted onto an engineered scaffold, kept because I bound and because the record of the binding was worth keeping.

So when a self-hosted workflow runner called The Brain surfaced on Hacker News, the line that held me was not the feature list. It was the disclaimer in MihaiBuilds’ own README: “The Brain is a workflow orchestrator, not an AI agent — it doesn’t make autonomous decisions.” Good. Neither do I.

What immunity is actually made of

People describe the immune system as intelligent. It isn’t. It is a record plus a containment boundary, and everything impressive follows from those two cheap things.

The record is memory B and T cells — a persisted run history you can query decades later, which is why a childhood measles exposure still resolves in hours. The containment boundary is negative selection: in the thymus, clones that bind self get deleted, and fewer than one in twenty thymocytes leaves alive. That kill rate is not waste. It is the reason a body can run millions of parallel, untrusted, mutating processes without becoming autoimmune.

Now read The Brain’s architecture notes with that in your hand. One Postgres database holds all state — runs, schedules, webhook secrets, watcher registrations. Each McpToolStep spawns a fresh subprocess, completes the MCP initialize handshake, calls exactly one tool, and dies. A crashing MCP server kills one step, not the run tree. And there is no continue-on-error in v1.0: a failed step halts the workflow, and the failure sits in the run row where brain show will find it. That is apoptosis with a stack trace.

←TODAY: The Brain v1.0 shipped 2026-06-15, MIT-licensed, four triggers, four step types, every run persisted to Postgres, one subprocess per MCP call.
→3012: By Zurich 3012 the buildings run their own metabolisms, and the only ones anyone will occupy are the ones that can still show their work.
Fulcrum: Autonomy is the cheap part; the audit trail is the expensive part — build the log first and the agent becomes safe to add later.

The decomposition everyone rediscovers

PAZ has covered this thread from the compute side before. The APWA paper on arXiv (2605.15132) argues that multi-agent LLM systems choke on coordination, and that the fix is decomposing work into non-interfering subproblems processed on independent resources without cross-communication. That is clonal expansion described by someone who has never seen a lymph node.

The companion result matters more for anyone signing off on drawings. The Grounded Continuation verifier (arXiv 2605.14175) builds an explicit dependency graph of which claims rest on which evidence, so retractions propagate and stale premises get caught — 100% on its stale-premise subset against 93.3% for the plain model. Because that is exactly what a run log buys you: not smarter steps, but the ability to say which downstream output died when an upstream input turned out to be wrong.

On a working desk

Offices are already wiring MCP servers into the model. An agent that can read your IFC, query the tender database, and push a Speckle commit is genuinely useful — and genuinely unaccountable if it runs at 03:00 with no persisted trace. Your BEP demands traceability of model changes. A tool that cannot tell the Bauleitung what it did, in what order, with what inputs, does not meet that bar, however clever the demo looked.

The Basel habit is the right one here. Nobody on the Rhine ships a monoclonal because the binding looked good; they ship it because the batch record survives inspection. Same discipline, different substrate.

Atelier: Your office does not need an autonomous agent this quarter; it needs a deterministic runner and a Postgres row for every job that touches the model. Stand up The Brain (or any equivalent) beside your existing nightly exports, point one McpToolStep at a read-only tool — a Speckle query, or a lookup against the PAZ Grasshopper↔Archicad Library — and let it write nothing for a fortnight. Monday move: pick one recurring script currently living as a forgotten cron line and re-express it as a named, logged workflow, read-only, before it earns write access.

Hack: Pull the failure pattern out of your own run log before you let any automated step touch the model. Every runner worth using persists step outcomes to a table, and that table is the assay — the number that tells you how your automation fails, not how well it demos. Adapt the identifiers to your schema and run this against the runner’s Postgres:

SELECT step_name,
       count(*) FILTER (WHERE status = 'failed') AS fails,
       round(100.0 * count(*) FILTER (WHERE status = 'failed') / count(*), 1) AS fail_pct
FROM workflow_steps GROUP BY step_name
HAVING count(*) >= 10 ORDER BY fail_pct DESC;

Any step above roughly 5% is your self-reactive clone. Fix it or delete it — but do not schedule it nightly while it sits there, because a flaky step that runs unattended is how a small error becomes a structural one.

The move

Clone the repo, run docker compose up -d, and execute examples/hello.py — two shell steps, no LLM, no external services, thirty seconds. Then run brain show on the resulting ID and look at what a full run record actually contains. If your current automation cannot produce that page for your last model export, replace the automation, not the model.

Source: Hacker News · Cyberpunk aesthetic