AI Infrastructure

🧑 Me

The two places a person is required, and nothing automates either.

In the process

• Council stage 7, human approval: The run stops. The approval is bound to a hash of this exact plan.
• Blog stage 4, leak gate: CI on every pushed branch. Fails closed: a crash, an unreadable image, a bad path or too few patterns is a refusal, not a clean scan.
• Blog stage 7, merge: I read the diff and merge. The agents are told not to — an instruction, not a lock, which is why this is my step here and not one of the controls below.
• Every SOC alert: the analyst recommends; the decision is mine.

🏠 The lab

What the one mutating agent is allowed to change, and only inside a scope a human approved. The controls that hold that line are enforced in code, not asked for in a prompt.

What holds the line

• Approval binding — hash comparison. The approval carries a SHA-256 of the plan. Edit the plan afterwards and the approval is void, because otherwise 'approved' can quietly come to mean something else.
• Single use — consumed once. An approval is spent when the stage starts, and is specific to one run and one stage. No blanket approvals.
• Exclusive claim — atomic lock. Reuses the lab's existing claim tool — an atomic mkdir mutex — so a human working by hand sees the same lock the orchestrator does.
• Intent record — written before acting. Settled only when the outcome is known. An exception mid-change leaves it unsettled, and an unsettled intent blocks any automatic retry, because the lab may be half-changed.
• Dry run default — inert unless told. The default walks the whole pipeline and changes nothing. Mutating is a separate, deliberate act — a flag at the terminal, or a button on the dashboard that appears only when an unconsumed approval already matches the stored plan. Neither route can approve anything; both only spend an authorisation that already exists.
• Fail-closed redaction — every write and transfer. Secrets and internal addressing are stripped before anything is stored, displayed, or handed to another agent. A redaction failure fails the stage rather than passing the text through.
• Two usage ceilings — one outside my code. The orchestrator caps a run, and the gateway caps it again per project key, so a bug in the first cannot defeat the second. The figure is not money: the CLI agents run on subscriptions with no per-call billing, so the ceiling bounds plan consumption expressed in Claude-equivalent dollars.
• Load-time validation — refuses to start. A workflow that lets the wrong agent mutate, skips the human gate, or lets the mutator verify its own change is rejected before it runs, not caught halfway through.
• Leak gate — fails closed, every push. Runs on every pushed blog branch, not only on pull requests, because a pushed branch is already public. A committed file declares how many lab-specific patterns must load, so an unset or stale secret is a refusal rather than a clean scan. Its own planted-leak tests run first, every time, to prove it can still fail.

The lab, as a map →

⚖ Homelab Council

One request, three agents, a structured review rather than three opinions. The orchestrator owns the state; each agent is a subprocess that starts, answers and exits.

The process, start to finish

1. intake — One request in. A run id, and a row per stage.
2. context — One bounded, redacted pack — identical for every agent, so disagreement means real disagreement rather than different inputs.
3. round 1 — All three answer blind, and their answers are committed to disk before anyone sees anyone else.
4. round 2 — Each reviewer sees the others' findings, passed as labelled data rather than prose, and may revise or hold.
5. extra rounds — Only if an agent asks for one. The conversation is as long as the work needs, not a fixed count.
6. synthesis — The moderator merges into agreed points, contradictions, unsupported claims, a plan, and exclusions.
7. human approval — The run stops. The approval is bound to a hash of this exact plan.
8. execute — Claude only, inside the approved scope, with the intent written down before anything runs.
9. verify — Kimi and Codex — never Claude, because Claude made the change.

The write-up →

Stage 1 of 9 · intake

One request in. A run id, and a row per stage.

context →

Stage 2 of 9 · context

One bounded, redacted pack — identical for every agent, so disagreement means real disagreement rather than different inputs.

← intakeround 1 →

Stage 3 of 9 · round 1

All three answer blind, and their answers are committed to disk before anyone sees anyone else.

Who acts here

• 🤖 Claude Code — can change things
• ⚙ Codex — prepares, never deploys
• 🔍 Kimi Code — read-only

← contextround 2 →

Stage 4 of 9 · round 2

Each reviewer sees the others' findings, passed as labelled data rather than prose, and may revise or hold.

Who acts here

• 🤖 Claude Code — can change things
• ⚙ Codex — prepares, never deploys
• 🔍 Kimi Code — read-only

← round 1extra rounds →

Stage 5 of 9 · extra rounds

Only if an agent asks for one. The conversation is as long as the work needs, not a fixed count.

← round 2synthesis →

Stage 6 of 9 · synthesis

The moderator merges into agreed points, contradictions, unsupported claims, a plan, and exclusions.

Who acts here

• 🧩 Moderator — read-only

← extra roundshuman approval →

Stage 7 of 9 · human approval human gate

The run stops. The approval is bound to a hash of this exact plan.

Who acts here

• 🧑 Me — and no agent can supply this step.

← synthesisexecute →

Stage 8 of 9 · execute

Claude only, inside the approved scope, with the intent written down before anything runs.

Who acts here

