Developer Tools / Case study
Agent delivery harness
How AI agents ship our software, with every change checked before it lands
In short
Our agent delivery harness: board item → agent in an isolated worktree → deterministic gate → cross-vendor review → land. It is how we ship our own products with AI agents working in parallel.
- State
- In daily use
- Isolation
- One worktree per agent
- Gate
- Deterministic
- Review
- Cross-vendor
- Built with
- Git / TypeScript / Node.js
The brief
The problem
AI agents write code quickly and report success confidently, even when the work is incomplete. Run several at once and they collide in the same files. Let one grade its own work and it passes.
What we did
Our approach
We built a harness that checks the agents' work. Work starts as an item on a durable board with written acceptance criteria. Each agent gets its own isolated copy of the repository, so parallel work cannot collide. When it finishes, a deterministic gate (build, tests and checks that do not care what the agent claims) decides whether the work is real. A reviewer model from a different AI vendor then reads the change. Only work that clears both gates lands, and a person owns what ships.
Features
What it does
- 01
Durable work board with acceptance criteria
- 02
One isolated worktree per agent
- 03
Deterministic build-and-test gate
- 04
Review by a second AI vendor
- 05
Human-owned landing
Results
What happened
- Runs every day on our own products, including this website
- Parallel agents work in isolated copies and never share a working tree
- Nothing lands on an agent's own say-so: a deterministic gate decides
- A second model from another vendor reviews each change
- The board survives restarts and machine changes, so no work is lost mid-flight
Services
What this work shows we do
AI automation
Service pageModels wired into the tools your team already uses, with logs and limits.
Fractional CTO
Service pageTechnical decisions, hiring and delivery oversight, part time.
Related work
Built with the same services
- AI & Machine Learning
Fleet watchdog
Our agent fleet reported panes as idle while they were mid-command. We tested a hosted decision model against an open local one on the same small eval, then shipped a watchdog that overrides the fleet's own status only when the model is sure.
Read the case study 
Developer ToolsJarvisMCP
JarvisMCP gives AI agents one governed door into our company systems: CRM, search intelligence, infrastructure, memory and coordination. Agents find the capability they need, act through it, and leave a record. They never hold the keys.
Read the case study
How we work
How a change reaches production
The same five gates for our own products and for yours. Nothing reaches your customers on the strength of a demo.
- 01 · Isolate
Its own branch and workspace
Every change starts in a separate copy of the code, so work in progress never touches what is live.
git worktree add .worktrees/your-change - 02 · Build
Engineers with AI agents
Agents write and test code beside us. They hold no passwords: every call they make goes through our gateway, which checks it and logs it.
agent → gateway → policy · audit · call - 03 · Prove
Evidence, then review
Tests, before-and-after screenshots of the running app, then independent reviewers. It does not move on until no serious finding is left.
review: 0 high · 0 medium → pass - 04 · Ship
Deployed and checked live
The pipeline builds and deploys. Then we check the running service itself, not just a green build.
replicas 1/1 · image sha matches · health 200 - 05 · Watch
Checked every night
Each integration we run is tested against its provider every night, so a changed API is caught before your team notices.
nightly: each integration vs its provider