Your agent sessions are more important than your Git history

July 29, 2026

You want to understand a part of the codebase, so you run git blame to see who implemented it. Except it wasn’t really them, it was their agent, and that agent, along with the reasoning that went into that code, is long gone.

We’re working at a higher level of abstraction now, and the reasoning behind a change can vanish the moment the agent session that produced it ends, leaving nobody, human or agent, able to explain the exact “why” later.

This comes with a real risk: the reasoning behind a change can vanish the moment the agent session that produced it ends, leaving nobody, human or agent, able to explain the “why” later.

The Source Code stores the result, Git history stores the what and when

Whenever I bring this up, the first reaction is: the code is the source of truth. And of course it is! However, it encodes the result of the original intent, not the actual intent itself. If you’ve been developing software, you know what I mean. More than once I’ve come across an implementation and thought “this doesn’t look right,” only for a conversation with the developer to surface the tradeoffs or technical constraints that forced it into that shape.

Similarly, your Git history just tells you what changed and when.

As a result, whenever you need to debug something in your codebase or extend a functionality, you can

inspect the source
git blame to understand when it was added and who added it
reach out to your team mate to learn more.

But your team mate didn’t really implement it either. Their agent did.

It’s like that co-worker that left the company

I keep coming back to this analogy.

With AI agents it’s the same, just faster. It used to happen when someone quit. Now it happens at the end of every session. Every time an agent finishes a task, it’s like a coworker with full context just left the building.

Agents already encode their reasoning

It’s all in the session, which includes the entire transcript from the prompts, dead ends and corrections that were necessary. All these are persisted on your hard drive.

I’m not the only one landing here. Thomas Dohmke, ex-GitHub CEO and now building Entire, made this a big part of his WeAreDevelopers keynote “The Agentic Assembly Line”. His framing:

these session logs are now the second most [important] artifact in software development. Second most because code remains the primary artifact … But we need both of these things together because the session logs together with the code, they reflect the institutional knowledge of our project.

As long as these sessions are only on your local hard disk, it might help you, but not really your team to be more productive. A common approach is creating ADRs or other forms of docs/summaries of agent sessions and store them alongside your source code in your repo in a docs folder or sidecar files. Jamon Holmgren, for example, describes such approach, committing the agent’s worksheet alongside the work so you can reference it later.

This can work, but it is prone to being out of date if agent operations don’t keep sidecar files or ADRs in sync.

Our work and collaboration patterns change

Product engineers now operate a fleet of agents that implement the product strategy they defined. That changes how we work and collaborate.

The product direction gives the strategy, the codebase encodes the result and the sum of all sessions contain the reasoning and decisions that went into it. That’s why the combination of both is so important to preserve.

However, if we look closer from a collaboration point of view, then it often still looks a lot more like “old” established patterns:

This introduces friction and loses information: what your coworker’s agent figured out doesn’t reach yours.

What I’d rather have: my agent directly pulling a distilled view of what my coworkers’ agents already worked out, using it to sharpen its understanding of that part of the codebase.

The Meta-harness - closing the gap between agent harnesses and your day to day work

Harnesses like Claude Code, Codex etc. add the agentic layer to LLMs, but there’s a gap between those primitives and your day to day work, which you close in two layers:

via harness engineering: tuning your specific harness (e.g. Claude Code or Codex) to your workflows via skills, custom MCPs etc
a meta-harness: optimizing all your harnesses, allowing for easy harness swapping and operating at a broader scope, like cross repository work, session management, improving collaboration patterns within teams.

They build on top of each other. You optimize your harness so it works best for you, and then you leverage a meta-harness on top to optimize the work across your team and organization.

Right now, I’m working (with the team at Nx) on such a new meta-harness, called Polygraph.

Here’s what’s already possible today:

Work across repositories - Polygraph indexes repositories and creates a repository graph which the agent can access and leverage both for retrieving information but also writing changes that stretch across repository boundaries (including coordinating PRs across them).

Automated workspace provisioning - Because Polygraph understands the connections among repositories, it is able to automatically provision the repositories required to satisfy a given cross-repo spanning feature work.

Session capturing and resuming - Polygraph is able to automatically capture agent sessions across harnesses. This enables interesting capabilities, like being able to resume sessions seamlessly on other machines and other harnesses, improving how we collaborate with AI agents. Things like adding something to a PR becomes as easy as resuming the connected session in your own harness and instructing it to fix the issue.

Here’s a concrete example of this workflow:

Build your work on top of other sessions - Polygraph builds a graph of connected sessions, linking them based on how similar their prompts, instructions, and code changes are. So when you’re about to extend a feature or fix a bug in it, you start from the sessions that already worked on that part of the code instead of a blank prompt. Here’s a demo by Polygraph developer Max Kless.

Code reviews - Because resuming sessions across agent harnesses is a core primitive of Polygraph, spawning adversarial code reviews becomes easy.

To recap

Git gave us a shared, durable memory for code. We never had the same thing for the reasoning behind the code. For twenty years that was fine, because the reasoning lived in people. Now it lives in agent instances that disappear at the end of every session. Keeping those sessions, and making them searchable across a team, is how the “why” survives.