Four Sentences Beat a 100KB Transcript. Here’s Why

Most people trying to give an AI “memory” do the exact same thing: they paste the whole history back in. Every session, every decision, every dead end, appended into one growing file and fed to the model hoping continuity shows up on its own. u/__hymn ran the opposite experiment for eight months, on a single long-running project, and the tiny file won every single time.

Here’s the pattern break worth stealing: more context is not the same as more continuity. The original poster started where most of us start, full transcripts of every prior session, stacked on top of each other. The model could quote the project history word for word. It still acted like it had never met the user. It hedged. It re-argued decisions that were already settled two weeks ago. It spent its effort summarizing what it had just read instead of doing the actual work.

Old way vs. new way

The old way: dump everything, let the model figure out the rules from a hundred kilobytes of raw evidence. The problem, according to the author, is that this forces the model to infer behavior from a pile of examples, and inference from a messy pile is lossy and expensive. Worse, a long transcript is full of superseded decisions sitting at the same weight as the current ones. It’s not memory, it’s a room full of people arguing where most of them already lost the argument.

The new way: cut the transcript, replace it with four sentences of identity, a dated ledger of recent changes, and the current working state. Same model, same task, and the difference in behavior was not subtle. The theory holds up: an identity file isn’t evidence the model has to interpret, it’s instruction the model just follows. That frees up the context budget for the work itself instead of history-parsing.

What actually goes in the four sentences

Skip facts and events entirely. The post’s author narrows it down to four things:

  • 📌 What this is
  • 📌 What it’s for
  • 📌 What it must never do
  • 📌 How it should behave when it’s uncertain

That last one carries more weight than the other three combined, per the original poster’s eight months of testing. Most bad outputs come from a model improvising under uncertainty, not from missing facts.

How to build it yourself

  1. Write four sentences, no more: identity, purpose, hard limits, and the uncertainty rule.
  2. Keep a separate dated ledger for what changed recently. That’s where events live, not the identity file.
  3. Add current working state as its own short section so the model knows where things stand today.
  4. Feed the model the identity file plus the ledger at the start of every session, skip the old transcripts entirely.
  5. Enforce one rule going forward: if a line has a date in it, it does not belong in the identity file. Move it to the ledger.

That last rule matters because the failure mode is sneaky. The identity file drifts into logging recent events, grows for a few weeks, and quietly turns back into a transcript wearing a different hat.

One caveat worth keeping: this is for behavior in a long-running relationship with one project, not for recalling specific facts on demand. If the model needs to pull up an exact past detail, that’s a job for retrieval, not for an identity file. Instruction beats evidence for behavior. Facts still need to be, well, facts you can look up.

The comment section adds two useful angles to this. One reader ties it straight to cognitive load theory: too much noise and the model burns cycles sorting what matters instead of working. Another pushes back a little, arguing that for very long transcripts, a model that stays accurate across the whole history might beat one that just writes a nicer-sounding summary, since consistency can matter more than polish. A third suggests going further for genuinely huge backgrounds, fragmenting them behind a router document so the model finds the right subtopic instead of scanning everything.

Whichever side of that you land on, the core test is simple and worth running on your own setup: most people are handing their AI evidence when what it actually needs is instruction. Try trimming your own context file down to four sentences and a ledger, and see if the same jump in usefulness shows up for you.

The original poster is still looking for someone to test this properly with a fixed task and a real eval instead of vibes. Worth reading the full discussion and chiming in if you’ve got the setup to run that test.

Frequently Asked Questions

Q: Won’t I lose important details by cutting the full transcript?

No , the identity file plus dated ledger captures what actually matters: intent, recent changes, and current state. You’re trading volume for clarity. The model stays consistent because it has instructions to follow, not because it’s drowning in examples.

Q: What’s the difference between an ‘identity file’ and a static system prompt?

They’re similar, but identity files evolve. A system prompt is set once and forgotten; an identity file includes a dated ledger of recent changes and current working state, so the model stays in sync with reality. It’s a living instruction manual instead of a static one.

Q: I have way too much context to fit in one identity file. How do I organize it?

Use a router or index document that outlines topics hierarchically (e.g., topic1 → subtopic1a, subtopic1b; topic2 → subtopic2a). Keep it brief and reference-friendly, then link to specific sections when needed. This keeps your context window free for actual work instead of archaeology.

Q: Why does the model get worse with more context, not better?

It’s cognitive load. Dumping raw transcripts forces the model to waste inference tokens sorting signal from noise, hedging, and re-litigating old decisions. A clean, concise instruction is cheaper than a pile of evidence. The model focuses on your current task instead of parsing history.

Four sentences of identity outperformed a 100KB transcript dump. Here is what I think is actually going on.
by u/__hymn in PromptEngineering

Scroll to Top