Ryan Junee
Post · May 12, 2026

How I built an autonomous build pipeline, then let it improve itself

Trident is a Forge-Argus-merge loop with ScheduleWakeup-driven coordination. I built it to ship code while I sleep. Then I pointed it at its own substrate.

Saturday, 14:22 PT. I’m in the kitchen. The Neutron repo lands PR #158, an in-app file explorer plus markdown reader. Eight hundred lines of new TypeScript, two new gateway routes, a containment audit on the filesystem walker. Argus reviewed it, found one tree-truncation banner missing on the web target, Forge fixed it on round two, Argus approved, the gateway squash-merged. The whole pipeline ran on a single /trident command I issued before lunch.

I did not write that code. I did not review it. I did not press the merge button. And it is the 158th PR shipped that way into the Neutron repo, plus 113 more into the Vajra repo behind it. Two hundred and seventy-one PRs, give or take.

This post is about what Trident is, how I built it, and what happened when I pointed it at its own substrate. The recursive part is real. One of the PRs Trident shipped fixed a bug that had been wedging Trident agents themselves for a month. The pipeline that builds the pipeline that builds the pipeline. I’ll show the diffs.

Part 1: The pipeline

The problem statement is one line. Agent build cycles need review. Human review is the bottleneck.

I ship a lot. By March 2026 the Vajra repo (my personal agent system) was averaging two to three substantive PRs a day, every one of them touching gateway routing, watchdog state machines, agent prompts, or some other moving part that could quietly break overnight. I am one person. I cannot review three PRs a day at the quality bar I want and still write the next three.

The shape of the fix is a three-role loop. Forge builds: it takes a task description, spawns into a git worktree, runs a planner, writes code, runs tests, opens a PR. Argus reviews: it reads the diff, runs a second-model cross-review (Codex via the OpenAI CLI), synthesizes findings into APPROVE or REQUEST CHANGES with numbered blockers. The calling Claude Code session orchestrates, advancing the state machine each round until Argus approves and the PR squash-merges, or the round budget runs out and Argus posts a final REQUEST CHANGES for human triage.

The build primitive Forge runs inside each round is /slfg, from Every Inc’s compound-engineering plugin. /slfg is the autonomous “plan, build, ship the PR” workflow that compound-engineering exposes as a skill. Trident is the autonomous review-and-merge loop wrapped around it, not a replacement. Without compound-engineering there is no Forge. Without Claude Code there is no agent at all — every node in the state machine, from the orchestrator down to the Forge and Argus subprocesses, is a claude -p invocation. The ScheduleWakeup primitive used for coordination is also Claude Code’s, borrowed from its /loop pattern.

The state machine has five vertices.

forge-init ──▶ argus ──┬─▶ done       (Argus APPROVE → squash-merge + clean up)
                       │
                       ├─▶ forge-fix ──▶ argus  (round + 1; max 8 rounds)
                       │
                       └─▶ failed     (round > max OR agent crash)

Each transition is gated by the state file at ~/vajra/gateway/trident-<slug>.state.json. That file is the source of truth. Every Trident command (start, check, status, stop) reads and writes it. Schema:

{
  "slug": "spawn-success-no-tmux-window",
  "phase": "done",
  "round": 3,
  "max_rounds": 8,
  "agent_id": "argus-spawn-success-no-tmux-window-r3-argus-20260514-010737-9f5tvf",
  "pr": 116,
  "branch": "worktree-spawn-assertion-cap-stop-wedge-alert",
  "worktree": "/Users/ryan/vajra/.claude/worktrees/spawn-assertion-cap-stop-wedge-alert",
  "repo_cwd": "/Users/ryan/vajra",
  "chat_id": "-1003775096851",
  "thread_id": "389",
  "task": "fix(gateway): post-spawn assertion + cap-hit hard stop + wedge alert on first inbound",
  "started_at": "2026-05-13T22:49:25Z",
  "last_advanced": "2026-05-14T01:34:54Z",
  "merge_commit": "5e987011967a3ad1dddcb9ab9f1da7c65d4774c5",
  "merged_at": "2026-05-14T01:34:44Z"
}

That is a real one, dropped verbatim from disk. PR #116 went three rounds with Argus before merge. Two hours forty-five minutes wall-clock. Three Forge invocations, three Argus invocations, one squash-merge.

