How it's built
Four maps of how it works.
1 · How code ships
How code reaches the households
A self-hosted delivery pipeline, built by hand from need and then mapped onto standard delivery vocabulary. It matched.
Automate what needs no judgment; keep a human on what does.
Rollback is mechanical, so it fires unattended. A fix needs a brain, so it waits for a person — because the easiest way to turn a red test green is to weaken the test.
“Didn’t run” is not “passed”.
A check that couldn’t run, or a change set that couldn’t be computed, is red — never rounded to green.
What a standard delivery platform adds
Arriving at the same primitives proves I understand them. What I’d gain by adopting one:
- GitOps reconciliation — a controller keeps the live system matching the repo, continuously, instead of only at push time.
- Managed progressive delivery — real canaries that ship to one household first; my fleet shares one image, so a bad build is fleet-wide.
- Identity-separated runners — short-lived, least-privilege credentials per job; mine uses one long-lived privileged credential and rests on the network perimeter.
- Delivery metrics for free — the four DORA measures, dashboards included.
The full vocabulary map
| What I built | What delivery pipelines call it |
|---|---|
| Quick checks that refuse a broken push before it leaves my machine | Pre-push hooks (shift-left) |
| A push is a human decision, so the push is the approval | Trunk-based delivery, perimeter as the control |
| One household that exists to be broken by tests | Staging tenant / blast-radius control |
| “Deploy only the parts whose files changed since they last deployed” | Path filters + a per-unit revision ledger |
| Practice mode is the default; arming is explicit | Dry run / fail-safe default |
| Parts too risky to bounce automatically get a flag, not an action | Manual approval gate |
| Snapshot the running version before building the new one | Last-known-good image tag |
| Household health table + post-deploy tests | Verification gates |
| Undo automatically on red | Automated rollback (cuts time-to-restore) |
| Failure files a ticket; an agent fixes; a human pushes | Roll-forward behind a human approval gate |
2 · How the agent works
How the agent runner works
An autonomous agent that works its own queue: an explicit state machine with a checkpointer and a hard human approval gate, built from first principles and later mapped onto standard agent-framework vocabulary.
What an agent framework adds
Arriving at the same primitives proves I understand them. What I’d gain by adopting one:
- A standard graph API — the next engineer reads a known shape, not my bespoke control flow.
- Visualisation and tracing for free — this diagram had to be drawn by hand.
- An ecosystem — ready-made nodes, integrations, checkpoint backends.
- Other people’s bug reports — every edge case I hit alone, thousands have already hit.
The full vocabulary map
| What I built | What agent frameworks call it |
|---|---|
| Task status that survives restarts and crashes | State (persisted graph state) |
| “Anything to do?” · “Did it report back?” | Conditional edges |
| One agent turn: the model reasons and calls tools | Agent / LLM node |
| The task queue, version control, commit helpers | Tool nodes |
| A baseline snapshot + attempt counter, so a killed run resumes where it was | Checkpointer (durable execution) |
| The review gate the agent cannot pass on its own | Human approval gate |
| Chaining several related tasks in one warm session | Beyond the vanilla graph — custom |
3 · How services run
My platform mapped onto Kubernetes
I built the equivalent by hand, from need, and can map it primitive for primitive. I don’t run Kubernetes — this shows which of its pieces mine correspond to, and where they don’t.
What Kubernetes adds
Each piece above is its own hand-built mechanism with its own failure modes — about five separate systems for reconciliation, restarts, scheduling, routing and isolation. Kubernetes makes them one model: one declarative spec, one control loop, one way to route, isolate and schedule. The value isn’t any single primitive — it’s that they’re the same substrate, so they compose, and everyone who’s run it before has already hit my bugs.
4 · How you know
How you know the agent did it
Proof is made at the tool, checked at the boundary, and audited in the agent’s reply — built from need, then mapped onto standard reliability vocabulary.
Absence of evidence is not evidence of success.
An empty search, a quiet error stream, a job that hasn’t reported back — each one used to read as “fine”. Every piece above exists to make “I don’t know” look different from “it worked”.
What the standard tooling adds
Arriving at the same primitives proves I understand the problem. What I’d gain by adopting the standard tools instead of my own:
- Tracing for free — OpenTelemetry gives every tool call a span; I built my own trace.
- Schema validators — off-the-shelf libraries enforce the contract I hand-check.
- Contract tests — Pact-style tests catch producer/consumer drift before deploy, not after.
- Signed proof — signed attestations make receipts tamper-evident; mine aren’t signed yet.
Building something similar, or think I could help? I’m always up for a conversation.
Email me →