How much of your prompt is re-explaining context the agent should already remember?

yeah this is the "context tax" and it compounds fast. the pattern i've seen work best is separating decision memory from state memory. decisions (why we chose this pattern, what not to touch) belong in a structured ADR-style doc that gets injected at session start. state (which file owns this, current task scope) needs to be live and queryable, not a static paste. the problem with the running doc approach is it drifts the moment something changes and nobody updates it. what actually cuts overhead is making the agent write back to the memory layer, not just read from it, so the context evolves with the work instead of lagging behind it.

I hit this constantly too. What's cut it down most for me is keeping a short "why" doc per project, not the code state, just the handful of decisions that would be expensive to re-litigate. Feeding that back in beats re-explaining from scratch, though it only works if I actually update it right after a decision instead of trying to reconstruct it later.

Hate this - as others have said the best workable solution I've found is that 'write-back' to memory loop and creating an index from there for certain projects/tasks. I feel like it'll only trip me up a couple of times per week now and that'll be on me and my laziness forgetting to prompt it to update the memory after an intense session, otherwise it'll stay relatively clean.

A bigger area of struggle for me is when it has the context available and it still just jumps to assumption, and you have to ask 'Did you actually read [x]?' and that'll put it back on track. You have to keep a close eye on it though. (Using Claude Opus 4.8 mostly at the moment).

My next launch attempts to solve this for brands at a marketing-context level but I'll be amazed if there's ever a 100% watertight solution to this that doesn't just remember, but uses the context sensibly too (like knowing exactly what to degrade over time etc.)

@Raj Nagulapalle the decision-vs-state split is a good way to name it, I've been lumping both into one messy paste. Write-back is the part I haven't tried yet though, right now the agent only reads my context doc, it never updates it on its own. Curious what that write-back actually looks like for you in practice, does the agent propose an edit to the memory doc as part of its normal output, or is it a separate step you trigger?

@Stacy Wycoff @Daniel Boardman both of your points land on the same failure mode from different angles - the doc drifting because nobody updates it, versus the agent having the context but still jumping to assumptions anyway. that second one might actually be the harder problem. even with a perfect write-back loop, you still need the agent to check its memory before acting instead of pattern-matching to the more common case. feels like that's less a memory architecture problem and more a "make it verify before it commits" problem.