---
title: Keep the agent session next to the code
description: Agents write code faster than anyone can review it, and the reasoning behind each change dies with the chat window. Notes on Thomas Dohmke's AGNTCon + MCPCon keynote and his backstage interview, the Entire checkpoint that links a session log to its commit inside Git, and why my own sessions expire long before the pull requests they wrote.
date: 2026-10-27
tags: AI coding agents, code review, Git, Claude Code, Entire
---

The agent session is worth as much as the diff it produced, so it should live in Git next to the code. That's Thomas Dohmke's case, and his company Entire builds it: a checkpoint that links the prompts, tool calls and rejected approaches of a session to the commit they ended in. The transcript doesn't prove the code is right. It's evidence that the diff matches what you meant.

Thomas ran GitHub as its CEO and now runs [Entire](https://github.com/entireio/cli). He gave the talk on day two of AGNTCon + MCPCon North America, October 23, then kept going backstage. I've merged 830 pull requests across my repos since October 1. Most of the sessions that wrote them are already on their way out of my disk, so this one hit close.

## The review queue grows two ways

He opened with a confession I recognise. He takes an idea in the morning, prompts an agent to plan it and build it, comes back to working code, opens a pull request like a good teammate, and realises he has no idea what all that code does.

The slides put numbers on it. A chart from The Pragmatic Engineer: teams using coding agents reach 57 pull requests a week, against roughly 10 for traditional teams. A chart from Cursor: those pull requests are getting much bigger too. So the queue grows in two directions at once, more changes and more code in each change.

A pull request still arrives with the old expectation: somebody will read it and understand it. Something has to give, and his next slide showed what does: more AI changes accepted without human review.

He's been guilty of it himself. It's Friday, 4 or 5 pm, the agent says it all works, CI is green and the diff doesn't tell you what could have gone wrong. You have three more pull requests. Approve them, let them wait until Monday, or YOLO merge.

<figure class="fd-fig es es-f1" aria-labelledby="es1-cap" data-desc="The review queue, from Thomas Dohmke's slides. Bars to scale: teams using coding agents open 57 pull requests a week, traditional teams about 10, from a Pragmatic Engineer chart. A second slide, from Cursor, showed the pull requests getting bigger too, so the queue grows in count and in size. Then the Friday afternoon at 4 or 5 pm with three pull requests left, the agent saying it all works and CI green: approve them, let them wait until Monday, or YOLO merge. His point: we need a better way to earn the confidence that what we merge is what we wanted.">
<div class="rp-bars">
<p class="rp-bars-h">Pull requests a week</p>
<p class="rp-bar rp-bar-win"><span>Teams with coding agents</span><i class="es-w" style="--w:57"></i><b>57</b></p>
<p class="rp-bar"><span>Traditional teams</span><i class="es-w" style="--w:10"></i><b>~10</b></p>
<p class="es-plus"><span class="rp-k">And each one</span>bigger than before, on Cursor's data</p>
</div>
<ol class="ea-rows es-fri" aria-label="Friday, 4 pm, three pull requests left">
<li><b>1</b><span class="ea-who">Approve</span><span>The agent says it all works, and CI is green.</span></li>
<li><b>2</b><span class="ea-who">Wait</span><span>Let them sit until Monday.</span></li>
<li class="ea-row-no"><b>3</b><span class="ea-who">YOLO</span><span>Merge, and hope the diff wasn't hiding anything.</span></li>
</ol>
<p class="mp-strip"><b>What gives</b><span>More AI changes accepted without human review.</span></p>
<figcaption id="es1-cap">The bars are to scale, from his Pragmatic Engineer slide. The Cursor slide showed a trend, not a figure, so there's no bar for it.</figcaption>
</figure>

## The loop was built around a person

His spiciest line: the software development life cycle, as we know it, is dead.

You've seen the infinity symbol. Write, build and test is the inner loop. Integrate, release, deploy and observe is the outer one. For twenty years DevOps and agile made those loops faster and the batches smaller, and it worked because one developer carried the context, the intent and the idea all the way around the circle.

Now an agent drives on those tracks, and we stand at each station handing it a new direction. The work keeps moving. The question is whether the intent you had at the start travels with it.

Backstage he flipped the old goal. We used to make loops smaller so a person could keep up. Now we need them bigger, so agents keep working while he's on a keynote stage, in a customer call, or asleep, and still build what we wanted without wasting tokens. His most frustrating moment: opening the Codex app on his phone in the morning and finding that a run stopped five minutes after he went to bed.

The cost cuts the other way too. He told students at a hackathon it's no achievement to win a $10,000 prize if you spent $50,000 in tokens on it.

<figure class="fd-fig es es-f2" aria-labelledby="es2-cap" data-desc="The software development life cycle as an infinity loop. The inner loop on the left is write, build and test. The outer loop on the right is integrate, release, deploy and observe. A token runs around both loops. The label cycles through three states. Before: one person carries the intent around the whole loop, so DevOps and agile made loops faster and batches smaller. Now: an agent drives the loop and we give it a new direction at each station, and the intent may not travel with the work. Next: bigger loops that run while you are on stage, in a meeting or asleep, with the intent on board. Thomas Dohmke's line: the software development life cycle, as we know it, is dead.">
<p class="ea-now ea-say3" aria-hidden="true"><span>Before: a person carries the intent</span><span>Now: an agent drives the loop</span><span>Next: bigger loops, intent on board</span></p>
<svg class="es-loop" viewBox="0 0 440 180" aria-hidden="true">
<path class="es-track" d="M220,90 C260,30 390,30 390,90 C390,150 260,150 220,90 C180,30 50,30 50,90 C50,150 180,150 220,90 Z"/>
<g class="fd-token"><rect x="-6" y="-6" width="12" height="12"><animateMotion dur="9s" repeatCount="indefinite" path="M220,90 C260,30 390,30 390,90 C390,150 260,150 220,90 C180,30 50,30 50,90 C50,150 180,150 220,90 Z"/></rect></g>
<text class="fd-t" x="135" y="96" text-anchor="middle">Inner</text>
<text class="fd-t" x="305" y="96" text-anchor="middle">Outer</text>
</svg>
<div class="es-key">
<p><span class="rp-k">Inner loop</span>Write, build, test</p>
<p><span class="rp-k">Outer loop</span>Integrate, release, deploy, observe</p>
</div>
<p class="mp-strip"><b>His line</b><span>The software development life cycle, as we know it, is dead.</span></p>
<figcaption id="es2-cap">The infinity loop from his slide, redrawn. The yellow square is whoever is driving: it used to be you.</figcaption>
</figure>

## The repo shows what changed, never why

Next slide: the landing page every GitHub repository has. Folders and files, a README somewhere at the bottom, some metadata on the side. You could read the code and piece the reasoning together from issues, pull requests and commit messages.

More often than we'd like to admit, he said, we went to Slack, Discord or an IRC channel to ask the person who wrote that line what they meant. The repository showed what changed. The why never came with it.

Then the last interface we all shared went quiet. He showed a Cursor headline from April 5, 2026: the editor has become the fallback. He still opens it to check a file an agent wrote. His standard interfaces now are Claude Code in a terminal, Codex in a Mac app, or a tmux setup a developer made their own.

That's where the thinking happens now. The session holds the approach you rejected, and the moment you told the agent "this is correct, but not what I wanted". When the session ends, that learning still matters. In three years it's the only way to time travel back and see what you actually wanted.

<figure class="fd-fig es es-f3" aria-labelledby="es3-cap" data-desc="Two places where a change leaves a trace. The repository page: folders and files, a README at the bottom, commit messages, issues and pull requests. It shows what changed. The why lived somewhere else, in Slack, Discord or IRC, in a message to whoever wrote the line. The agent session: the prompts, the plan, the tool calls, the approach you rejected, and the moment you told the agent this is correct but not what I wanted. It holds the why. Since a Cursor headline of April 5, 2026, the editor has become the fallback: the session in the terminal or the app is where the thinking happens.">
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">The repo page</p>
<p class="mp-two-name">What changed</p>
<p class="mp-two-line">Folders and files</p>
<p class="mp-two-line">A README at the bottom</p>
<p class="mp-two-line">Commits, issues, pull requests</p>
<p class="mp-two-line es-gone">The why: in Slack, Discord or IRC</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">The agent session</p>
<p class="mp-two-name">Why it changed</p>
<p class="mp-two-line">The prompts and the plan</p>
<p class="mp-two-line">Every tool call</p>
<p class="mp-two-line">The approach you rejected</p>
<p class="mp-two-line">"Correct, but not what I wanted"</p>
</div>
</div>
<p class="mp-strip"><b>April 5, 2026</b><span>Cursor: the editor has become the fallback.</span></p>
<figcaption id="es3-cap">The struck line is the part that never made it into the repository.</figcaption>
</figure>

## A checkpoint ties the session to the commit

Here's the mechanism. On his slide, the session log sits on the left: tool calls, model responses, what he wanted. The Git commit sits on the right, with its diff and its SHA. In the middle is what Entire calls a checkpoint, linking the two inside Git.

Git, because it's the open-source system we've used for more than two decades, so session logs belong there as Git objects. That also means his teammates can read his sessions, and so can whoever joins the team three years from now.

The open-source [Entire CLI](https://github.com/entireio/cli) is MIT licensed and written in Go. Per its README and docs, it works like this:

```bash
entire enable --agent claude-code   # installs agent hooks and Git hooks in the repo
git commit -m "..."                 # the hook asks: link this commit to session context?
entire checkpoint explain <id>      # the prompt, transcript and files behind a commit
entire session resume <branch>      # pick the sessions back up in your agent
```

- The agent hooks capture the session as you work: prompts, transcript, tool activity, changed files and token usage when available.
- A checkpoint needs both captured context and a commit. Git hooks add an `Entire-Checkpoint` trailer to the commit message, and that's the link.
- The checkpoint is stored in its own ref under `refs/entire/checkpoints/`, not as a commit on your branch. Your branch stays clean.
- One session can produce several checkpoints, and one checkpoint can combine several sessions.

It supports Claude Code, Codex, Cursor, Copilot CLI, OpenCode and a few more. On top sits Entire's hosted platform, where a Trail groups the intended outcome, the changes across repos, the sessions, review findings, CI results and human approvals, with gates for when a change is ready to merge.

The catch is in the same README. Checkpoints are pushed with your code by default, so a public repository exposes its transcripts. Secret redaction runs before a checkpoint is written, and they call it best effort. They suggest previewing with `entire checkpoint list --outgoing`, a separate private checkpoint repository, or `--skip-push-sessions`.

<figure class="fd-fig es es-f4" aria-labelledby="es4-cap" data-desc="How an Entire checkpoint links a session to a commit, in three boxes. On the left, the session log: prompts, transcript, tool calls, files touched and token usage, captured by agent hooks as you work. On the right, the Git commit: the diff, the SHA, and a trailer in its message, Entire-Checkpoint followed by an id. In the middle, the checkpoint, stored in its own Git ref under refs/entire/checkpoints, not on your branch. The label cycles: the agent works and the hooks capture; you commit and a checkpoint is written; the trailer links them. Underneath, his point: the transcript is not proof that the code is correct, it is evidence that the diff matches the intent. And the README's warning: checkpoints are pushed with the code by default, so a public repository exposes its transcripts.">
<p class="ea-now ea-say3" aria-hidden="true"><span>The agent works, hooks capture</span><span>You commit, a checkpoint is written</span><span>The trailer links them</span></p>
<div class="es-link" aria-hidden="true">
<div class="ea-box ea-box-sv es-b1"><p class="ea-box-k">Session log</p><p class="ea-box-n">Why</p></div>
<span class="es-arr">→</span>
<div class="ea-box ea-box-sb es-b2"><p class="ea-box-k">Checkpoint</p><p class="ea-box-n">The link</p></div>
<span class="es-arr">←</span>
<div class="ea-box es-b3"><p class="ea-box-k">Git commit</p><p class="ea-box-n">What</p></div>
</div>
<ol class="ea-rows es-parts" aria-label="What each part holds">
<li><b>1</b><span class="ea-who">Session</span><span>Prompts, transcript, tool calls, files touched, token usage.</span></li>
<li><b>2</b><span class="ea-who">Checkpoint</span><span>Its own ref under <code>refs/entire/checkpoints/</code>, not a commit on your branch.</span></li>
<li><b>3</b><span class="ea-who">Commit</span><span>The diff, the SHA, and a trailer: <code>Entire-Checkpoint: &lt;id&gt;</code>.</span></li>
</ol>
<p class="mp-strip"><b>His point</b><span>Not proof the code is correct. Evidence the diff matches the intent.</span></p>
<p class="mp-strip es-warn"><b>The catch</b><span>Pushed with the code by default. A public repo exposes its transcripts.</span></p>
<figcaption id="es4-cap">His slide, redrawn, with the storage details from the CLI's README and docs. The id is schematic.</figcaption>
</figure>

## Git's own idea, applied to the server

The other pressure is load. He showed a chart of commits from Claude Code alone climbing fast, then a GitHub chart from August 2026 with pull requests, commits and repositories up by an order of magnitude or more.

If every agent output waits for a human to review it, we're the bottleneck. And if the infrastructure can't scale as fast as the agents, it's the next one.

His answer is the idea Linus had when he built Git, taken one step further. Git is distributed on our laptops: everybody has their own copy of the repo. Then we all send it back to one central hub. He says that doesn't scale, isn't resilient, and doesn't let you decide which country or region hosts your code.

He calls software the largest team sport on earth. Millions of people in companies, open source, research, schools and hackathons, who don't care which country the others are in and often don't even use their real names. That community deserves infrastructure that's decentralised, open source and independent, like Git and Linux themselves.

<figure class="fd-fig es es-f5" aria-labelledby="es5-cap" data-desc="Two shapes of Git hosting. Today: every developer has a full copy of the repository on their own machine, but all of them push back to one central hub; Thomas Dohmke says that doesn't scale, isn't resilient and doesn't let you choose the country or region that hosts your code. His ask: make the servers distributed too, the way Git made the clients distributed, so the infrastructure scales as fast as agents produce code. Above both, the load from his slides: a GitHub chart from August 2026 with pull requests, commits and repositories up by an order of magnitude or more.">
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">Git today</p>
<p class="mp-two-name">One hub</p>
<svg class="es-net" viewBox="0 0 160 110" aria-hidden="true"><g class="es-edge"><line x1="80" y1="55" x2="22" y2="18"/><line x1="80" y1="55" x2="138" y2="18"/><line x1="80" y1="55" x2="14" y2="68"/><line x1="80" y1="55" x2="146" y2="68"/><line x1="80" y1="55" x2="48" y2="100"/><line x1="80" y1="55" x2="112" y2="100"/></g><rect class="es-hub" x="66" y="41" width="28" height="28"/><g class="es-node"><circle cx="22" cy="18" r="8"/><circle cx="138" cy="18" r="8"/><circle cx="14" cy="68" r="8"/><circle cx="146" cy="68" r="8"/><circle cx="48" cy="100" r="8"/><circle cx="112" cy="100" r="8"/></g></svg>
<p class="mp-two-line">Every laptop has a full copy</p>
<p class="mp-two-line">Every push goes to one place</p>
<p class="mp-two-line">You don't pick the region</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">His ask</p>
<p class="mp-two-name">Servers distributed too</p>
<svg class="es-net" viewBox="0 0 160 110" aria-hidden="true"><g class="es-edge es-edge-ag"><line x1="22" y1="18" x2="80" y2="10"/><line x1="80" y1="10" x2="138" y2="18"/><line x1="22" y1="18" x2="14" y2="68"/><line x1="138" y1="18" x2="146" y2="68"/><line x1="14" y1="68" x2="48" y2="100"/><line x1="146" y1="68" x2="112" y2="100"/><line x1="48" y1="100" x2="112" y2="100"/><line x1="80" y1="10" x2="80" y2="58"/><line x1="80" y1="58" x2="14" y2="68"/><line x1="80" y1="58" x2="112" y2="100"/></g><g class="es-node es-node-ag"><circle cx="22" cy="18" r="8"/><circle cx="80" cy="10" r="8"/><circle cx="138" cy="18" r="8"/><circle cx="14" cy="68" r="8"/><circle cx="80" cy="58" r="8"/><circle cx="146" cy="68" r="8"/><circle cx="48" cy="100" r="8"/><circle cx="112" cy="100" r="8"/></g></svg>
<p class="mp-two-line">Hosting as distributed as the clients</p>
<p class="mp-two-line">Scales with the agents' output</p>
<p class="mp-two-line">You choose country and region</p>
</div>
</div>
<p class="mp-strip"><b>August 2026</b><span>GitHub: pull requests, commits and repos up an order of magnitude or more.</span></p>
<figcaption id="es5-cap">Schematic: the number of machines and links is made up. The square is the central hub.</figcaption>
</figure>

## A merge conflict is a question about intent

Backstage, the host brought up a hot take Thomas had given him earlier: merge conflicts are a skills issue. Thomas explained it.

Merge conflicts got easy. You ping your agent, or have CI do it: the PR has a conflict, fix it. Agents are really good at the common kind, where somebody updated main while your pull request was open and you need to rebase.

The other kind is when two people changed the same thing. Then the question isn't textual any more. Is it my intent or Stefan's that's the right call? That still needs a person.

He sees the same pattern in CI. Nobody writes GitHub Actions workflows in YAML by hand now, the agent does. Then a run takes half an hour, then an hour, and you still need to know what normal looks like before you tell it to optimise.

<figure class="fd-fig es es-f6" aria-labelledby="es6-cap" data-desc="Two kinds of merge conflict, from Thomas Dohmke's backstage interview. Kind one: someone updated main while my pull request was open, so I need to rebase. An agent resolves it, by hand or automatically in CI. Kind two: two people changed the same thing. Now the question is whose intent is right, mine or Stefan's, and a person still has to decide. The same goes for CI: agents write the GitHub Actions YAML now, but you still need to know what a normal run time is.">
<div class="mp-two-row">
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Main moved under my PR</p>
<p class="mp-two-name">Agent rebases</p>
<p class="mp-two-line">Ping it, or let CI do it</p>
<p class="mp-two-line">Textual, not a decision</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card">
<p class="mp-two-who">Both of us changed the same thing</p>
<p class="mp-two-name">A person decides</p>
<p class="mp-two-line">My intent or Stefan's?</p>
<p class="mp-two-line">The agent has the context, not the call</p>
</div>
</div>
<p class="mp-strip"><b>Same in CI</b><span>The agent writes the YAML. You still need to know what a normal run time is.</span></p>
<figcaption id="es6-cap">His two cases, as he told them. Stefan is his example, not a real conflict.</figcaption>
</figure>

## Code and prose go opposite ways

The best five minutes backstage weren't about code. He said that when you let AI write a blog post, it looks amazing on first read. On second look, it sounds like a research paper for an audience that isn't the blog's.

And you can't edit your way out of it. What you read from the AI already mixes into your head so much that fixing sentences doesn't make it human written. For text, you have to work the other way round: draft first, then use the agent as a peer reviewer that gives feedback but never writes the text.

Code went the opposite direction. The AI writes all of it and we verify. At Entire, one of their engineers built an agent called slop cop that checks your code for slop. It's an eval on their platform: orange or red, and you're not allowed to merge. Then you tell your agent to address the slop cop's feedback and it rebuilds, tested against the same unit and integration tests. Rewriting code is easy that way. Rewriting prose isn't.

The host added his favourite: run any review skill in a sub-agent, because a context polluted by the agent that wrote the code can't judge it. Thomas warned about the other extreme, review skills that write thousands of lines of tests for a five-line change on CI minutes you pay for.

<figure class="fd-fig es es-f7" aria-labelledby="es7-cap" data-desc="Code and prose go in opposite directions. For code, the agent writes the first draft; slop cop, an eval on Entire's platform built by one of their engineers, checks it for slop, and orange or red blocks the merge; then the agent rewrites against the same unit and integration tests. For prose, you write the first draft yourself; the agent reviews it like a peer and gives feedback but never writes the text; then you rewrite. His reason: you can't edit your way out of AI text, because once you've read it, it steers your own wording.">
<div class="mp-two-row">
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Code</p>
<p class="mp-two-name">Agent drafts</p>
<p class="mp-two-line"><span class="rp-k">1</span>The agent writes it</p>
<p class="mp-two-line"><span class="rp-k">2</span>Slop cop: orange or red, no merge</p>
<p class="mp-two-line"><span class="rp-k">3</span>The agent rewrites, same tests</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card">
<p class="mp-two-who">Prose</p>
<p class="mp-two-name">You draft</p>
<p class="mp-two-line"><span class="rp-k">1</span>You write it</p>
<p class="mp-two-line"><span class="rp-k">2</span>The agent reviews, like a peer</p>
<p class="mp-two-line"><span class="rp-k">3</span>You rewrite. It never writes the text</p>
</div>
</div>
<p class="mp-strip"><b>Why</b><span>You can't edit your way out of AI text.</span></p>
<figcaption id="es7-cap">The two directions, as he described them backstage.</figcaption>
</figure>

## My sessions expire before my PRs do

This is the part that hit close. My setup: work goes into a GitHub issue, an agent builds in its own worktree, a model from another vendor reviews the change, and every change ends as a pull request I merge myself. Since October 1, that's 830 merged pull requests across my repos.

The pull requests will stay forever. The sessions behind them won't. On the Mac mini right now there are 739 Claude Code session files, 4.7 GB of JSONL, and the oldest is from September 28. That's no coincidence: Claude Code deletes local transcripts after 30 days by default, through its `cleanupPeriodDays` setting. By mid-November, the reasoning behind every early-October PR is gone.

What survives is what I made agents write down. The issue says what was needed, the PR body says what changed and `Closes #N` links the two, and a changelog fragment rides in the same PR. That's the why in a few lines. The rejected approach and the "correct, but not what I wanted" moments don't make it.

I haven't run Entire yet, and one thing would stop me on some repos: this site is public, and checkpoints push with the code by default. For a public repo I'd want them in a private checkpoint repository, which the README already suggests.

<figure class="fd-fig es es-f8" aria-labelledby="es8-cap" data-desc="My own numbers on October 27, 2026. Since October 1, 830 pull requests merged across my repos. On the Mac mini, 739 Claude Code session files, 4.7 GB of JSONL, the oldest from September 28. A timeline from September 28 to October 27 shows the 30-day window: Claude Code deletes local transcripts after 30 days by default, through its cleanupPeriodDays setting, so sessions roll off the left edge while the pull requests they produced stay in Git. What survives of the why: the GitHub issue, the pull request body with Closes N, and a changelog fragment. What doesn't: the approach that was rejected, and the moments of correct but not what I wanted.">
<div class="mp-stats">
<p><b>830</b><span>pull requests merged since October 1</span></p>
<p><b>739</b><span>Claude Code session files on the mini, 4.7 GB</span></p>
<p><b>30 days</b><span>before Claude Code deletes a transcript, by default</span></p>
</div>
<div class="es-win">
<p class="rp-bars-h">What's still on disk</p>
<p class="es-span"><i class="es-gone-w"></i><i class="es-kept-w"></i></p>
<p class="es-ends"><span>Before Sep 28: gone</span><span>Sep 28 to Oct 27: kept</span></p>
</div>
<div class="mp-two-row">
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Survives in Git</p>
<p class="mp-two-line">The issue: what was needed</p>
<p class="mp-two-line">The PR body and <code>Closes #N</code></p>
<p class="mp-two-line">A changelog fragment</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card">
<p class="mp-two-who">Rolls off after 30 days</p>
<p class="mp-two-line">The approach I rejected</p>
<p class="mp-two-line">"Correct, but not what I wanted"</p>
<p class="mp-two-line">Every tool call in between</p>
</div>
</div>
<figcaption id="es8-cap">My setup on the day I wrote this. The timeline shows the retention window, not my session history to scale.</figcaption>
</figure>

## Try it

The keynote is about eleven minutes and the backstage part about another eleven. Watch the "SDLC is dead" stretch, then read the Entire README's section on where checkpoints are stored before you enable it on anything public.

If you want more:

- [Thomas Dohmke's keynote](https://youtu.be/eB9I4Ixx2wc?t=3391) at AGNTCon + MCPCon North America, October 23, 2026 ([the session-log part starts here](https://youtu.be/eB9I4Ixx2wc?t=3630), [backstage here](https://youtu.be/eB9I4Ixx2wc?t=6523))
- [entireio/cli](https://github.com/entireio/cli), the open-source CLI, MIT licensed
- [Capture checkpoints](https://docs.entire.com/guides/checkpoints/capture-checkpoints), Entire's guide to how a commit gets its checkpoint
- [Review the plan, not the pull request](/notes/review-the-plan-not-the-pull-request.html), Dylan Ratcliffe's answer to the same review queue, from the same conference
- [How the Claude Code team reviews code that Claude writes](/notes/claude-code-team-code-review.html), six layers of checks before a person reads anything
- [The agentic software factory is the 2022 one with one box swapped](/notes/software-factory-2022-to-lights-off.html), where my own review queue shows up

If you keep your agent sessions somewhere that outlives the chat window, tell me where. I'd love to know whether anyone reads them again after the merge.