Applied AI · August 2026 to present
A harness for AI coding agents near production
Built project skills, defined subagents and guardrails so AI agents could diagnose production safely, with a human approving every fix.
The problem
What was needed, and what made it hard.
The repository had a second author: an AI app builder that committed and deployed code without passing through my checkout. Early on, my local copy was behind production, which ran a function that did not exist on my disk. Agents also lost their context at every compaction, and a paid campaign was about to point real traffic at the system. I needed agents that could diagnose a live system in parallel and still could not break it.
The system
How one finding moves from diagnosis to production.
Select a component to read what it does and how it fails.
- Analysis agents. Each reproduces one issue, read-only against production, and writes one root-cause file. Parallel runs collided in a shared browser until each got its own context.
- Human approval. I read each root cause and approve a plan before code is written. The gate sits where blast radius changes, and I am the bottleneck.
- Fix agent. Plans first, then implements in its own git worktree after I approve. A stronger reviewer model is consulted before and after; I check its claims.
- Promotion chain. Fixes move through a chain of branches; the app builder's branch feeds staging. Agents cannot deploy infrastructure, and every task starts with a sync.
- Issue tracker. Anything undecided or broken lands here with root cause and plan, tagged found by AI or by human. Memory holds only per-machine facts.
Decisions
What I chose, what I turned down, and what it cost.
1Split diagnosis from fixing
- I chose
- Separate defined agents: analysis is read-only and runs in parallel, and fixing is plan-only until I approve, in its own worktree.
- I turned down
- Spawning ad hoc agents and tightening their prompts, after they started stepping on each other.
- Why
- Diagnosis is safe to parallelise and fixes are not. A live campaign raised the stakes, so the split sits where blast radius changes.
- What it cost
- Every fix waits for my approval, and each agent definition needs maintaining.
2Gate on a stronger model, then check it
- I chose
- I consulted a stronger reviewer model before and after implementing and before anything irreversible, and verified its claims against the data.
- I turned down
- Deferring to it, or skipping it to save quota.
- Why
- It caught a cross-tenant leak, a false claim in a vendor report and a hardening step that would have silently stopped load balancer logs. It also flagged an authorization risk in two functions that already enforced auth, so I did not act on it.
- What it cost
- Usage limits. I hit the weekly cap mid-test-pass, so mechanical agents moved to a cheaper model and only real diagnosis escalated.
3Keep knowledge in files, not chat
- I chose
- Rules, procedures and open problems live in versioned files. Each skill traces to a dated incident, and memory holds per-machine facts only.
- I turned down
- Leaning on session memory and long chats.
- Why
- Agents lose their working context at every compaction, and the files survive it. The sync-first skill exists because my copy fell behind production.
- What it cost
- A ritual before every compaction: update skills and memory, then compact. And discipline about which file a fact belongs in.
What broke
What I noticed, what caused it, and how I fixed it.
Agents racing in one browser
- What I saw
- Logging in as admin in one tab redirected another tab's signup page into the admin app.
- The cause
- Every tab shared one browser context, so one cookie jar.
- The fix
- Named, isolated contexts held in a registry on the automation server. I confirmed it persists across subagent calls before relying on it.
One agent's cleanup nearly erased another's work
- What I saw
- A fix agent's post-commit cleanup ran a checkout that reverted another agent's uncommitted changes. They survived only because that agent kept writing.
- The cause
- Two agents shared one checkout.
- The fix
- Each agent now commits from its own worktree and never discards changes it did not create.
A debugging loop
- What I saw
- The agent kept trying fixes for the auth crash loop and none held.
- The cause
- It was fixing before diagnosing.
- The fix
- I stopped it and reset the method: use the official docs actually in use, get the reviewer's read, read the logs as far as they go, log every attempted fix, then diagnose. The root cause followed.
Outcome
What came of it, and what it was built with.
- Nearly every skill and agent definition was written after a specific incident and is dated to it.
- Across two sessions from 16 August to 29 September 2026, I directed 55 of 155 reviewer-model consultations, and 20 of 55 subagent spawns came from my own definitions.
- These figures describe practice, not results. I have no speed, quality or cost measurement, so I quote none.
Built with
- Claude Code
- Subagents
- Project skills
- MCP servers
- Playwright
- Git worktrees
- GitHub Actions
- GitHub Issues
The rule I took from this
The line I keep from this project.
Split diagnosis from fixing where the blast radius changes.
Rule 2 of 10
Keep reading
Next case study · Applied AI
Skills and model routing for AI coding agents
Skills that hand agents current third-party docs, builds, tests and browser sessions, with each kind of task sent to the right model.
Also worth reading
Working on something similar?
Tell me what the system is doing, and what it should be doing.