• 🤖 Claude Code — can change things

← human approvalverify →

Stage 9 of 9 · verify

Kimi and Codex — never Claude, because Claude made the change.

Who acts here

• ⚙ Codex — prepares, never deploys
• 🔍 Kimi Code — read-only

← execute

🤖 Agents · 6

Different powers on purpose — the one that builds cannot be the one that signs off. Only one of these can alter the lab, and only inside a scope a human approved.

• 🤖 Claude Code — can change things
• ⚙ Codex — prepares, never deploys
• 🔍 Kimi Code — read-only
• 🛰 Kimi (SOC analyst) — read-only
• 🧩 Moderator — read-only
• 📝 Claude Code (blog repo) — opens a PR, never merges

🤖 Claude Code can change things

Coordinator, planner, and the only agent permitted to change the lab.

What it runs on, and under

• Read-only tools for every review stage; write tools only for the one mutating stage
• Runs under root-managed hooks that log every tool call to a hash-chained ledger
• Cannot verify its own change — the verification stage excludes it by design

Where it acts in the council

1. 3 · round 1 — All three answer blind, and their answers are committed to disk before anyone sees anyone else.
2. 4 · round 2 — Each reviewer sees the others' findings, passed as labelled data rather than prose, and may revise or hold.
3. 8 · execute — Claude only, inside the approved scope, with the intent written down before anything runs.

The write-up →

⚙ Codex prepares, never deploys

Implementation and test plans, and independent review of anything Claude proposes.

What it runs on, and under

• Reviewed the one security-control change Claude wanted, and recommended against it
• Ran the vulnerability scan that drove a full container remediation pass
• Has its own rate limit, so the council has to cope with it being unavailable

Where it acts in the council

1. 3 · round 1 — All three answer blind, and their answers are committed to disk before anyone sees anyone else.
2. 4 · round 2 — Each reviewer sees the others' findings, passed as labelled data rather than prose, and may revise or hold.
3. 9 · verify — Kimi and Codex — never Claude, because Claude made the change.

The write-up →

🔍 Kimi Code read-only

Independent read-only auditor and long-context reviewer.

What it runs on, and under

• Launcher verifies a checksum manifest over its own policy files before it will start
• Refuses prompt mode, session reuse and resumed approvals — so it cannot be automated
• Participates through a deliberate human handshake rather than a widened guard
• Audited the SOC analyst below, and correctly refused to confirm the network claims it had not tested itself

Where it acts in the council

1. 3 · round 1 — All three answer blind, and their answers are committed to disk before anyone sees anyone else.
2. 4 · round 2 — Each reviewer sees the others' findings, passed as labelled data rather than prose, and may revise or hold.
3. 9 · verify — Kimi and Codex — never Claude, because Claude made the change.

The write-up →

🛰 Kimi (SOC analyst) read-only

First-line security analyst over the SOC. Triages an alert, correlates the evidence, explains it and recommends what to look at. Never remediates.

What it runs on, and under

• A different path from the CLI above: the model is called with no tools, no shell and no filesystem, so the forbidden actions are structurally impossible rather than policy-enforced
• Two services split by what each may reach — the half that reads telemetry has no route off the machine, the half that talks to the model cannot read a log line
• Evidence is bounded and sanitised first: secrets stripped, private addressing pseudonymised, public addresses kept because those are the evidence
• The 'Automatic Actions Performed: NONE' line on every report is written by the code, not the model, which has no field it could use to claim otherwise

Where it acts

Not part of the council. It runs its own path: an alert in, a triage report out, nothing it can act on.

The write-up →

🧩 Moderator read-only

A fourth model that reviewed nothing, and merges what the other three found.

What it runs on, and under

• Runs on a free model on the local gateway, so the highest-volume step costs nothing
• Different model family from every reviewer — a jury argument, not a cost dodge
• Instructed never to resolve a disagreement by picking a side, only to state it

Where it acts in the council

1. 6 · synthesis — The moderator merges into agreed points, contradictions, unsupported claims, a plan, and exclusions.

The write-up →

📝 Claude Code (blog repo) opens a PR, never merges

A second instance that owns this blog's repository and never touches the lab. Turns a redacted handoff into a post and keeps the standing pages true to the lab.

What it runs on, and under

• Gets a handoff file, not access — the agent on the lab redacts before anything is pushed
• The two never share a conversation; the repository is the only surface they have in common
• Stress-tested the leak gate before the first real draft crossed, and found it reporting clean on a path that did not exist
• Opens a pull request and stops. Merging is publishing, and that stays with me

Where it acts in the blog pipeline

1. 5 · finish — The repo agent: voice pass, front matter, series, and every standing page and derived count brought back in line with the lab.
2. 6 · pull request — Lists every count it changed and how it derived it, and everything it proposed rather than was told.

The write-up →

🚪 Gateway

One endpoint for every model, with the spend limit enforced outside the caller.

What is running

• LiteLLM routes, authenticates and caps spend per virtual key
• Open WebUI for humans, behind single sign-on; the API takes keys, not logins
• Per-project keys scoped to specific models with their own budget

