The harness starter

The model is the engine. The harness is what makes it safe to leave running.

I run Sanvio Labs as one founder with a factory of AI agents. The harness is what holds it together. The starter is the smallest version of it I'd trust, and it's free.

Listen to this page

5 minutes, the text below in Pat's voice (an AI clone, made with ElevenLabs)

Clone the starter Read how we built ours

What a harness is

Everything around the model: the rules it reads, the procedures it follows, the checks that stop it, and the other agents it hands work to.

Claude Code, Codex and Kiro are all good out of the box. What a client pays for is the same good result on Tuesday as on Monday. The agent that wrote the code last week isn't the agent working on it today, and nothing it knew comes along unless you write it down somewhere it has to read. The harness is where that gets written down, and where it gets enforced.

You ask a coding agent to fix a bug. On its own it commits a .env file and the mistake lands in your repo. Then the harness appears around it: instructions it reads, steps it follows, a second reader, and checks that stop it. The same request again: the hook blocks the .env, the agent fixes it, the reader and the checks agree, and only then does it land. — The same request, without a harness and then with one.

What's in the starter

Six pieces, plus one worked job: drafting client proposals, because a proposal is where the cheap mistakes live. It works with Claude Code, Codex and Kiro, and needs Python 3.9 and no packages.

Standing rules

One file every session reads first: what the agent may do, what it never does, and what counts as done.

Skills

Named procedures with inputs, steps and an output. The agent follows one when a request matches it.

A gate

A script that fails when work isn't ready. The agent runs it, fixes what it names, and runs it again.

The git hook

The same gate and a secret check at every commit, whatever the agent decided.

The guard

Checks every tool call before it runs. Credential files are refused, and anything that would send or delete asks you first.

A review agent

A second reader in a fresh context. It reports what is unclear or over-promised and never edits.

Two loops that do most of the work

The first runs inside a session. The gate fails, the agent fixes what it names, and the gate runs again. Then git runs it at commit and CI on every pull request, so it doesn't depend on the agent's good intentions.

A change goes edit, test, hook. The hook blocks a committed .env, the change goes back to edit, and on the second pass it clears the hook, CI, review and a human merge. — Fix and recheck.

The second runs across sessions. When the agent gets something wrong, the correction goes into the file that governs that behaviour, dated, with the reason. If you only said it out loud, the next session never heard it.

In session 1 the agent pushes to main. You say learn from that, and the rule is written into AGENTS.md with the date. Session 2 starts with fresh context, reads AGENTS.md, and opens a pull request instead. — Mistake to rule.

Set it up

git clone https://github.com/SanvioLabs/sanvio-harness-starter
cd sanvio-harness-starter
git config core.hooksPath .githooks
python3 scripts/check_setup.py

Don't skip the third line. Git only runs the hook if you point it there, and the setting doesn't survive a clone. Skip it and every check in the hook does nothing, and nothing tells you. Already have a harness? Run git config core.hooksPath in your clone. If it prints nothing, your hooks aren't running either.

Where it goes: a factory per client

I think of this as a factory: a line that takes tickets in and puts reviewed pull requests out. The goal is a factory that runs itself, 100% autonomous. It isn't there yet.

Inside every factory there's a flywheel, and it's how the factory recognises its own mistakes. Each turn ends at a gate, and what it learned goes into the rules for the next turn.

Five phases on a wheel: Discover, Shape, Build, Validate, Scale. Each gate between them lights as the work passes and shows the question it asks, and the last gate starts turn two. — The flywheel: each turn ends at a gate, and what it learned starts the next one.

Each client gets their own factory, in their own repo, with their gates, their rules and their tests. And one factory can feed another. The starter came out of mine, and it's what a new one starts from. What passes between them is the method and the rules, never the material: one client's code and data stay in that client's factory.

Getting to 100% doesn't mean taking the person out on faith. Today a person still signs off on a run that stops and asks, a production change real users would feel, and anything that leaves the company. Each of those is a gate that hasn't earned trust yet. When a gate proves it catches what the person would have caught, the person steps back from that point.

The full story is on Substack: what broke, what each failure turned into, and the numbers.

Why it's free

I want you building the way I can build, quickly. AI is moving fast enough that the newest working methods have to be shared, or the people without them fall behind. And I'd like some of the people who pick it up to become people I work with.

It's MIT. I'm asking for one thing the licence doesn't: if you build on it, keep the line in each file that says where it came from, and link back to it when you write about it. Then tell me what you built. I'd like to see it.

AI Engineering Enablement

The starter gets you the shape. We build the one for your codebase.

Your rules, skills and gates in a repo your developers check out, review and release agents built for your code rather than pulled off a shelf, and the same harness running on every pull request. We build it with your engineers and stay on while they run it. They own it when we step back.

Talk about your team's setup Clone the starter