I build agentic AI systems for public-record research, software work and creative production. I use frontier models where judgment matters, open-weight models on my own hardware where volume matters, and plain code where the result has to repeat. Each system below gets the problem, the decisions, what came of it, and what it does not prove.
My role
I decide what gets built and how, direct the agents that build it, and decide what evidence is enough to call it done. AI coding agents write most of the code. I run them the way I ran a sales territory: written scope, acceptance criteria frozen before work starts, software rather than a model checking the result, and a receipt for every decision.
MIT licensed · six plugins · 16 of 16 scenarios and 54 of 54 checks passing
fixes submitted upstream to vLLM, the inference engine
2
pull requests 56026 and 56028 · both open
public funding records Municipal Intel reads
1.9M+
100+ sources · 2,000+ municipalities seeded across seven states
re-prompts in one unattended session, before I built the brake
988
8 re-prompts over two simulated hours after it · the field note has the receipts
What runs where
Most of the craft is matching the model to the job and keeping the token spend sane. This is the current line-up.
What runs where
Job
Model
Why
Planning, review and judging the work
ModelClaude, hosted; OpenAI and Gemini inside Municipal Intel
WhyThe calls that need the best reasoning, each with a receipt.
The volume: workers, finders, summarizers
ModelQwen 3.8 27B on vLLM, quantized to NVFP4, on my own hardware; Kimi K3, GLM and DeepSeek hosted when I need more lanes
WhyAn open-weight model on my own GPU does the bulk work without a cloud bill, a couple at a time within the memory budget, and I reach for hosted models only when I need more lanes.
Jev (TypeSafe), a model that answers typed questions with a probability, used as an advisor only
What I've built, and why it's built that way
Seven systems in three groups. For each one I start with the problem it solves, then the handful of decisions that shaped it, then what the evidence shows, including what it doesn't.
Model operations: keeping local model services usable
Changing a model or sharing one GPU can interrupt everyone's work. These three systems make changes deliberate, failures visible and limits fair.
Swapping a live local model without losing service
Problem. Swapping the model a team depends on can take the whole service down, with no clean way back.
Decisions
Every change is a dry run first, and writes a receipt before it acts.
A process is stopped only when its id, start time and command line all match. Nothing is killed by name.
An engine must report idle three times before it is stopped.
Health is read from live metrics, after a hung engine kept answering "healthy".
Outcome. After a swap, given a very long document, it still finds a fact planted 139,994, 179,978, 219,962 or 234,914 tokens in. Cold start to ready fell from 5:13 to between 3:45 and 4:04.
Measured on one machine, in evaluation; not yet signed off as accepted.
Fixing the inference engine itself
Problem. On a hybrid model, very long prompts crashed the engine or re-ran from scratch in a loop.
Decisions
Traced it to the root cause: two parts of the engine disagreed on how large a block of memory was, so very long prompts crashed it or looped.
A request that can never fit now ends with a clear error instead of looping.
Outcome. A 250K-token request that extends a 140K one now finishes in 11.5 seconds instead of 25.6. I submitted both fixes upstream to vLLM.
Both pull requests are open and awaiting review, not merged.
Problem. Put several people on one model server and they evict each other's cached work, and everyone gets slower.
Decisions
Each key gets its own model list, request rate, parallel limit and prompt-size cap.
Before maintenance the gateway pauses new work and drains what's running.
If a model is down, callers get a clear error, never a silent switch to a different model.
Outcome. The prompt-size cap came from a measurement: one user's long prompts hit the cache on 3 of 45 requests, and output speed fell to 42.8 tokens a second against a healthy 196 to 250.
Serves a handful of people, not a fleet, and nobody pays for it.
Agent workflows: keeping agent work in scope and checking completion
Long agent runs stall, widen their own scope, or report work as done before it is proven. These three systems separate implementation from verification and write down every hand-off.
Keeping long agent runs alive without a babysitter
Problem. Agent sessions on local models stall, loop on one file, or just sit there waiting for someone to type "continue".
Decisions
Re-prompt only sessions with work left to do, and back off: one blocked session was re-prompted 988 times at 39 s before the brake existed.
At most two subagents at once, because the model server's memory holds about two live requests. Extra calls wait in line; they never fail.
Nudges go into tool output, never the system prompt, so the model's cached work stays usable and nothing is recomputed.
Agents can't rewrite their own configuration.
Outcome. Published as open source under the MIT license: six plugins, 139 tests and a frozen 16-scenario eval, all passing. In the eval, a blocked task got 8 re-prompts over two simulated hours instead of about 184.
It was built for one person's setup. In the published version the machine-specific parts are configuration, not code.
Handing work from agent to agent without losing it
Problem. Subagents lose context at every hand-off, widen their own scope, and stop mid-task with nothing written down.
Decisions
Every hand-off is a written artifact: a scope brief, a frozen contract, a commit with notes, a signed receipt. The next agent reads that, not the chat.
Each role gets only the permissions its job needs. The finder, the contract judge and the reviewers can read but can't run or edit anything.
Delegation is one level deep, from a list of 20 named subagents. A subagent can't start another.
A worker that runs out of steps saves a checkpoint for one continuation. If it stops without notes, a summarizer writes what was tried and ruled out, so the next attempt doesn't repeat it.
Outcome. The replay below is one ticket through this hand-off: the worker said "done" twice and was turned back 5 times before the merge. The two-at-a-time cap ships in the open-source harness with 9 tests, including first-come, first-served order for calls that wait.
Not yet measured: whether splitting the work across roles beats one strong agent.
Problem. Left to itself, an agent will report work as done that it hasn't proven.
Decisions
The verifier is software, not a model. It signs its checks against the exact commit.
The acceptance criteria freeze once written.
A fresh-context reviewer reads the work, then an independent judge decides the merge.
"Passed", "approved" and "pull request opened" are three different states. None of them means done.
Outcome. The chain's final validation passed 72 tests.
Whether the chain beats a single agent is not proven yet, and its own plan says so.
Retrieval: documentation an agent can trace to its source
Coding agents answer from stale memory. This system gives them the documentation for the version in use, with the source on every chunk.
Search that cites the version it came from
Problem. Coding agents answer from memory, which is often stale, instead of from the documentation for the version you actually run.
Decisions
One search matches identifiers, meaning and keywords at the same time, and a reranker puts the best evidence first.
Every chunk carries its source, version, license and commit.
Test sets are frozen and identified by hash, so a change can't move the goalposts without being noticed.
"Not found" never means "does not exist".
Outcome. 1.93M passages from 239 sources, served to agents over MCP. Adding the reranker raised the share of test questions answered with the right evidence from 78% to 89%, with a median search time of 244 ms over 269 searches.
Self-measured on my own test set.
Harness scorecard
A 2026 study of 97 open-source agent harnesses found 60% had neither tests nor evals; 7 had both. Here is mine, scored the same way. Most agents stop the moment nobody is watching. Mine notice the stall and keep going, with brakes on how often they try.
Check
What it means
Mine
Disclosed harness
Published, MIT licensed, so anyone can see what runs around the model
This is a real run, reconstructed from its receipts. A worker proposed a fix for a data-consistency bug, two database reads seeing different snapshots so an item could show up twice or vanish from a ranked list, and what follows is everything that happened between that proposal and the merge, each hand-off, failure and decision included. It shows the review process for one task. It is not a comparison of developer productivity.
The decisive moments
+0:50Fifty minutes in, the worker reported the fix complete. The verifier first proved the test could catch the bug on the old code, then ran it on the worker's commit: 17 passed, 1 failed. The run was turned back with a finding.
+1:14The first repair failed the same size-limit check. Second receipt, second commit.
+3:11By +2:25 the fix passed its tests and a fresh-context reviewer approved it. The independent judge did not: a new query broke an existing test, and a generated index was stale.
+6:50The reviewer got checked too. Twice the verifier refused the reviewer's pass because its report left out the contract version and three of the clauses.
+9:26After 26 tests and a clean smoke run, the judge approved and the manager merged. Then the run waited for my sign-off, because merged and accepted are two different states.
The full run, step by step
start to merge
9h 26m
times the worker said "done"
2
rejections before the merge
5
13 steps.
ManagerContract frozen
Opens the task and freezes a 12-clause acceptance contract before any code is written. A contract review later adds clauses; it ends at 20.
Worker"Done"
Reports the fix complete: one database statement per page instead of two, 3 files changed.
System One checkAdvisory
A typed judgment model checks that the worker's description matches the actual diff, in under a second. It advises; it never decides.
Verifier (software)Bug reproduced
First, the verifier runs the proof test on the old code and confirms it fails there. A test that can't catch the bug proves nothing.
Verifier (software)Fail
Then it runs the named tests on the worker's commit: 17 pass, 1 fails. The list doesn't stop at its size limit.
Signed receipt bound to the exact commit; a priority finding is opened.
Verifier (software)Fail
The first repair arrives. Same tests: 17 pass, and the same size-limit check still fails.
Second receipt, second commit.
Verifier (software)Pass
The second repair passes: 18 tests, then 22 after a follow-up commit, and a clean smoke run.
ReviewerPass
A fresh-context reviewer reads the work against every clause of the contract and passes it, with 3 advisory notes. The pull request opens.
JudgeChanges requested
The independent judge overrules the reviewer: a new query broke an existing test, and a generated index was stale.
Two findings, each with the failing check.
Verifier (software)Pass
The worker fixes both findings and says "done" again. This time the verifier agrees: 26 tests pass, smoke run clean.
Verifier (software)Review rejected
Even the reviewer gets checked. Twice the verifier refuses the reviewer's pass because the report left out the contract version and 3 clauses.
The reviewer re-issues a complete report.
JudgeApproved
The judge re-reviews the updated work and approves it.
ManagerMerged
Merged. The run then waits for my sign-off, because merged and accepted are two different states.
No agent graded its own work. Software caught what the worker missed, the judge caught what the reviewer missed, and software caught the reviewer's paperwork.
From the run's receipts, September 2026. Times are elapsed from the start of the run; the names and the repository are removed.
How the pieces fit
I treat coding agents the way I would treat contractors I have not worked with yet. Each one works in its own worktree, nothing it writes reaches a branch without the checks, and no agent approves its own output. One runtime sits under me, three kinds of work sit under it, and every arrow in the drawing is a hand-off that leaves a receipt.
Diagram: I watch every session of one agent runtime, which runs inside a harness (loop continuation, a two-subagent cap, a stall watchdog, a read-only config guard and a memory briefing). Under it are three columns. Models: a lane router in front of local vLLM and llama.cpp engines, a switch controller and a shared gateway. Work: manager, finder and worker agents, a software verifier, a fresh reviewer and a judge, then the repository and CI. Knowledge: docs search over MCP, hybrid search with a reranker, and sources with provenance. Everything writes to receipts and metrics.
Me, the owner
Every agent session runs where I can watch it live.
Agent runtime
Hosted model plans and reviews; local models do the volume.
How one ticket moves between subagents. Each one starts from what the last one wrote down, not from the conversation, and gets only the permissions its job needs.
1ManagerPrimary agent
Opens the ticket in its own worktree and dispatches each subagent in turn.
Hands on The ticket
2FinderRead-only
Confirms the problem exists in this checkout and traces who writes the data and who reads it.
Hands on A scope brief: acceptance clauses, allowed paths, and the proof each clause needs
3Contract judgeRead-only
Reviews the clauses and the proof plan before any code is written: approved, or numbered changes.
Hands on A frozen contract
4WorkerEdits its worktree only
Writes the failing test first, then the fix, inside the allowed paths. Runs no tests, never pushes, never changes the contract.
Out of steps: it saves a checkpoint, and a continuation agent resumes from it, once.
Stopped without notes: a summarizer writes what was tried, what was ruled out and what is left.
Hands on A commit and its notes
5VerifierSoftware
Runs the named tests on the exact commit and signs the result. A failure goes back to the worker as a finding.
Hands on A signed receipt
6Closure reviewerRead-only, fresh context
Reads the work against every clause, looking for what is missing. A pass means ready for the judge, not done.
Hands on A review report
7JudgeIndependent
Decides the merge, and can overrule the reviewer.
Hands on Approved, or changes requested
8MeOwner
Merged and accepted are two different states. Acceptance is my sign-off.
Result Accepted
How delegation is governed
The runtime can call 20 subagents by name. Anything not on that list is refused.
Delegation goes one level deep. No subagent can start another, so every run can be traced.
On a local model, two subagents run at once. The third waits its turn and never fails. A held slot is released when its tool returns, or after 40 minutes as a safety net.
The finder, the contract judge and the reviewers can read files but can't run commands or edit anything.
The worker can't rewrite files in place, hide work in a stash, or throw away a branch's history.
Between sessions, standing orders in an operator note ride along with every continuation. When a lane has finished its queue, adding a new line to its note starts it again within a minute, in a window I can watch.
No model where the result must repeatBulk data ingestion runs without an LLM, so the same input gives the same output, and re-runs are cheap.
Software verifies; models proposeA check that decides whether work is done is code, not another model's opinion.
Dry run first, receipt alwaysAnything that changes a running system says what it will do, records what it did, and can be rolled back.
Fail loudlyA clear error beats a silent fallback to a different model or a guess.
No self-written repair codeWhen a scraper breaks, an agent may re-route and propose a fix. It never writes and runs new code on its own.
Numbers come from receiptsIf I can't re-derive a figure from a log or a test, I don't use it.
How I build
I work with hosted frontier models for planning and review, and local models on my own GPU for the volume. Everything runs where I can watch it, and every change leaves a record.
In the open
The code that can be public is public, under the MIT license, so anyone can read what runs around the models.
a request that can never fit now ends with a clear error instead of looping
Where the systems get used
Municipal Intel
Independent work, built on my own time from public records.
Research software that reads what a municipality publishes, budgets, council minutes, meeting recordings, grant awards and announcements, and shows its strategic goals, what it is funding and what it is not. It joins what an agency needs, the money it has and the people who decide into one cited record, for anyone who wants to understand what their municipality is doing.
Contributor · a family-owned independent studio building games in Unreal Engine 5
I built the pipeline the studio makes its images, video, sound and animation with, on local inference, so the art is made in-house, there are no per-image API fees, and no source art ever leaves the building.
I'm training image and video models on the game's own art, so what they generate matches the look the studio already has.
When a model provider goes down or rate-limits us, the agents fail over on their own, with circuit breakers and a cap on retries. Hand-offs between agents are checked, so an empty plan or a missing reviewer verdict stops things early instead of late. And whoever is operating can see stuck sessions live.
Field notes
What running agents on my own hardware actually looks like, with the receipts. Reading notes on the research I'm building on, and designs I'd put in front of a team, sit alongside. Field notes come from receipts; designs say they're designs.
Most agent governance reads like an IT policy. The better model is one every sales leader already runs: territories, qualification, pipeline review and approval levels.