Who wrote this code? AI provenance starts with the wrong question

A customer loses access to a feature after a pricing change.

The code path is easy to find. git blame points to a commit from three weeks ago. The commit is clean: one eligibility condition changed, tests updated, pull request approved. The diff was written by an AI coding agent, but the commit sits under an engineer's name because that is how the work entered the repository.

Now answer the question the customer actually forced onto the table: why did eligibility change?

The commit message says "update plan checks." The issue says "align with new pricing." The agent transcript is gone. The Slack thread contains four proposals and no obvious verdict. Product remembers agreeing to one exception. Engineering remembers a different one. Everyone can see who touched the line. Nobody can prove which decision the line was supposed to implement.

That is the provenance gap AI-generated code is exposing. We keep asking who wrote the code when the harder question is who decided what the code should mean.

A commit is a location, not an explanation

Git gives teams an excellent record of state. It shows that a file changed, which commit changed it, who authored and committed the snapshot, and how the repository moved from one version to the next.

That record was never designed to carry the full chain of intent behind every line. Even with human-written code, the why leaks into issue trackers, planning docs, review comments, calls, and memory. AI agents widen the leak because one visible commit can compress an entire hidden process: prompt, retrieved context, tool calls, generated alternatives, test results, human corrections, and approval.

Attribution metadata can recover part of this. The emerging git-ai standard, for example, defines a way to record AI authorship information alongside Git work. That is useful. A team should be able to tell where AI contributed.

But "an agent generated these lines" still does not tell you why the lines are right.

The same model can implement two opposite pricing rules. The same agent can remove a feature because product cut it, or because it misunderstood an empty flag. Model identity answers an attribution question. It does not answer the decision question.

Four records, four different truths

Teams are starting to group several kinds of traceability under the word provenance. Separating them makes the missing layer easier to see.

Commit provenance tells you how the source tree changed: author, committer, timestamp, parent, diff.

Agent provenance tells you which model, agent, session, or prompt contributed to the change.

Build provenance tells you how source became an artifact. SLSA provenance is built around verifiable claims about where, when, and how an artifact was produced. GitHub artifact attestations let a project establish signed provenance for binaries and container images.

Decision provenance tells you why the change exists: the active team decision, its owner, its reason, the alternatives rejected, the evidence used, and the approval that allowed the agent to act.

These records do not compete. They form a chain.

A build attestation can help prove that an image came from a particular repository and workflow. GitHub is explicit that an attestation is a signed claim, not a guarantee that the artifact is safe. In the same way, an agent trace can prove that a model generated a patch without proving that the patch matches the product decision.

You can have perfect artifact integrity and still ship the wrong pricing rule.

The missing link is the decision

Imagine an agent receives this task: "Update the free plan eligibility logic."

It searches the code, finds isEligibleForFreePlan, notices that company accounts are excluded in one service but included in another, and makes them consistent. The tests pass. The change is technically coherent.

What the agent did not see was the product call from last Tuesday: company accounts remain eligible during an ongoing migration because sales promised continuity to twelve customers. That exception lives in a meeting note and one message from the product lead. It never reached the agent.

A useful provenance record would connect the resulting code to facts such as:

• the request that triggered the change;
• the active pricing decision and the person who owns it;
• the migration promise that constrains eligibility;
• the alternative the team rejected and why;
• the files, tests, documents, and evidence the agent used;
• the review and approval that allowed the change to land;
• the commit, deployment, and customer-visible behavior that followed.

Without that chain, an audit trail becomes a pile of timestamps around an unexplained outcome.

This is especially dangerous when several agents share a codebase. As we saw in the multi-agent memory problem, two agents can produce individually reasonable changes from different versions of the truth. Decision provenance lets a team detect that split after the fact. Shared decision memory prevents it before the code is written.

Saving every prompt will not fix this

The obvious answer is to retain complete agent transcripts. Keep every prompt, response, tool call, and generated token. Then nothing is lost.

Except the answer is still buried.

A long transcript may show what the agent saw. It may not show which statement was authoritative, whether the underlying decision was still active, who owned it, or whether a human approved the final interpretation. Storing everything shifts the problem from missing evidence to unusable evidence.

It creates a second problem too: agent sessions can contain credentials, customer data, copied messages, internal documents, and irrelevant context. Treating raw transcripts as the permanent company memory expands the privacy and security surface without guaranteeing that anyone can reconstruct the verdict later.

Useful provenance is selective. Keep the evidence needed to explain the change, not every scrap that passed through the context window.

What a team should record

For consequential agent work, the provenance record needs a small set of linked facts.

Trigger. What request or event started the work? This might be an issue, incident, customer commitment, or product change.

Active decision. What settled call was the agent expected to honor? State the verdict directly, not as a link to a conversation someone must re-read.

Owner and approval. Who had authority over the call, and what did they approve? Agent execution should not blur the difference between a suggestion, a delegated task, and an approved change.

Reason and rejected alternatives. Why did the team choose this path, and what did it deliberately not choose? This stops a future agent from presenting a settled rejection as a new idea.

Evidence used. Which code, tests, documents, incidents, and customer facts shaped the work? Evidence makes the path reviewable without preserving an entire session.

Agent contribution. Which agent or model proposed or wrote what? This is where AI-specific attribution belongs.

Result. Which commit, pull request, artifact, deployment, or product behavior came from the work?

Replacement history. If the decision changes, what replaced it and why? Provenance that can be silently overwritten is only a current note wearing an audit-trail costume.

This record should follow blast radius. A renamed local variable does not need a product decision attached. A pricing boundary, data-retention rule, public API shape, permission model, or customer promise does.

Provenance is a product question

It is easy to make AI code provenance sound like a compliance feature for engineering. That framing is too narrow.

When product asks why a feature was cut, the answer should connect the current behavior to the call that cut it. When support asks why one customer sees a different plan, the answer should point to the exception and its owner. When an engineering lead reviews a sweeping agent-generated change, the review should show which active decisions it touches. When a developer refactors the code six months later, the constraints should survive the rewrite.

The whole team is asking different versions of the same question: can we trace this product behavior back to an intentional, owned decision?

If the answer is no, knowing that Claude, Codex, or a human typed the line does not rescue the team.

Where Lockstep fits

Lockstep gives teams a decision-memory layer for work done with AI coding agents. A decision is captured with its verdict and why, tied to an owner, ranked by blast radius, and preserved when a later decision replaces it. Through get_product_context, any MCP-compatible agent can receive the relevant active decisions before it changes code.

That creates both sides of useful provenance. Before the change, the agent gets the constraints it must honor. After the change, the team can trace the code back to the decision that shaped it, instead of searching old chats for a sentence that might have been the verdict.

The next generation of codebases will contain more work produced by agents, more quickly, across more parts of the product. "Who wrote this line?" will matter.

"Why does this line exist, and who decided it should?" will matter more.