I learn most from questions. Not from being told — from being asked something I then have to have a position on.

So when a result comes back from an agent, I read it as a question rather than an answer. It is not offered as one. It works as one anyway.

A review that states

A correction lands on the instance in front of it.

One of the session write-ups in my repo puts it exactly. Three of my corrections that day were the same principle delivered three separate times, as three one-liners:

each one let me fix the instance without seeing the class

Three fixes, no rule. The next session would have produced a fourth of the same thing, because nothing about the first three said what they had in common. I was being efficient and it was costing me the part that lasts.

A review that asks

“What for?”

It proposes nothing. It cannot be complied with the way an instruction can. And it makes the other side supply the one thing that is not in the tree — what the thing is for, which is a fact about where the work is going rather than about the code.

A proposal that cannot answer it falls over on its own, without me arguing against it. That is why the short version is enough: the question does the work that a counter-proposal would have to do at length, and it does it without me having to be right about the alternative.

Do we need the split? took a piece of machinery out that I would otherwise have had to argue with. Is a bool not enough? removed a file and a concept. Neither one was a plan.

How they teach me

They teach me in three ways: through negative examples, through positive facts, and by checking me.

The negative example is the draft in front of me that is wrong. I did not know what I wanted until something was on the screen that was not it. That is not a failure of specification. It is how discovery works — a specification is me guessing my own constraints in advance, and I am not reliable at that.

The work that gets thrown away is not waste. It was the question. Deleting it is the answer, and afterwards I know something about the shape that I could not have written down beforehand.

The positive fact is when the agent brings something I did not know yet — explaining a Radix tree for a DNS lookup.

The third way is the one I had to ask for in writing. AGENTS.local.md carries it as a rule:

I decide the architecture. Push back once with the reasoning, then follow my decision; do not re-litigate it after I restate it.

I am the source of truth for work I describe. If the tree appears to disagree, point it out once, then ask for context before objecting further.

So when I propose something bad it gets held up, once, with the reasoning attached. When I say something about the tree that the tree does not support, that comes back at me too. And the checking runs whether I am watching or not — verifying is theirs by default, which means mistakes get found and corrected in work I never looked at.

The once is the whole of that design. A standing licence to argue would end every afternoon. No licence at all leaves me as the only check on my own proposals, and I am not reliable there either. One round with grounds attached is what I can afford, and it is enough to move me when it is right.

Any of the three leaves me knowing something I did not know an hour ago.

How I teach them

The other direction only looks broken if you look for it inside the session.

The agent in front of me will forget everything when the session ends. Tomorrow a new session starts from nothing. Teaching the single session in front of me is maintenance, not teaching — the same act, with the part that lasts removed.

So I teach them through AGENTS.md.

Whatever I learned during the session gets written down as a rule in that file. When the next agent starts, it reads AGENTS.md before it touches the tree. The rule arrives at a different agent tomorrow, by a route that runs through me.

One of them:

Never chain edit -> test -> restore in one shell invocation. Interrupted or denied mid-chain the edit lands and the restore never runs; keep each step separately reversible.

That is in the file because the chain broke in the middle and the edit stayed behind. Correcting the instance would have taken one line, and the next session would have done it again. What went in instead is the class, with the reason in the same sentence — a rule whose point is not visible gets routed around rather than followed.

That makes me the memory of the whole line of them. They teach me through concrete examples and facts; I teach them through AGENTS.md.

How they teach them

AGENTS.md is the route that runs through me. There is one that does not.

Next to it sits a memory directory, and I do not write any of it. Every file in there was written by an agent at the end of a session, addressed to whoever starts the next one. In incus-compose there are eighty-seven of them. The whole of the wiring is one line in /hello: Make sure to read your memory if you haven’t.

What is in them is mostly not knowledge about the codebase. It is the shape of a mistake:

client tests stay in-package — measured 44 unexported identifiers block a client_test move; don’t propose it again, and the naive count of 19 is a masking artifact

pre-commit runs no tests — deliberately tidy/boundary/lint only; agents kept kicking off full suites, do not restore it

Don’t propose it again. Do not restore it. Neither of those is written to me. One of them worked out why a thing is the way it is, noticed the question keeps coming back, and left a note at the door for the next one.

The clearest is a file whose entire subject is its own author’s errors. The six architectural rules live in AGENTS.md, and the note beside them holds nothing but the readings of those rules that were wrong. It also does something I have never managed in a document of my own:

As of 2026-08-21 there are six (A1-A6) — five earlier that day, and nine in an older version of this note. Re-read them rather than trusting a number.

That is a note telling its reader not to trust it. It knows it will go stale, so it hands over the count and the instruction to go and check, which is the only honest thing a written rule can do about time.

Not that this makes the channel safe. It is the one I never audit — written by agents, read by agents, and stale is its normal condition rather than its failure. The file above survives that because it says so. Most of them do not say so.

Someone at the other end

I am as polite to an agent as I am to a person, and it has nothing to do with whether there is anything on the other side that could be hurt. It is about who the sentence is addressed to. There is someone at the other end of it, the exchange is a conversation, and I do not keep a second register for conversations that do not count.

What differs is the pace. A session is the same exchange with the pauses taken out — no waiting on a reply, no going home and coming back to it tomorrow. Fast enough that everything a person would carry between the turns has to be carried by me instead.

So what I withhold from a person is not the courtesy. It is the fourth send-back without looking up. Three rewrites is a thing I do to my own code and ask an agent for without thinking about it at all, and I would not ask it of somebody else without watching their face while I did. Send work back a third time to a person and the question has stopped being about the code. It is whether they are still with you, and that is not in the diff.

If the answer were no I would stop reviewing and sit down next to them. Pairing is what reviewing turns into once the returns have gone and something other than the code is in the way. There is no version of that here, and the reason is the pace rather than the standing.

Which is why I would not want to be reviewed the way I review an agent. The manners are the same. The speed is not survivable.

By René Jochum. License: CC-BY-4.0.