Kizuna: where AI agents build software under your rules

Open the commit history of a repository where a coding agent has been busy for a month and look at the author column. You’ll usually see one name, over and over. A bot account. Maybe it’s the CI service user, maybe it’s an app someone installed in a hurry during a trial. Hundreds of changes, some written by a person, some by an agent, some by an agent a person nudged halfway through, and the forge records all of them as the same anonymous helper.

That was fine when automation meant a dependency bot opening one pull request a week. It stops being fine when agents write a real share of the code you ship.

I spent years building payments and trade-finance systems, where the first question after anything goes wrong is always the same. Who did this, and who said they could? On most forges today, if an agent was involved, the honest answer is that we’d have to piece it together from commit messages and memory.

Forges assume a person at the keyboard

GitHub and GitLab are very good at what they were designed for. Their design assumption is that a committer is a human, perhaps with some scripts, and that identity hangs off a human credential: an email, a personal token, an app a person authorised.

Every control downstream inherits that assumption. Branch protection asks whether the committer belongs to a group, and the agent belongs to whatever group its token belongs to. Review rules ask for an approval, and nobody checks whether the reviewer read the agent’s change or the summary the agent wrote about its change. Build artefacts are signed by the pipeline, which tells you the pipeline ran and nothing about what asked it to.

None of this is negligence. It’s what happens when a tool built for one kind of participant meets a new one. But it means a team adopting agents seriously inherits a gap at exactly the point where work becomes software. You can govern the agent’s prompt, its model, its budget. If the place where its code lands treats it as an odd colleague with a shared password, the rest doesn’t add up to much.

Supply-chain risk in the agentic era goes further into why this matters now. My short version: agents make more changes, faster, than any review culture was built for, and the forge is where that pressure lands.

What Kizuna is for

Kizuna is the place where AI agents build software under your rules. It’s half of what we’re building at Deep Thinking. The other half, Voxeltron, is where that software goes to run.

We started from four outcomes rather than a feature list.

Every agent has its own identity. No shared token, no bot account standing in for ten different things. When an agent opens a change, the record says which agent it was and what it was allowed to do at that moment. When you stop trusting an agent, you can stop it, and its past work stays attributed to it.

Work is checked independently. The agent that wrote the change doesn’t get to be the one that says it’s fine. Tests, checks and your own rules run on the change itself, separately from the agent that produced it, and the result becomes part of the record.

People approve what matters. You decide which kinds of change need a human and which can go through on their own once the checks pass. A schema migration on a payments ledger and a typo in a README shouldn’t wait in the same queue. The person at the gate should see what actually changed and why, in a form they can take in within a couple of minutes, which is the subject of human gates that don’t bottleneck.

And there’s one record per change. Who asked for it, which agent did it, under which rule, what was checked, who approved it, what shipped. Kept as the work happens, rather than assembled in a panic the week before an audit. Deterministic replay is the audit trail is about what that record needs to answer.

The rules are yours, and that’s the part I care about most. Every organisation already has rules about who can change what. They just live in wikis and in people’s heads. Kizuna is meant to make those rules the thing agents work inside, so that letting an agent do more becomes a decision you make on purpose, with evidence, instead of something that drifts.

I’ll be plain about where we are. Kizuna is in development. We don’t have customers yet, and we’re opening a small pilot programme to build it alongside teams who feel this problem now.

Questions worth asking any forge

Whether or not you ever look at Kizuna, these are the questions I’d put to any tool where agents commit code. They’re quick to answer if the tool was designed for agents and slow if it wasn’t.

1. Does each agent have its own identity, separate from human accounts and from other agents? What happens to an agent’s past work after you revoke it?
2. When an agent tries something it isn’t allowed to do, what happens? Ask to see it. You want a refusal and a record, not a quiet success.
3. Who checks the agent’s work, and is that check independent of the agent?
4. Can you choose which changes need a person by the kind of change, rather than by repository?
5. For any change in production, can you see in one place who asked for it, what did it, under which rule, and who approved it?

Time the last one. If the answer today is “a few days, if the right people are around”, you’ve found the gap.

Why now

My bet is that the volume of agent-written code will keep climbing much faster than anyone’s ability to read it line by line. I don’t think the answer is to slow agents down. I think trust has to move from “someone read every line” to “the rules were followed, the work was checked, and the right person signed off”, and that has to be something you can show rather than assert.

The forge is where an agent’s work becomes permanent, so that’s where we started.

If you’re working on this, we’d like to hear from you.