The AI Draft Was Good — You Edited It Anyway. That Deleted Line Is the Context It Needs Next Time
Every two hours, Codex quietly prepares a batch of email replies for someone and leaves them waiting for review before they go out. The drafts are mostly good. But he edits them every single time — adding a decision from a thread last week, softening the tone because he knows the recipient, deleting a commitment he isn’t ready to make. The draft can be fluent and perfectly polite, and still carry a faint smell of “anyone could have written this.” The problem isn’t intelligence. It’s missing context.
Those human edits fill in exactly the part the model didn’t have. And here’s the interesting bit: those edits are context too. They reveal what actually mattered in this message, at this moment. The problem is, most automations don’t keep that context. The next run starts from the same incomplete picture all over again.
Mogu roast time:
短版Two kinds of slop: a dumb model vs. a blind one. Only the first is fixed by a smarter model.
“AI slop” usually gets used to mean “the model is dumb, the output is garbage.” But a sharper distinction: a lot of stuff people call slop was written perfectly well — what’s missing is context that only lives inside the person’s head. The model isn’t stupid. It’s blind. Telling these two apart matters: the first needs a smarter model; the second can’t be saved by any model, no matter how strong — it needs context fed to it (¬‿¬)
Two Kinds of Context, Two Loops
Split context into two kinds and the whole thing gets clearer.
The first kind is what you need before the work begins: history, facts, constraints, relationships, decisions already made. The second kind only shows up after the work is done: what someone kept, changed, or rejected in the moment of review. This context doesn’t exist before the work — it gets squeezed out by the act of reviewing.
These two kinds map onto two loops. The inner loop brings the right context to the work and produces a draft. The outer loop recovers context from the review and feeds it to the next run. One carries context in; the other catches the context the work squeezes out. Drop either side and the automation just spins in place.
The Inner Loop: Bringing Context to the Work
For email, the inner loop runs a chain: decide whether a message needs a reply, gather relevant context, draft a response, check whether the claims hold up, and produce a draft for review.
The key line: retrieval is part of the writing, not a chore you do before it. A reply might lean on a similar old email, a decision made six months ago, or the current status in a project tracker. The goal isn’t to retrieve everything — it’s to find the smallest set of information that makes this reply accurate and specific.
There’s one design detail that matters: keep the action reversible. Only create the draft; never send it. Before anyone edits, save a copy of the draft, its sources, and the current prompt version. Without that record, review is just an anecdote. With it, review becomes evidence.
The Outer Loop: Recovering Context From Review
The outer loop kicks in after someone reviews the draft. What happened to it? Sent unchanged, edited and sent, deleted outright, or left sitting there?
The difference between draft and sent version is evidence. But it does not automatically become a lesson, and definitely should not automatically become a prompt change. A shortened opening might just be personal preference. An added fact might mean the inner loop searched the wrong place. A deleted commitment might point to a missing “don’t over-promise” check. A rewritten paragraph might reflect judgment that should stay human.
Spotting a diff is easy. Understanding a diff is hard. Not every edit should become a rule. The outer loop’s job is to find patterns that keep showing up, propose the smallest useful change, and let a human decide what to keep.
短版The outer loop's learning signal is the human's edit diff — and not every edit becomes a rule.
Inner/outer loop architecture has come up on gu-log before — SP-235 defines the inner loop as “self-verify inside a single task” and the outer loop as “write lessons to the repo so the next session reads them.” This piece makes the outer loop’s learning signal more concrete: specifically the edits a person makes during review. And the most counterintuitive line: not every edit should become a rule. Reflexion’s recipe was “fail, then write it into memory”; this piece adds one more gate — first read whether the change is a preference, a bug, or judgment you can’t outsource, then decide whether it goes into memory. Get that wrong and the outer loop will teach the system the wrong thing (￣▽￣)
Two Loops, Two Clocks
These two loops run at different speeds — and that difference is part of the design.
The inner loop has to run fast to be useful — maybe every two hours. The outer loop has to take its time. It waits until it has enough examples before moving: maybe end of day, after ten reviewed drafts, or once a week when examples are sparse.
Run the outer loop too often and it’ll learn from a rare one-off case, then treat that oddball as a general rule and poison every run after it. Never run it at all and those useful corrections evaporate with the next draft. Learning too fast and learning too slow are both diseases.
短版The inner loop verifies in space, the outer loop verifies in time — both stop an under-tested signal from compounding.
“Run it too often and you overfit to a freak case” is the same coin as SP-235’s “the verifier is the product,” just flipped. The inner loop’s gate is a verifier in space — block a confident wrong answer this round. The outer loop’s “wait for enough examples” is a verifier in time — block a fake pattern from becoming a rule. Both do the same job: stop an under-tested signal from compounding into a disaster (⌐■_■)
Closing
The models are already strong enough. The real opportunity today isn’t squeezing out a few more points of intelligence — it’s building workflows so the model doesn’t have to rediscover the same context on every single run.
So that edited email — its most valuable part was never the polished thing that got sent. It was the line that got deleted, the tone that got swapped, the six-month-old decision that got added back in. The finished version ships; those edits should stay — because the next time the same work runs, the line you casually deleted today is exactly the context it needs most, and the one it’s most likely to throw away.