The write-up →

☁ Upstream models

Reached through the gateway, never directly: one endpoint, per-project keys scoped to specific models, each with its own budget. The CLI agents (Claude Code, Codex, Kimi Code) run on their own subscriptions outside the gateway, which is why the usage ceiling watches one seat and infers the rest.

What that means

• The usage ceiling watches one seat of three. Only one agent reports a figure at all, so the cap bounds that agent and infers the rest — it is a proxy for a subscription rate limit, not an account balance.

The gateway write-up →

🔭 Recorded

Every call recorded, so a claim about what an agent did can be checked. None of this stops a bad change; it makes a bad run legible afterwards.

What the plane records about itself

• Per-run attribution — one session per run. Every gateway call carries the run id, the agent and the role, so a council run is one tracing session rather than anonymous traffic indistinguishable from the chat UI's.
• Run scoring — five judgements. Panel completeness, unsupported claims, deadlock, the operator's decision, and whether the moderator followed its format first time. All were already computed and then discarded; now they can be compared across runs.
• Failure tracing — errors, not just successes. The gateway used to report only calls that worked. On a router with fallback chains the failures are the interesting part — a rate limit that triggered a fallback, a key missing a model from its scope.
• Regression dataset — verified ground truth. Real review requests whose correct answer was confirmed afterwards by running the command, not by agreeing with a model. Each carries the trap the panel actually fell into.
• Review interface — history, side by side. A local web dashboard behind single sign-on showing every run, and each agent's round 1 next to its round 2. The panel's value is the correction between them, which a scrolling transcript hides. It reads persisted state, records an approval, and can spend one — it holds no credential and never invokes an agent itself; a separate unreachable worker does that.
• Operational overview — across runs, not one run. Where runs stop, how each agent replied, plan usage per run, and average time per stage. Colour on that page means severity and nothing else — it is read like a log console, so red has to be worth looking at.
• Activity feed — merged from three sources. The event log carries only stage transitions. Agent replies and approvals live in their own tables, so a feed built from the event log alone would have shown a quiet lab on a busy day. All three are merged into one severity-coloured stream.
• Approvals ledger — everything that touched the lab. Every approval with its scope, actions, plan hash and who recorded it, and every declared execution intent with whether it settled. An intent that never settled means a change may be half-applied, and that is visible without opening the run.
• Homepage export — counts only. Separately from the dashboard, run counts go to a file served on an internal listener for the lab's front page. Ids, statuses and totals — never request text, replies or plans.

Langfuse → · The assurance plane → · The SOC →

📝 The blog, lab to site

Two agents that never share a conversation. The one on the lab writes and redacts; the one in the repository finishes and reconciles. Their only common surface is the repository itself, so the handoff is a file and the gate is code.

The process

1. draft — The agent on the lab writes the post after a project finishes, next to the real configs.
2. redact — Credentials, real addresses and image metadata replaced before the push — a pushed branch is already public, and deleting it retracts nothing.
3. push — One handoff file and its images, on a draft branch.
4. leak gate — CI on every pushed branch. Fails closed: a crash, an unreadable image, a bad path or too few patterns is a refusal, not a clean scan.
5. finish — The repo agent: voice pass, front matter, series, and every standing page and derived count brought back in line with the lab.
6. pull request — Lists every count it changed and how it derived it, and everything it proposed rather than was told.
7. merge — I read the diff and merge. The agents are told not to — an instruction, not a lock, which is why this is my step here and not one of the controls below.
8. deploy — Cloudflare Pages rebuilds the site from main.

The leak gate write-up →

Blog stage 1 of 8 · draft

The agent on the lab writes the post after a project finishes, next to the real configs.

redact →

Blog stage 2 of 8 · redact

Credentials, real addresses and image metadata replaced before the push — a pushed branch is already public, and deleting it retracts nothing.

← draftpush →

Blog stage 3 of 8 · push

One handoff file and its images, on a draft branch.

← redactleak gate →

Blog stage 4 of 8 · leak gate gate

CI on every pushed branch. Fails closed: a crash, an unreadable image, a bad path or too few patterns is a refusal, not a clean scan.

Who acts here

• 🧑 Me — merging is publishing, and that stays mine.

← pushfinish →

Blog stage 5 of 8 · finish

The repo agent: voice pass, front matter, series, and every standing page and derived count brought back in line with the lab.

Who acts here

• 📝 Claude Code (blog repo) — opens a PR, never merges

← leak gatepull request →

Blog stage 6 of 8 · pull request

Lists every count it changed and how it derived it, and everything it proposed rather than was told.

Who acts here

• 📝 Claude Code (blog repo) — opens a PR, never merges

← finishmerge →

Blog stage 7 of 8 · merge gate

I read the diff and merge. The agents are told not to — an instruction, not a lock, which is why this is my step here and not one of the controls below.

Who acts here

• 🧑 Me — merging is publishing, and that stays mine.

← pull requestdeploy →

Blog stage 8 of 8 · deploy

Cloudflare Pages rebuilds the site from main.

← merge