Abstraction: Briefing in Apples

Two compactions of the same history

The compaction move we just built produced a record: what was done, what was decided, what remains. For many tasks that is exactly right. But watch a case where it quietly isn't. A coding agent has spent 60 iterations building a sensor-data ingestion service — designing, writing, refactoring, fixing. The wall is full. Two different summarizers compact the same history:

Both are honest. Both fit on one page. Now give each briefed agent the same next task and watch the difference:

⟨tool_use⟩
edit_file(path = "api/handlers.py", old = "…", new = "def
receive_acoustic(payload): readings = parse_binary(payload);
db.insert(readings)")

⟨tool_use⟩
create_file(path = "adapters/acoustic.py", content = "# adapter #3:
binary → readings, emits to validator …")

A RECORD is organized by the past: what happened, in order.
A MODEL is organized by the domain: how to think about what's next.

A record INFORMS the remaining work.
A model GOVERNS it.

The second framing

Name what Compaction B really did: it changed the representation. We learned earlier that the description chooses the solution — polar coordinates make the circle easy — and that the first framing is chosen before the conversation begins. Compaction is the one moment in a trajectory where you get to choose the coordinate system again, and this time with the benefit of everything the conversation has learned. Sixty iterations ago, nobody knew the architecture. Now it's known — and the compacted wall can be built out of it.

Compaction doesn't have to shrink the old representation.
It can REPLACE it — with the representation the remaining
work deserves, chosen in hindsight.

Write the briefing in apples

Now the second move, and it reaches back to the beginning of our tool-design work. Recall the word apple: one small token, and an information-dense structure unfolds — looks, weight, uses — learned long before the conversation began. We used that to price tool names. But the same economics govern every word on the wall, including every word of a briefing. Compare two ways to convey the same architecture:

The design rule for every abstraction you write:

The best compression is a pointer into what the model
already knows.

Write the briefing in apples, not in eples: name every
pattern that HAS a name, and spend description only on
what is genuinely novel.

The engineered apple

What about structures that have no standard name? Then you choose an apple to borrow: a metaphor. A good metaphor imports a whole trained bundle of entailments in a handful of words. Watch one do real reasoning work:

Apples decompress more than you asked for

And that is also the danger. The thrown apple came with affordances nobody stated — that was the magic — but wrong names ship wrong affordances with exactly the same silence. Call your buffer a "queue" and the model assumes first-in-first-out; if it isn't, you have re-created the lying name — this time in your briefing instead of your tool set. The disciplined pattern is the one experts use on each other:

The three registers

Step back, because this completes a ladder we started building back with the Tolstoy manual. There are three registers for putting knowledge into a conversation, in increasing order of density:

Choosing a register is a lookup question: is this pattern trained? Point at it. Merely demonstrable? Exhibit it. Genuinely novel? Then you must describe it — and pay full price. A well-built abstraction usually uses all three: names for the known patterns, one worked example for the house style, description only for the truly local rules. That mix — not any single register — is what makes a one-page briefing able to stand in for sixty iterations.

Compaction asks:   what can we DROP?
Abstraction asks:  what can we POINT TO instead of carry?

The lightest context is not a shorter transcript.
It is a better representation — written in words that
were paid for during training, not during the task.