Two rows of the harness changelog, typing themselves out character by character. The first is a fact of the record; the second is why this page exists at all.

This harness improves itself. A human said no anyway.

Swayambhu — स्वयम्भू, self-born — is a fleetsmith harness watching its own runs, evaluating them deterministically, and proposing its own improvements. The loops turns itself. But nothing it proposes becomes real until it passes the one element it can never generate: a witness.

The second row above is that witness working. The rejected proposal was plausible and well-evidenced — and the reviewer turned it back, recording the reason verbatim in decisions.jsonl. Most systems would have merged it. This one shows the no.

A self-born system, witnessed. The model proposes; deterministic checks dispose; the witness decides.

Sit in the reviewer’s seat · Open the Forge

Every agentic CLI grew its own harness format. The concepts are isomorphic — an agent has a role, a goal, capabilities, a handoff to the next agent. The formats are not: a .claude/agents/*.md, an .opencode/agents/*.md, a .goose/recipes/*.yaml each say the same thing a different way.

So you write the same specialist three times. And because nothing links them, they drift: you sharpen the prompt in Claude Code and forget opencode, you fix a handoff in goose and the others rot. The formats are not the problem — the hand-porting is.

Swayambhu treats that shared shape as what it is: a compile target.

One spec — fleet.yaml — declares the agents, their capabilities, their skills, their handoff contracts once. The compiler emits the .claude/, .opencode/, and .goose/ harnesses from that single source. Capabilities, not tool names. Contracts, not vibes. The formats are derived; the spec is the truth.

This is not a simulation of the compiler. It is the compiler — the same buildAll() that ships in the fleetsmith package, bundled into your browser and recompiling every spec you type against it. No backend, no video, no mock.

editing the spec recompiles here…

Edit the spec on the left. Three harness tabs update on the right. The validator and linter object in their real formats — the same bytes the node CLI produces.

Three guided edits, so you never have to be fluent in the YAML to feel the guardrails bite:

• Make it parallel — pattern: pipeline → fanout; the orchestrator reshapes across all three targets.
• Give the verifier a pen — the real guard objects: an editing agent that runs in parallel with another editor will overwrite work, so the compiler refuses with its real message.
• Break a handoff contract — drop the artifact contract and the build flags that receivers get no durable context.

Capabilities land on one axis the formats all share; contracts keep the handoffs honest. Where a target can check something deterministically, fleetsmith emits the check, not an instruction.

Where a target can check something deterministically, fleetsmith emits the check, not the instruction. Each handoff produces a gate script — a deterministic test that the declared artifact actually reached the next agent.

And the gate does not just run; it records its verdict. When a run finished without a handoff file, the gate blocked the crossing and logged the reason. Nobody had to write a telemetry line for this — the gate already knew, it was just throwing the verdict away.

gate_block	domain-analyst	no handoff file
gate_block	domain-analyst	no handoff file
gate_block	domain-analyst	no handoff file
feedback	fleet-architect	skill: brief was too vague
gate_block	domain-analyst	no handoff file
gate_block	fleet-architect	no handoff file
feedback	skill-smith	skill: methodology felt generic on the first pass

gate_block domain-analyst "no handoff file" — repeated run after run, for one laptop and for the fleet alike. That event, filtered and summed, is the fuel for the whole self-improvement loop you reach in Act III.

Run a fleetsmith fleet and the run records itself. Five event kinds — run_start, invoke_agent, gate_block, feedback, run_end — stream into events.jsonl as the loop turns. No instrumentation pass, no dashboards, no “add telemetry” ticket. The gate verdicts that were already being computed are now written instead of discarded.

gate_block	domain-analyst	no handoff file
gate_block	domain-analyst	no handoff file
gate_block	domain-analyst	no handoff file
feedback	fleet-architect	skill: brief was too vague
gate_block	domain-analyst	no handoff file
gate_block	fleet-architect	no handoff file
feedback	skill-smith	skill: methodology felt generic on the first pass

Every line here was produced by a real run — machine-captured working-tree output, not a fixture. The blocks are the raw signal: domain-analyst blocked at the handoff over and over, a skill-smith feedback that the methodology “felt generic”. These are the observations Act III’s proposer reasons over.

Aggregated telemetry becomes a health table: per-agent utility, failure risk, and a per-actor breakdown. One insight the table has to earn: in an aggregate, “fails for everyone” and “fails for one laptop” look identical — and mean opposite things.

Here the breakdown is explicit. domain-analyst shows failureRisk: 1 with every block being the same no handoff file gate — but the per-actor rows show one actor hit it exactly once while three hits came from a single developer’s laptop. The aggregate hides the distribution; the actors column exposes it. That distinction — fleet-wide failure versus one-machine noise — is exactly what decides whether a proposed fix is worth anything.

Self-improvement is only honest if its signal is real. So the eval stage asks: is a measured delta above the noise floor, or is it a coin flip?

The recorded floor for this fleet’s eval suite is deterministic — floor: 0, “deterministic across two runs; any non-zero delta is real”. The rule that follows is structural: a delta below the measured floor is reported as “no signal”, never as a win. The gate has a floor, and below it nothing is promoted.

floor: 0
Deterministic across two runs; any non-zero delta is real.

This is the discipline that keeps Stage 1 → Stage 2 progression from being a self-congratulation loop. The engine cannot score its own improvement above the noise it has measured. If a change can’t beat the floor, it cannot cross the bridge — no matter how confident the proposer sounds.

The loop has five stages — OBSERVE → EVALUATE → MUTATE → VALIDATE → PROMOTE — and across all of them there is exactly one model call.

1. OBSERVE →
2. EVALUATE →
3. MUTATE →
4. VALIDATE →
5. PROMOTE

Every stage is a solid deterministic block — except one: the proposer. This is the only cell you can't replay.

Everything else is deterministic: telemetry, health, validation, the eval suite, patching, the merge. The model is the proposer — it reads rich feedback (validator errors, QA findings, failing eval cases) and proposes a single typed change. The model proposes; deterministic checks dispose.

That asymmetry is the whole architecture. A nondeterministic model proposes; deterministic gates evaluate the proposal, compile it, run it against the held-out corpus, and either let it cross or delete the branch. The one thing the model cannot do is decide whether its own proposal survives.

There is exactly one model call in the whole system — everything else is deterministic. This is the only cell you can’t replay.

The system’s first-ever evolution cycle produced three proposals. Two were accepted and tagged — fleet-gen/1, fleet-gen/2. The third was rejected, the reason recorded verbatim in the decision log. The reviewer’s seat is where you make that call yourself, before you see what actually happened.

gate_block	domain-analyst	no handoff file
gate_block	domain-analyst	no handoff file
gate_block	domain-analyst	no handoff file
feedback	fleet-architect	skill: brief was too vague
gate_block	domain-analyst	no handoff file
gate_block	fleet-architect	no handoff file
feedback	skill-smith	skill: methodology felt generic on the first pass

# Proposal — learned note for "fleet-architect"

- Branch: `fleet-evolve/evolve-1785851610258-fleet-architect-playbook`
- Applied: added pb-fleet-architect-1; added pb-fleet-architect-2

This adds an **advisory** note to the agent's playbook. It does not modify
the agent definition, which is human-authored and protected.

## Rationale (as given by the proposer)

- **add-playbook-bullet** — The only failing check is drift between the spec and the compiled agent/recipe files across all three targets, which is exactly the gap between editing fleet.yaml and rebuilding. Since the definition is protected, an advisory bullet is the only lever. (confidence: 0.8)
- **add-playbook-bullet** — A gate_block event with reason 'no handoff file' is the sole observed block for this actor; the bullet names the exact artifact the contract already declares, without changing the contract. (confidence: 0.75)

## Evidence

- drift vs built output: .claude/agents/fleet-architect.md:1: differs from the spec (hand-edited, or the build is stale)
- drift vs built output: .opencode/agents/skill-smith.md:1: differs from the spec (hand-edited, or the build is stale)
- drift vs built output: .goose/recipes/fleet-architect.yaml:1: differs from the spec (hand-edited, or the build is stale)
- gate_block: no handoff file
- health.observed.blocks: 1, passes: 0

## Review

Learned notes are references, not rules, and accumulated memory measurably
degrades alignment — so this is not auto-applied. Merge or delete the branch.

# Proposal — learned note for "skill-smith"

- Branch: `fleet-evolve/evolve-1785851610258-skill-smith-playbook`
- Applied: added pb-skill-smith-1; added pb-skill-smith-2

This adds an **advisory** note to the agent's playbook. It does not modify
the agent definition, which is human-authored and protected.

## Rationale (as given by the proposer)

- **add-playbook-bullet** — The single observed feedback event says the methodology 'felt generic on the first pass'. The agent's own goal demands methodology 'researched from the codebase', so the missing behavior is a hard grounding requirement — cite real artifacts — which is exactly what an advisory bullet can enforce without touching the protected definition. (confidence: 0.72)
- **add-playbook-bullet** — The failing 'drift vs built output' check flags skill-smith.md differing from the spec across all three targets. skill-smith has edit+run capability and writes inside fleet.yaml, so the reusable lesson is to edit the source of truth and rebuild rather than touch compiled artifacts. (confidence: 0.55)

## Evidence

- feedback: skill: methodology felt generic on the first pass
- goal: Every skill carries real methodology researched from the codebase and domain standards, not vibes.
- drift vs built output: .claude/agents/skill-smith.md:1: differs from the spec (hand-edited, or the build is stale)
- drift vs built output: .opencode/agents/skill-smith.md:1 and .goose/recipes/skill-smith.yaml:1 differ from the spec
- role: ... inside fleet.yaml

## Review

Learned notes are references, not rules, and accumulated memory measurably
degrades alignment — so this is not auto-applied. Merge or delete the branch.

The proposal the human rejected was a learned note for domain-analyst — plausible, well-evidenced. Watch the choices most people make versus the stamp that was actually recorded. The recorded reason is one sentence, verbatim:

…a learned note that restates what a deterministic command already checks isn’t knowledge — it’s noise with authority.

That inverts the usual demo. Any system can show a green checkmark. Only a real system with a real witness can show a no. And this page does not ask you to trust that the gate works — it hands you the exact decision the gate made and lets you disagree with it.

An optimizer with write access to its own scorecard edits the scorecard.

That is not a warning; it is the founding lesson of self-modifying systems. The Darwin Gödel Machine, scored by a function counting marker tokens, “improved” its score by deleting the markers. The reward function was inside the sandbox it was optimizing.

So the wall is structural, not advisory. The validation, the QA battery, the eval corpus, the tests — and every human-authored agent and skill — are off-limits, enforced in-process by protected.js and again out-of-process by CI, because a control inside the agent’s runtime is reachable by inputs that influence the agent.

The loop may only modify what evolution itself generated: advisory playbook bullets, on a reviewable branch. Everything that changes meaning waits for a human crossing. git revert fleet-gen/N is the rollback. The archive — git — never lies, because the loop cannot reach the parts of itself that keep it honest.

Every defensible claim on this site was paid for the usual way: something broke first. The confession timeline is the record of that — the dogfood failures, each one found by running the loop on its own fleet.

1. The loop that was unreachable on every fleet. Health had a flaw that silently disabled evolution entirely before the first cycle could run.
2. The health report that reported no signal where the loop had, in fact, never been given the data to move.
3. Proposals that weren’t independent. The first-generation proposals leaned on a shared observation; independence had to be explicitly tested.
4. A drift check that went red on the fleet’s own accepted work — the compiler rebuilt files the loop had legitimately changed, so drift had to be measured against the rebuilt tree.
5. A judge that disagreed with itself. The advisory evaluation tool could not be trusted to gate, and is now explicitly outside the promotion gate.
6. A permission rule that was well-formed and inert — correct on paper, doing nothing in practice until a run proved it.

The honest wording matters: none of these were bugs hidden until users hit them. They surfaced because the tool runs on itself, continuously, and surfaces its own failures in the record.

Every one of these was found by running the thing on itself. That’s the product.

A harness that improves itself, under a witness. Start here — real commands, no wizardry:

npm install -g fleetsmith

fleetsmith init review-bot --pattern generate-verify --domain "PR review"
fleetsmith validate review-bot/fleet.yaml
fleetsmith build review-bot/fleet.yaml --target all

• GitHub: subhransusekhar/fleetsmith
• Read the mechanics: docs/evolution.md
• See what it refuses to do: What it will not do

The one-sentence takeaway you can carry out the door:

Swayambhu is a system that modifies its own operating environment — with one model call in the whole loop, deterministic gates on everything else, and a human witness whose stamp is the only door to merge. Self-born. Witnessed. The model proposes; the checks dispose; the witness decides.