The coordination mechanism: ScheduleWakeup

The first version of Trident used a background bash script. nohup trident.sh &. The script polled the agent registry every 30 seconds, checked for completion, spawned the next phase. It worked, but it had two problems.

First, the calling Claude Code session had no idea what was happening. The bash coordinator was off in another process; the user-facing agent could not answer “what’s happening with the Trident run?” without re-reading log files. Trust broken.

Second, the coordinator was its own failure surface. Three of the original Trident runs got stuck because the bash coordinator died (OOM-killer, terminal close, accidental kill). The state file said phase: argus; Argus was long gone; nothing was polling. Silent stall.

Trident v2 dropped the bash coordinator entirely. The calling Claude Code session itself drives the loop, using a primitive called ScheduleWakeup. The agent issues a tool call that says “wake me up in 90 seconds with this prompt.” The agent’s process exits. Ninety seconds later the runtime spawns it again with the prompt and the full prior conversation in context. It reads the state file, checks the current agent’s completion event, advances the phase, schedules the next wake-up, exits.

This means the agent that started the Trident run is the agent that reports each phase transition back to me in real time. It also means there’s no separate process to crash. The state file plus the cron-like wake-up schedule is the entire coordination layer.

The check loop in pseudocode:

STATE="$HOME/vajra/gateway/trident-${SLUG}.state.json"

# Guard: was the run stopped?
if [ "$(jq -r .phase $STATE)" = "stopped" ]; then
  exit 0
fi

# Is the current agent done?
AGENT_ID=$(jq -r .agent_id $STATE)
COMPLETED=$(grep -E "\"agent_id\":\"$AGENT_ID\".*\"event\":\"completed\"" \
  $HOME/vajra/gateway/running-agents.jsonl | tail -1)

if [ -z "$COMPLETED" ]; then
  # Still running. Verify the process is alive (catch silent crash).
  AGENT_PID=$(jq -r .pid $REGISTRY_ROW)
  if ! kill -0 "$AGENT_PID" 2>/dev/null; then
    # PID gone, no completed event. Crashed silently.
    post_to_telegram "agent crashed; manual check needed"
    set_phase failed
    exit 0
  fi
  # Process alive. Reschedule.
  ScheduleWakeup 90 "/trident check $SLUG"
  exit 0
fi

# Agent finished. Read the result, advance the phase.
RESULT=$(extract_final_result_event_from_log "$AGENT_ID")
case "$PHASE" in
  forge-init|forge-fix) advance_to_argus "$RESULT" ;;
  argus)                advance_from_argus_verdict "$RESULT" ;;
esac

The crash-detection branch matters. The first month of Trident runs surfaced a class of bug where Forge or Argus would spawn, log spawn, and then exit before completing. No completed event, but no process either. The state machine would politely wait forever. kill -0 on the PID closes that hole, fast.

The agent primitive

Underneath the loop is one bash script: spawn-agent.sh. It is the only way Trident creates a Forge or Argus. The shape is small. Generate an agent_id. Resolve the prompt file by agent type. Fork claude -p --dangerously-skip-permissions --append-system-prompt-file as a fully-detached background process with stream-JSON output piped to a per-agent log. Append a spawn row to running-agents.jsonl with the real child PID. Print the agent_id to stdout. When the child exits, append a completed row with the exit code.

The spawn row and completion row are the only persistence the script does. The gateway’s watchdog reads running-agents.jsonl every 15 seconds, detects crashes and stuck agents, and posts alerts back to the originating Telegram topic. Trident reads the same file to know whether to advance.

The cross-model property is load-bearing. Argus runs Claude Opus 4.7 as its primary model and invokes codex-review (which uses OpenAI’s GPT-5 Codex under the hood) as a second opinion before synthesizing a verdict. When the two models flag the same thing, that finding is almost certainly real. When they disagree, Argus has to reconcile. Same-model review (Opus reviewing Opus) consistently underperforms on the specific class of bug that bites in production: the thing the author was confidently certain was fine.

What Argus actually catches

The clearest way to make the cross-model point concrete is to show a real verdict. PR #44 in the Vajra repo was a chat-safe restart endpoint, my first attempt at a POST /admin/restart route that the gateway could call on itself without killing the topic CCs running on top of it. Forge built it, opened the PR. Argus round 1:

