The Compaction Curse: A Three-Line Prompt Problem

# "The Compaction Curse": A Three-Line Prompt Problem Blown Up Into a 45-Minute Presentation

## How It's Described

https://youtu.be/Nm3MsnngCJg?si=4QWKn2MKNIyEsEGg

"In large codebases, agents lose context. The window overflows, the agent runs a compaction, part of the information drops out, it goes to recover the context, overflows again, compacts again. It loops around, hallucinates, and breaks the architecture. The solution is — follow best practices, code locality, clear interfaces. Otherwise the agent won't be able to work."

This is a quote from Sheiko's lecture. It sounds scary. It sounds like a fundamental problem that requires rebuilding the entire codebase. It sounds like a reason for a separate presentation at a meetup.

In practice, it's **a three-line prompt problem**.

---

## Why This Is Not a Problem

Compaction is not a bug. It's a **standard mechanism** for managing the context window. Every modern model and every harness (Claude Code, Codex, MiMo Code) has a built-in compaction strategy. It works. Yes, part of the context gets compressed. Yes, nuances may be lost.

But this is **not a catastrophe**. It's a manageable process. And it's managed not by rebuilding the codebase for "locality and interfaces," but by **three lines of instruction** that you give to the agent.

Sheiko says in his lecture: "The company decided that since we have agents, there's no need to worry about best practices. And locality was lost. And the agent started gathering context from the entire project."

This is a substitution. The problem isn't that "there are no best practices." The problem is that **nobody told the agent where to save important information before compaction**. Best practices are for people who read code. An agent doesn't read code like a human. An agent works with a context window. And the context window is managed by an instruction, not by refactoring.

---

## Solution 1: An Instruction for memory.md (Three Lines)

Here is literally the entire "compaction curse fix":

```

Before the context window reaches its limit or a forced compaction occurs,

you must write to memory.md: the current task, progress, key decisions,

constraints, and next steps. After compaction, you read memory.md and

continue working without losing context.

```

Three sentences. You add it to the system prompt or to the project's `agents.md`. The agent periodically dumps critical context to a file. After compaction, it loads it back. Nothing is lost.

This is not theory. This works. This is exactly how memory works in MiMo Code from Xiaomi (which Sheiko himself mentions in the lecture). This is exactly how custom harnesses work — the ones built by people who know how to configure agents.

**The entire "fix" is:**

1. A `memory.md` file in the project root (or in the `.agent/` directory)

2. Three lines in the system prompt

3. The agent writes and reads it on its own

No refactoring. No "best practices for agents." No 45-minute presentation.

---

## Solution 2: Custom Compaction (For Long Tasks)

If the task is truly long (hours of agent work, hundreds of iterations), three lines might not be enough. Then you set up **custom compaction**:

**What it is:**

Instead of the standard compaction that compresses everything indiscriminately, you configure **priority compaction**:

1. **Critical context** (current task, goal, constraints) → saved to `memory.md` without compression

2. **Decisions and architectural choices** → saved to `decisions.md`

3. **Iteration history** → compressed normally

4. **Tools and rules** → not compressed (they're in the system prompt)

The agent calls a skill before each compaction:

```

Before compaction:

1. Write to memory.md: task, goal, progress, next_steps, constraints

2. Write to decisions.md: all architectural decisions with rationale

3. Run compaction

4. After compaction: read memory.md and decisions.md, restore context

```

This is **not "rebuilding the codebase."** This is a 10-line skill that the agent executes automatically.

---

## Why Best Practices Are Not a Panacea

Sheiko says: "Use best practices, code locality, clear interfaces. Otherwise the agent won't be able to work."

This is **partially true**, but it's presented as the only solution. The reality:

**Best practices help, but they don't solve compaction.**

Yes, if the code is modular and the interfaces are clear, the agent needs less context to understand the task. It doesn't drag the entire project into the window. That's good. But this is **not a compaction fix**. This is context consumption optimization. Even in perfectly modular code, a long task will overflow the window. And then you need memory.md.

**Best practices are months of work. memory.md is three lines.**

If you have a large codebase without modularity, refactoring for "locality and interfaces" will take months. Adding three lines to a prompt will take three minutes. What would you choose?

**Best practices are for people. memory.md is for the agent.**

Code locality and clear interfaces exist so that a **human** can quickly get up to speed on a task. An agent doesn't get up to speed like a human. An agent reads the context window. And if the needed information isn't in the window, it won't find it — even if the code is perfectly modular. memory.md guarantees that the needed information is **always in the window**.

---

## Why Sheiko Inflates This Problem

Because he needs content for a presentation. "Add three lines to your prompt" is not 45 minutes at a meetup. It's 30 seconds.

So he:

- Calls it a "curse" (sounds epic)

- Talks about "hallucinations and looping" (sounds scary)

- Proposes "best practices and locality" (sounds like big work)

- Doesn't mention memory.md (because it's too simple and doesn't qualify as a presentation)

In the lecture, he briefly mentions: "You can also help a bit through proper indexing of some memory bank that stores context." But he doesn't elaborate. He doesn't give an instruction. He doesn't show that it's three lines. Because then the presentation would end in 5 minutes.

---

## What to Do Right Now

If your agent "loops" or "hallucinates" on long tasks:

**Step 1:** Create a `memory.md` file in the project root.

**Step 2:** Add to the system prompt or `agents.md`:

```

Before compaction: write to memory.md the current task, progress,

key decisions, constraints, and next steps.

After compaction: read memory.md and continue working.

```

**Step 3:** For very long tasks, add `decisions.md`:

```

Before compaction: write to decisions.md all architectural

decisions with rationale. After compaction: read decisions.md.

```

**Step 4:** Test it. Run the agent on a long task. Make sure that after compaction it continues without losing context.

That's it. No refactoring. No best practices. No 45-minute presentation. Three lines of prompt.

---

## Conclusion

"The Compaction Curse" is not a curse. It's a **standard mechanism** managed by three lines of instruction. The agent dumps important information to `memory.md` before compaction and loads it back after. Nothing is lost.

Best practices help, but they are neither necessary nor sufficient. They're for people. The agent needs `memory.md`.

Those who spend 45 minutes talking about the "compaction curse" and proposing to refactor the codebase simply haven't written three lines of prompt. And that's their choice. But this is not an AI problem. This is a laziness problem.