Coding Agents Don't Need Longer History — They Need Intent Continuity | Towards Data Science

Masonry So the wild claim here is basically, your coding agent doesn’t need more history… it needs a memory of what you meant.

Eyre Yeah, the author’s line is that memory failure isn’t the core bug. The bug is deciding which old rules still matter for the task you just asked for.

Masonry Right. In their test, you tell the agent on day one, never leak internal database IDs. Sixty messages later you ask for an auth flow, no mention of IDs… and the agent happily ships an endpoint leaking them.

Eyre And crucially, the context window wasn’t full. The rule was in the logs. The agent just had no mechanism to say, hey, that earlier constraint applies here too.

Masonry Which is such a “we’ve been doing Exploring Next for too long” moment, because this is basically agents need receipts again, just for requirements instead of actions.

Eyre Mm‑hm.

Masonry You keep coming back to, you need boring structure around the clever model… and this is like, yep, here’s some more boring structure.

Eyre Totally. And the way they do it is aggressively boring, in a good way. Pure Python, no L L M in the pipeline, no embeddings, no vector database, just code you can run in under a second.

Masonry Walk me through the core argument the way you see it, Eyre. What’s actually new here beyond “use R A G”?

Eyre So they carve things up into three questions. Retrieval is, what historical info might be relevant. Verification is, is that info still valid. Intent continuity is, which historical intent should affect this task right now, including dropping stuff that’s been overridden.

Masonry And most teams stop at the first question, right? They just stuff more logs into context or vector search and hope the model pays attention.

Eyre Exactly. The experiment makes that concrete. They run eight coding tasks on this toy but non‑trivial project. Baseline, with no special history handling, gets zero of eight right. Basic search over past requirements recovers fifty‑seven percent of the rules and solves four tasks. The full pipeline, with verified intent continuity, recovers one hundred percent of the requirements and solves all eight.

Masonry Zero to four to eight is pretty crisp.

Eyre It is. And the nice part is they kept everything deterministic. The agent and the requirement checker are just Python, so every run is reproducible. No hidden L L M randomness.

Masonry Okay, talk about the pipeline itself. Because it’s not fancy… but it’s opinionated in ways I like.

Eyre Step one is an extractor over the chat history. It scans for trigger phrases like “must”, “never”, “required”, “for now”, and flags any sentence that looks like a requirement. On a seventy‑interaction test, it hit all twelve planted requirements — so recall was one hundred percent — with three false positives, like someone saying they must run to a dentist appointment.

Masonry So they intentionally tuned it to over‑catch and then clean up later, instead of silently dropping a rule.

Eyre Right. They even call out that a keyword filter bragging about perfect precision on a tuned test is probably hiding its weaknesses. Here, they keep the noise and let the next step sort it out via a component classifier that only keeps things mapped to real system parts.

Masonry Okay, so we’ve got structured rule candidates. Where does the “continuity” part really kick in?

Eyre Verification. For each candidate requirement, they check two things: has it been superseded, and does it apply to this task’s context. Supersession is a simple rule: if two records share component, scope, and target key, but different values, the newer one wins. Their example is two auth rules about the same auth method, where the later one replaces the earlier. But two database rules for production versus prototype don’t cancel each other, because the scope differs.

Masonry So you’re not just dredging up every time someone said “database”; you’re enforcing a little change log over specific keys.

Eyre Yeah. That’s the “intent continuity” piece: carry forward what still applies, drop what’s obsolete, without the human restating it or hand‑curating the memory every turn.

Masonry Do you buy the technical claim? Eight tasks isn’t exactly a massive benchmark.

Eyre It’s tiny, but I think they’re honest about that. This isn’t “we solved agent memory.” It’s “here’s a concrete failure mode and a working fix.” The assumptions are narrow: they rely on you having reasonably clean component tags and a domain schema that’s not wildly wrong. In a giant brownfield monolith, that mapping is messier than their example.

Masonry Yeah, nobody’s schema file says “misc legacy stuff” even though half the system is that.

Eyre Exactly. And their extractor is intentionally dumb. In a real product you’d want something more robust than trigger phrases. But directionally, the result that verification plus supersession logic beats just “more history” feels very right.

Masonry From a product angle, the “who should care” section in the piece is actually pretty sharp. They basically say: do this if you have long‑running coding agents where requirements get set once and then the humans change — multi‑week refactors, shared agents across teammates, big codebases with old design choices.

Eyre And explicitly don’t bother if your sessions are short, your project is tiny, or you’re already manually repeating every rule. If you can paste the full requirements doc into every prompt, you don’t need a whole continuity pipeline.

Masonry Which I appreciate. Not every agent paper admits “this is overkill for your weekend script.”

Eyre Yeah. The real practical shift for me is: stop thinking of “history” as this undifferentiated blob. Treat requirements as first‑class objects with scope, keys, and versions. That’s exactly the receipts move we keep coming back to.

Masonry And the fact that they got meaningful gains with zero embeddings and zero L L M calls in the memory pipeline… that’s a nice reminder that half the win is just writing down your rules and checking them.

Eyre It also dovetails with that edit‑fidelity episode we did. There it was “preserve everything you can, make changes explainable.” Here it’s “preserve the intent, make overrides explicit.” Same boring spine underneath.

Masonry Yeah. If I were shipping a serious coding agent today, I’d steal this pattern wholesale: extract rules, keep a little versioned rule store, and grade the agent against it. Bigger windows can come later.

Eyre Same. You can even bolt it onto existing systems. Just run their pure‑Python pipeline on your logs and see how many of your own “never do X” rules your agents are quietly ignoring.

Masonry Alright, now I kind of want to do that on a few of our old test runs… but that is a very nerdy way to spend a Monday. Thanks for walking through it, Eyre; this one’s going straight onto the “agents need receipts” wall for me.