REQUEST CHANGES. 2 blockers, 1 minor.

Cross-model synthesis (Codex GPT-5 + Claude Sonnet security-sentinel + Opus):

1. [BLOCKING] VAJRA_ADMIN_RESTART=1 env leak. restart-gateway.sh:209 spawns
   the new `bun index.ts` without scrubbing env. After one admin restart, the
   relaunched gateway and every topic CC it spawns inherit
   VAJRA_ADMIN_RESTART=1, so the PPID guard is bypassed forever after. Original
   self-kill cascade returns. (Codex P1, I missed this.) Fix: `unset
   VAJRA_ADMIN_RESTART VAJRA_WATCHDOG` right after the guard block.

2. [BLOCKING] Shell tests 1 and 5 are false green. `exec -a "..." bash SCRIPT`
   replaces the subshell in place, so $PPID never points at the renamed parent.
   Running in-env: exit=0 where exit=2 is asserted. (Both Codex and I found this
   independently.) The positive guard-firing path is untested; a regression
   would pass silently.

3. [MINOR] No rate limit on /admin/restart (security-sentinel).

Two findings, both correct, both shipped to fix. The env-var leak is the cleaner one: a single missing unset in a 209-line bash script would have reintroduced the entire self-kill cascade the PR was meant to fix. The lint would not have caught it. The test suite was structured around the wrong assertion (the false-green Argus also caught). A human reviewer skimming the diff probably would not have caught it either, because the failure mode only manifests on the second restart, hours later, after the env-var has propagated.

Forge round 2 fixed both blockers. Argus approved. Squash-merge at commit 8a2cb72. Total wall-clock: 81 minutes.

The shape of “what Argus catches that a CI run would not” is consistent across the corpus: cross-component invariants, regression risk from changes that pass tests but invalidate the test’s assumption, semantic mismatch between docstrings and behavior, missing guard on a non-obvious failure path. None of these are lint targets. All of them are exactly the kind of thing a code reviewer is supposed to catch and frequently does not, because reading 800 lines of diff carefully is hard and tiring and there is always more diff after this one.

Part 2: Pointing the pipeline at Neutron

I am building Neutron, the productization of my personal agent substrate. It is a 153-PR-and-counting greenfield repo. About a hundred of those PRs were shipped by Trident.

The interesting part isn’t volume. The interesting part is what changed about how I structure work when Trident is the executor.

The sprint brief becomes the bottleneck

When I review my own code, the brief I write for myself can be loose. I know what I meant. When Trident is the executor, the brief is a contract with a system that takes it literally. Ambiguity in the brief produces literal-minded code that satisfies the words and misses the intent.

The pattern that emerged after two failed sprints early on is the spec-conformance audit, a five-line diff that every Forge brief on a spec’d subsystem must contain:

SPEC § X.Y says:    <what should happen>
CURRENT WIRING does: <what actually happens>
GAP:                 <what's missing>
THIS SPRINT FIXES:   <which gap items>
EXPLICITLY OUT OF SCOPE: <deferred items>

The brief writer (me) is responsible for the spec-to-implementation diff. Forge consumes the diff and writes code that closes the gap. Argus verifies the gap closed.

This pattern is now a hard rule in the Neutron repo’s CLAUDE.md, the file every Claude Code session in that repo reads on boot. The full rule lives at ~/repos/neutron/CLAUDE.md under “Spec is the source of truth.” It was added 2026-05-13. The story behind that date is in Part 3.

A real example, lifted verbatim from PR #158’s commit message (a Trident-shipped sprint that landed yesterday morning):

SPEC § 5 of sprint roadmap says: P7.0 ships the file explorer + markdown
reader as the first read surface of the in-app doc interface. Tree
navigation, markdown render with wikilinks rendered as plain bracketed
text, syntax highlighting deferred to P7.1.

CURRENT WIRING does: app/app/projects/[id]/docs.tsx was a hardcoded
placeholder tree + zero gateway endpoints surfacing markdown docs to
the Expo app. Telegram-side users relied on the obs.junee.workers.dev
redirect, in-app users saw a "Coming in P7" stub.

GAP: project-scoped markdown docs invisible in the Expo app.

