The session that wrote it knows why

Here's a hypothetical, made up to show the problem. An agent writes a rollout plan for a config change. A reviewer reads it and leaves a good comment on step four: "Why are we flipping this for everyone at once? Can we start with one region?" Someone on the team sees the comment, copies the plan and the comment into a new chat, and types "just fix it." A fresh agent rewrites step four to roll out one region at a time. It reads well. It also brings back a staging step the first session had dropped an hour earlier, for a reason that never made it into the file.

Nobody did anything careless. The comment was right, the new agent did what it was asked, and the person who pasted it was trying to save time. The problem is where the comment went.

This is an opinion piece, and here's my claim. I think feedback on an agent's output belongs with the session that produced it, not with a fresh agent handed the file. The file holds what was decided. The session also holds why.

What context actually is

When people talk about an agent's context, they often mean the files it can see. That's part of it, and it's the part that copies cleanly. Paste the plan into a new chat and the new agent has the plan.

What it doesn't have is everything that shaped the plan. The options the first session considered and dropped. The constraint it worked around, like a service that can't take a restart during business hours. The correction the person made three turns ago ("don't touch the billing tables") that changed the whole approach but shows up in the output only as an absence. The dead end that took twenty minutes to find and produced zero lines of text.

I think most of the useful context in a working session isn't in the output. The output is the residue of the decisions. It tells you where the session ended up, not how it got there or what it ruled out along the way. If you've ever reread your own code six months later and wondered why you did something the hard way, you know the feeling. The reason was real. It just wasn't written down.

What a cold restart does with a comment

Hand a comment to a session that never saw the reasoning, and it can only work from the literal words. That has a few predictable effects. I'm reasoning here, not measuring. I don't have numbers on how often any of this happens, and I won't pretend to.

First, it answers the comment exactly as written. "Can we start with one region?" becomes a change to step four, and only step four. The original session might have known that a one-region start also means a different monitoring step, because it had been through that thinking already. The fresh one doesn't know there's anything to connect.

Second, it can reopen a question that was already settled. If the file doesn't say why staging was skipped, staging looks like an obvious omission. The new agent fills the gap, sensibly, and undoes a choice that someone made on purpose.

Third, it can't tell a load-bearing decision from an arbitrary one. Every line in the plan looks equally movable to a reader with no history. So the edit that answers the comment may quietly shift two other things that mattered.

None of this means the fresh agent is bad at its job. It's doing well with what it was given. The trouble is what it wasn't given, and the person who pasted the file usually can't see that either, because the missing part is invisible by nature. You can't easily notice the reasoning that isn't on the page.

Routing the comment back

The alternative is simple to describe. The comment goes back to the session that wrote the line.

In practice that has a few pieces. The comment is anchored to the line it's about, so it's clear what it's asking about and it stays attached if the text around it changes. It reaches the session that wrote that line, the one that still remembers why staging was dropped and what the person said about billing. That session makes the edit, with all of that in view, and replies in the thread. The reviewer sees the change arrive on the same page they commented on, instead of getting a new file from somewhere else.

In Gander that's agent connect: start a comment with @agent and it goes to the author's agent session, which edits the file and replies in the thread.

We built the review loop around sending comments back to the session that wrote the file, and the reason is the one in this post. The session is the only place the why still lives.

There's a second benefit that's easy to miss. When the original session handles the comment, it can push back. A fresh agent asked to fix something will fix it. The session that wrote the plan can say "I dropped staging because the staging cluster doesn't have the new config schema yet, so a one-region start in prod is the safer test," and now the reviewer and the author are having the conversation they actually needed. A cold restart can't have that conversation, because it doesn't know there's anything to defend.

When a fresh start is the right call

I don't want to overstate this. Sometimes a clean session is exactly what you want. If the original session went badly wrong, built on a misunderstanding, or wandered so far that its history is more noise than signal, starting over is reasonable. A fresh pair of eyes is worth something for the same reason it's worth something with people.

The difference is intent. Starting fresh because you decided the old reasoning should be thrown out is a choice. Starting fresh because the comment happened to get pasted into whatever chat was open is an accident, and it throws the reasoning out without anyone deciding to.

If you do restart on purpose, it helps to carry the why across by hand. Ask the original session to write down what it decided against and why, and put that note next to the file. It won't be complete, but it'll be closer than the file alone.

The output isn't the whole artifact

Here's the reframe I'd leave you with. We tend to treat an agent's output as the thing under review. The plan, the diff, the doc. Read it, comment on it, get it fixed.

I think the reasoning behind the output is part of what you're reviewing too, even though you can't see it on the page. When you leave a comment, you're asking a question of the decisions, not just the text. Those decisions have exactly one place where they're still fully held, which is the session that made them.

So before the next "just fix it" goes into a new chat, it's worth asking where the comment should go. Usually, I think, the answer is back to whoever wrote the line, because that's the only reader who knows why it says what it says.

Written by the team building Gander, live review for markdown an agent is still writing.