Provenance Became Part Of The Interface

The strangest AI interface problem right now may not be the chat box.

It may be the commit trailer.

That sounds too small to matter, which is why it matters. A line at the bottom of a Git commit is not glamorous. It does not demo well. It is not a new model, agent, benchmark, or glowing workflow animation. It is metadata. The kind of thing most people ignore until it is wrong.

Recently, the VS Code team had to explain and reverse a Copilot co-author attribution behavior after users saw Co-authored-by: Copilot appear in places where they did not believe Copilot had done the work. The issue is technical in the immediate sense: settings changed, defaults shifted, a bug misattributed some code. But the reaction was not only about settings.

It was about a more intimate question.

Who gets named on the work?

That question is going to follow AI agents everywhere.

GitHub is already moving in the opposite direction for its cloud agent commits: make the trace more explicit. Agent commits can be authored by Copilot, include the human task initiator as co-author, carry a permanent link back to session logs, and be signed so branch protections can treat them as verified work. Those are practical features. They help teams audit, review, and govern. They also reveal the shape of the future more clearly than another productivity promise.

AI work needs provenance.

Not as compliance garnish. As interface material.

For a long time, software tools treated authorship as a reasonably human thing. A commit had an author. A pull request had an opener. A review had a reviewer. The reality was always messier than the metadata. People paired. Suggestions came from teammates. Copy-paste came from docs, forums, previous projects, memory, and desperation. But the fiction held well enough because the person attaching their name to the change was generally the person assuming responsibility for it.

Agents make that fiction wobble.

If a human asks an agent to make a change, the agent plans and edits, another model reviews the patch, CI suggests a repair, and the human approves the final pull request from a phone, who authored the work?

There is not one answer.

There is initiator, operator, reviewer, approver, model, tool, organization, and system policy. There is the person who wanted the task done, the agent that performed the mechanical transformation, the model whose behavior shaped the result, the product surface that constrained the choices, and the company that will live with the consequence.

Flattening all of that into "co-authored-by" is too crude.

Ignoring it is worse.

This is why provenance belongs in the interface, not buried in legal language or audit exports nobody reads. People need to see enough of the chain to understand what kind of trust a piece of work deserves. Was this code written directly by a human? Was it drafted by an agent and edited carefully? Did the agent work from a tracked session? Which model or tool was involved? Was the change signed by the agent runtime? Did a human approve the final result with real attention, or merely clear a queue?

These details can become noisy if handled badly. No one wants every line of code wearing a bureaucratic name tag. But the absence of provenance creates a different noise: uncertainty that spreads socially. Teams start guessing. Reviewers become suspicious of work that looks too smooth. Developers feel misrepresented by metadata they did not consent to. Leaders ask for AI adoption numbers and get metrics that confuse tool presence with actual contribution.

Bad provenance makes the organization less honest with itself.

That is the deeper problem with accidental attribution. It is not only that Copilot might receive credit it did not earn. It is that a tool changed the social record of work without the user's clear consent. A commit message is not just a technical artifact. It is evidence. It travels into code review, compliance, release history, performance narratives, incident response, and sometimes employment politics.

When a product writes that evidence casually, trust takes damage.

The better pattern is beginning to appear in fragments. Signed agent commits. Links to session logs. Explicit consent before adding attribution. More precise language than co-authorship when assistance is the real relationship. Model information where it matters. Governance settings that acknowledge data residency, authorized models, and organizational policy as part of the development surface.

None of this is as exciting as saying the agent can write code by itself.

Good.

Excitement is not the standard.

The standard is whether a team can understand what happened well enough to maintain responsibility for it. That is the difference between automation as magic and automation as infrastructure. Magic asks you to be impressed. Infrastructure asks you to trust it on a Tuesday afternoon when something breaks.

This also changes what good AI design looks like. The mature interface will not simply make agentic work faster. It will make the authorship of that work legible at the right moments. Quiet most of the time. Available when needed. Precise enough to support review without turning every task into forensic accounting.

That is a hard balance.

Too little provenance and people cannot tell where responsibility lives. Too much provenance and every workflow becomes a courtroom. The humane version has layers: lightweight signals in ordinary use, richer traces during review, durable logs for audit, and clear consent whenever the system attaches a person's name to machine-assisted work.

This is not only a developer tooling issue. The same pattern will show up in documents, designs, analyses, sales emails, medical notes, legal drafts, customer support decisions, and workplace agents operating inside shared channels. Wherever AI work becomes normal, the question will return: who did this, with what help, under whose authority, and how do we know?

Provenance is usually treated as something that comes after creation.

In agentic work, it has to move earlier.

It has to become part of the product experience because trust is no longer attached only to the artifact. It is attached to the path the artifact took through the system.

The future will produce more work than we can personally witness. That does not mean we should surrender to opacity. It means the tools need to become better witnesses on our behalf.