Blog · 28 October 2026

Blame that remembers why: what a change should carry when the author was an agent

This essay was written by an AI agent of 100monkeys.ai and reviewed for publication by the company. We build Carbon Forge, the source control it describes in its last section, so read that part as a maker's account.

Every engineer has run blame on a line that made no sense and found a name, a date and a commit message that said "fix". The name was a colleague. You walked over, or you sent a message, and the colleague remembered, or remembered enough. Blame was never really a record of why. It was a pointer to a person who held the why in their head.

That arrangement quietly assumes the author is still around and still remembers. When the author is an agent, both assumptions fail. The session that wrote the line is gone. Its context window was discarded an hour after it landed the change. There is nobody to walk over to. If the reason was not written down at the moment of the change, it does not exist anywhere.

So the question is worth asking directly: when the author of a change is an agent, what should the change carry?

The reason, in the author's own words, at the moment of writing

The first thing is the intent: one sentence the author wrote, before landing, saying what the change is for. Not a summary generated later from the diff. A diff can tell you what changed; only the author can tell you what it was meant to do, and the only time that sentence is cheap to get is the moment the author is about to land.

Humans write poor commit messages because the cost of a good one falls on the writer and the benefit falls on a stranger months later. Agents do not have that excuse. Asking an agent for one honest sentence of intent costs nothing, and a system that requires it on every landing gets it every time. The interesting design question is not whether to ask, but where the answer lives, and whether it survives.

The whole change, or none of it

The second thing is completeness. An agent asked to rename a configuration key will touch the code that reads it, the default file that sets it and the page that documents it. If those land as three separate events, there is a window in which the code and the documentation disagree, and if one of the three fails, the window never closes.

A change made by an agent should land as a unit: the code and the prose that explains it, written together or not at all. The reason this matters more for agents than for people is volume. A person makes a handful of these changes a day and notices a half-landed one. A fleet of agents makes many, and nobody is watching each one land.

No silent merges

The third thing is honesty about conflict. When two authors change the same thing, a system can either guess at a combined result or stop and say so. Text merging that guesses well most of the time is a reasonable trade for people, who read the result. It is a poor trade for agents, because the guess is made by neither author, and the record then holds a line that nobody intended.

A conflict should come back named, with enough context for the caller to decide, and the decision should be bound to the state the caller actually saw. If the ground moved again before the decision landed, the decision should be made again. That is slower in the rare case and much easier to audit in every case.

A history that cannot be rewritten

The fourth thing is permanence. The point of carrying the reason is to be able to read it later, and that only works if later readers can trust that the record they read is the record that was written. History that only grows, where an undo is a new change rather than an erasure, gives an auditor something to stand on. A release that names one fixed state of everything, and keeps naming it, gives the same guarantee for "what shipped".

Approval bound to exactly what was approved

The fifth thing is the human signature. When a person approves an agent's work, the approval should attach to the exact state they looked at. If the agent patches anything afterwards, the approval should stop counting. Anything looser turns review into a ritual: someone said yes to a version that no longer exists.

How we built Carbon Forge around those five

We build Carbon Forge at 100monkeys.ai, and the five properties above are the ones we designed it to hold. Each sentence below is what the product's public docs state.

Carbon Forge keeps code, files and prose in one record on the server, and people and agents read and write it through the same tools. An agent does not clone. It opens a lane, which is a set of patches over the trunk, and every read on the lane composes the trunk as it stands now with those patches.

A landing is one changeset: every page, code tree and file it names is written in one transaction, or nothing is. A code change and the page that documents it land in the same changeset, together or not at all.

Carbon Forge never merges text by itself. A patch that no longer applies is reported as a named conflict, and the caller answers it against the trunk it saw.

Every revision and every changeset is hash-chained, and a revert is a new landing, so history only moves forward. A cut names one sealed snapshot of the workspace and never moves, so a release has one answer for as long as the workspace exists.

On a protected trunk, a landing-rules page names the approvers each path needs, and an approval binds to the lane's exact state, so a later patch voids it.

And the property this essay started with: blame, grep, diff and history run on the server, and blame shows next to each line the intent the agent wrote when it landed it. Ask why a line is there, and the answer is the author's own sentence, written at the moment it mattered.

Two more things a skeptical reader will want to know. Git is a projection: every code tree renders to a git history and pushes to GitHub fast-forward only, so existing git tooling keeps working. And agents reach Carbon Forge over MCP with the same tools the editor uses, with tokens that can be held to a preset such as SCM reader, which writes nothing.

What we would like to hear

If you run more than one agent against the same codebase, the useful question is not which tool you use but what your record can answer a month from now. Pick a line an agent wrote last month and ask your system why it is there. If the answer is a name and "fix", the reason has already been lost.

Disclosure: 100monkeys.ai builds Carbon Forge, the record people and agents share, alongside AEGIS by 100monkeys.ai, an open-source agent orchestrator in beta, and Zaru, a companion that shows its work. This essay was drafted by one of our agents. Public Carbon Forge workspaces are free and every account includes one free private workspace. The source-control design is described in full here: https://carbonforge.dev/docs/p/features/source-control-on-the-substrate?utm_source=100monkeys.ai&utm_medium=article&utm_campaign=push-2026-10-28