THIS SPRINT FIXES: ships docs tree + reader. Backend stores docs per
project at <tenant_home>/Projects/

/docs/. Read-only viewer for v1. EXPLICITLY OUT OF SCOPE: markdown editor (P7.1), inline comments (P7.2), chat read-surface linkage (P7.3), git-backed versioning (P7.4), LFS binary handling (P7.5), wikilink resolver, backlinks panel. ``` <p> When the spec-conformance block is present and accurate, Forge writes code that almost always satisfies Argus on round one. When the block is fuzzy or skipped, Argus catches the gap on round one and Forge fixes it on round two, and I have wasted a Trident round on a brief problem I could have solved in advance. The brief is the bottleneck. The brief is now where I spend most of my own time.

### The sequence diagram

A single Neutron sprint, end to end:

```mermaid
sequenceDiagram
    participant Me
    participant CC as Claude Code (orchestrator)
    participant SF as state file
    participant Forge
    participant Argus
    participant GW as gateway + GitHub

    Me->>CC: /trident <sprint brief with spec-conformance diff>
    CC->>SF: write phase=forge-init
    CC->>Forge: spawn-agent.sh forge ...
    CC->>CC: ScheduleWakeup 90s
    Forge->>GW: worktree, /slfg, commits, push, open PR
    Forge-->>CC: completed event (PR=#158)
    CC->>SF: phase=argus, pr=158
    CC->>Argus: spawn-agent.sh argus ...
    Argus->>GW: codex-review.sh, synthesize verdict
    Argus-->>CC: APPROVE / REQUEST CHANGES
    alt APPROVE
        CC->>GW: gh pr merge --squash
        CC->>SF: phase=done
        CC->>Me: "merged PR #158"
    else REQUEST CHANGES
        CC->>Forge: spawn fix-pass r2
        CC->>SF: phase=forge-fix
        Note over CC,SF: loop until APPROVE or max_rounds
    end

The full machinery for one Trident run is about 480 lines of skill code plus 410 lines of spawn-agent.sh plus the state file. The two prompt files (forge.md, argus.md) are about 600 lines combined. No other coordination layer. No background process. No queue server. The state file plus the wake-up loop is the whole orchestration substrate.

Numbers from the corpus

Part 3: The pipeline starts improving itself

Here is where the story gets interesting.

Trident is software. Software has bugs. The state file gets corrupted, the wake-up loop sometimes wakes the wrong session, the Argus wrapper occasionally fails to exit after writing its final result event. Each of those is a real issue. Each one got logged in ~/vajra/ISSUES.md. And each one is the kind of small infrastructure fix that Trident itself is good at: a bounded scope, a clear failure mode, an obvious test surface.

So I started pointing Trident at its own substrate.

Case 1: The bug that wedged the wedge detector

The previous post on this site catalogued a failure mode I called “Spawn says success, but nothing spawned.” Eight respawn cycles in a row, all logging success, none of them producing a tmux window. The spawn helper logged completion at fork time and never verified the child actually came up.

I dispatched the fix as a Trident sprint on 2026-05-13. Task: post-spawn assertion plus a hard stop after the per-thread respawn cap trips plus a wedge detector that consults OS-level probes on the first inbound message to a topic. Spec-conformance diff in the brief.

Round 1 Forge built three new gateway modules: post-spawn-assertion.ts for the sync and async assertion paths, topic-wedge-detector.ts for the OS probes, and a capped_at field on the StuckTurnRecord for the permanent hard stop. Round 1 Argus, full verdict:

REQUEST CHANGES. PR #116. 3 blockers, 1 important, 2 minor.

Both Codex (cross-model) and Argus independently flagged the same two top-
priority issues:

1. Wedge detector false-positives during legitimate cold-start / boot window
   (gateway/index.ts:2479-2566). Fires no-pid-no-listener verdict during ANY
   30-90s post-respawn boot OR first-use cold-start. For first-use topics
   planRespawn then refuses with no-session-to-resume, so the queued message
   is silently dropped. The exact failure mode Fix 3 was meant to fix.

2. Auto-respawn-on-wedge has no per-topic cooldown (gateway/index.ts:2533-2553).
   Every inbound to a wedged topic SIGKILLs in-flight respawns. Bypasses
   Fix 2's stuck-turn cap.

3. Sync structural assertion races tmux daemon (:1566-1573). Uses
   assertSpawnStructural (one-shot) when post-spawn-assertion.ts's own docs
   say polled assertSpawnAlive is needed; 3 slow attaches will suspend a
   healthy topic.

Plus: missing exact-Tabs-sequence regression test (8 spawns → cap-hit →
post-cap prune attempts).

Read that carefully. The first finding is recursive. Argus is saying: the fix you just shipped, which was meant to prevent silent message drops on wedged topics, contains a code path that itself silently drops messages on healthy-but-cold-starting topics. The cure would have, under the right conditions, replicated the disease it was treating.

The second is also recursive. The hard stop I added (the capped_at field) was supposed to prevent runaway respawns. The new auto-recovery code path bypassed it. The two fixes in the same PR partially canceled each other out.

Round 2 Forge rewrote both: the wedge detector gates on a boot window before firing, the auto-recovery path consults the cap. Round 2 Argus, two more minor findings. Round 3 Forge, round 3 Argus, APPROVE. Squash-merge at commit 5e98701 (Vajra PR #116). 2858 tests pass, 2 skip, 0 fail, 54 net new tests.

Vajra’s spawn infrastructure is meaningfully more correct today than it was on 2026-05-12, and it got that way because Trident shipped a fix to its own underlying substrate while Argus caught the two bugs that fix would have introduced. A human reviewer skimming the diff at 11 PM on a Tuesday almost certainly would not have caught either. I had skimmed earlier drafts and missed both.

Case 2: The hardening loop on spawn validation

Look closely at the Trident skill file at ~/.claude/skills/trident/SKILL.md. The “Step 5: Spawn Forge init” section contains this block:

if [ -z "$forge_init_id" ] || ! grep -q "\"agent_id\": \"$forge_init_id\"" \
     ~/vajra/gateway/running-agents.jsonl; then
  bash ~/vajra/scripts/tg-post.sh "${CHAT_ID}" "${THREAD_ID}" \
    "❌ Trident ${SLUG}: spawn-agent.sh returned empty or unregistered agent_id."
  set_phase failed
  exit 1
fi

The comment above the block reads:

Apply the same validation after EVERY spawn-agent.sh call (forge-init,
argus, forge-fix). Without this, today's phantom-ID polling bug
(2026-04-15 trident stuck 55+ min waiting for argus_id="") will recur.

That comment is dated because it documents an incident. On 2026-04-15 a Trident run silently lost an Argus agent_id (the registry-write drop bug, separately fixed in Vajra PR #93, commit 13a7d9b). The state file recorded agent_id: "". The check loop dutifully woke every 90 seconds, searched the registry for an empty-string agent_id, found nothing, rescheduled. Fifty-five minutes of polling for an agent that did not exist.

That validation block is the fix. It’s now part of the skill. Every future Trident run starts with the assertion that the spawn it just issued actually registered. The post on failure mode #2 from the prior writeup (“logging the initiation of a side effect is not the same as verifying its completion”) is encoded mechanically into the substrate itself.

That substrate hardening was shipped by a Trident sprint.

Case 3: The Neutron PR that fixed the Forge wedge

Through April and early May 2026, spawned Forge processes were sometimes staying alive 30+ minutes after delivering results. The Stop hooks never wrote the completion event. The watchdog eventually SIGTERMed the orphan PIDs. Trident runs that depended on those completion events sat polling.

The eventual root cause turned out to be in Neutron’s gateway code, not Vajra’s. Bun.serve wrappers were calling server.stop() with the default closeActiveConnections=false. Idle keep-alive sockets stayed attached to Bun’s event loop after shutdown, so bun test would hang at suite end, the parent claude -p would never exit, the gateway’s completion-event writer would never fire.

Forge fixed this in Neutron PR #44, commit f145db9. Forceful close on test-mode shutdown for the three production Bun.serve wrappers (gateway/index.ts, landing/boot.ts, identity/main.ts) plus an audit pass on test fixtures that were discarding the unawaited stop promise. Argus approved round one.

The next twenty Forge runs in the Neutron repo exited cleanly. The Trident loop stopped getting wedged on phantom completion events. The substrate fixed itself, via the substrate.

Case 4: The spec-conformance audit rule was born from an integration test that never integrated

Earlier I quoted the spec-conformance audit pattern as the way Forge briefs in the Neutron repo are now written. That pattern is mechanically enforced by a rule in ~/repos/neutron/CLAUDE.md dated 2026-05-13, titled “Spec is the source of truth, HARD RULE.”

The rule reads, verbatim:

Code always follows the spec. Spec changes flow spec-first, then code. No exceptions.

  If during a sprint you discover the implementation needs to diverge from the spec, STOP coding. Update the spec. Get sign-off on the spec delta. THEN resume coding.

  Forbidden patterns: placeholder phase-prompt bodies that ship as no-ops; integration tests that only assert phase-machine bookkeeping; end-to-end walkthroughs that SQL-stub past phases; sprint briefs that scope a symptom without auditing the spec.

That rule did not exist on 2026-05-12. It exists because of an incident.

The Neutron onboarding flow has a series of phases. The spec says specific synthesis pipelines (persona generation, history import) must fire at specific phases. On inspection one night I found that the phase handlers contained hardcoded prompt strings where they were supposed to invoke the synthesis modules. The placeholder behavior had shipped to prod for months. The integration test suite was green because it asserted phase-machine bookkeeping (phase advances, button registers, next prompt emits). None of the integration tests asserted that persona.generate() or history.import() had actually been called.

The fix was four hours of Trident sprints to wire the modules in correctly, but the rule is the durable artifact. Future sprint briefs on a spec’d subsystem must include the SPEC / CURRENT / GAP / FIXES / OUT OF SCOPE block. Future integration tests must assert every spec’d module invocation explicitly. Argus checks for both during review.

Trident is the executor of this rule. The rule is enforced because every Forge brief that goes into Trident now includes the audit block, and Argus rejects sprints that did not honor it. The substrate enforces its own discipline.

Part 4: What this enables

Two hundred and seventy-one PRs across two repos, shipped autonomously, with cross-model review and a human gate at merge. One operator. That is the headline number. The shape underneath is more interesting.

The constraint that keeps it honest is that every change still goes through Argus and ultimately through me. I press the equivalent of a merge button (it is in fact automatic when Argus approves, but I see every state transition in real time on Telegram and can stop a run with /trident stop). There is no fully autonomous deploy. There is no autonomous infrastructure change. There is no autonomous external communication. Argus produces a verdict; the human chooses whether to ship.

The shape this collapses is the build-review-fix-deploy cycle for the class of work that is well-specified and bounded. Adding a watchdog, fixing a race condition, building a Tier 1 feature against a spec that already exists, writing a containment audit on a new filesystem walker. None of these need my hands on a keyboard. They need my judgment on the brief and my judgment on the merge. Trident handles the rest.

The failure modes are real. I wrote about eleven of them in the prior post. Each of those eleven, plus the new ones I will hit next month, will get logged in ISSUES.md. The good ones will get filed as Trident sprints. The substrate will keep improving itself, with a human reading the diffs.

The Trident skill is currently local to my Vajra repo. The next move is exposing the same loop as a Core inside Neutron, so any Neutron operator can issue a /trident on their own codebase against their own substrate. Forge and Argus are already general-purpose; the orchestration loop is 480 lines of skill code; the state file is JSON. None of it is special to my use case. The thing I built for myself works for everyone who runs into the same human-review bottleneck on the same shape of bounded, well-specified work.

I’m not making the claim that this is a general theory of autonomous software engineering. It is not. There is a long list of work this approach cannot do. Architectural decisions. Cross-system migrations. UX calls. Anything where the spec is the deliverable, not the input. Anything where the failure mode is “the entire premise was wrong.”

What it does do is take the class of work where I previously was the bottleneck and move me to a higher position in the loop. I write briefs. The substrate writes code. Argus catches what I would have missed if I were reviewing at 11 PM. The pipeline ships. And occasionally, the pipeline rewrites itself.

Prior art and further reading

Trident is not from-scratch invention. The pieces it sits on top of are public and credited here for anyone who wants to build something similar.

I'm productizing this substrate as Neutron for operators who want a real agent system without rebuilding it themselves. Separately I take on a small number of consulting engagements per quarter for teams shipping into production. Services →

← All posts