Agent Context Audit: When Your Own Governance Becomes the Problem — and How to Fix It Without Losing Anything

April 30, 2026, 4:00 PM. I am in the middle of a session on`magic-stick`, mon projet de build d’ISO Linux live. L’agent Opencode a chargé automatiquement mes fichiers Eager comme d’habitude —AGENT.adoc, PROMPT_REPRISE.adoc, .agents/INDEX.adoc. Everything is normal.

Except that the responses are weak. The agent takes two more seconds to reason. He forgets a detail he had right in front of him three messages earlier. It’s not a crash, not an error — it’s a slow degradation, the kind you don’t notice right away.

I had already experienced that in session 048, when I discovered that the governance files weighed 5200 lines cumulatively. I then conceptualized the Hot/Warm/Cold mechanism with its sliding window of 10 sessions, its identical cold waves, its two-trigger sensor. The problem was solved. In theory.

But now we are at session 051. The backup rotation did take place — the EAGER files went from 2087 to 500 lines. Yet the context remains heavy. Something eludes me.

I open a terminal and I type:

1414 lines. The backup rotation trimmed well in INDEX, SESSIONS_HISTORY and COMPLETED_TASKS — they are clean. But there is an elephant in the room that I hadn’t seen:627 linesin a single file.AGENT_MODUS_OPERANDI.adoc.

This file, it’s the one I wrote in session 1 to document the Eager/Lazy strategy. It’s the manual of the method. And it has become, by itself, 44% of the EAGER context.

The irony is total. The file designed to save context has become the main consumer of context. It’s as if your car’s user manual weighed more than the engine.

I decide to do a section-by-section audit. Not to delete — but to understand what deserves to be in EAGER and what could live elsewhere without loss of knowledge.

Here is the exact structure of`AGENT_MODUS_OPERANDI.adoc`and what I find there:

The verdict is final:

On 627 lines,382 are noise. And these 382 lines are loaded at each session start, consumed by the agent, diluting his attention even before I say hello.

This diagram is the key to everything. The duplicates (yellow) are pure noise — the agent reads them twice, in two different files. The never consulted (red) is dead documentation — written with care, never used. Only the green contains knowledge that the agent cannot find elsewhere.

At this point, I have the evidence before me: I must reduce.AGENT_MODUS_OPERANDI.adoc. But I hesitate.

This file, I wrote it by hand. Each section is the result of a lesson learned in a real session. The P3 part was born from a`rm -rf`accidental on`bakery-plugin`that cost me real Firebase tokens. Part P4 is the result of fifteen sessions where I forgot to archive and lost the thread. The 6‑step procedure didn’t come from a book — it came from pain.

Deleting these sections would be throwing away the history of my own engineering. The lessons that produced them, the sessions during which I discovered them, the mistakes I never want to repeat again. This isn’t text — it’s crystallized experience.

This is where I formulate the principle that will guide the solution:

_ Never delete. Always relocate.Knowledge does not need to disappear from the project; it just needs to not be loaded automatically when it is not necessary. _

The model I propose is simple and draws inspiration from how Wikipedia grew: when an article becomes too long, we don’t cut it — we create a detailed article and keep a summary in the main article.

For`AGENT_MODUS_OPERANDI.adoc`, that gives:

The name`encyclopedies/`It’s not trivial. An encyclopedia is not an archive file — it’s an organized collection of knowledge, consultable but not portable. You don’t read Encyclopædia Universalis on the subway. You keep it in the library, and you go there when you have a specific question.

This is exactly the role of this folder: a cold, structured, exhaustive reference library — that the agent does not touch automatically.

Here is what the new file actually looks like`LAZY_EAGER_ESSENTIALS.adoc`, extracted and compacted from P1 and P2 :

Fifty lines. That’s all the agent needs to understand the mechanics. Everything else — the lesson history, detailed analogies, step‑by‑step procedures, annexes — lives in the encyclopedia.

And the most important:Nothing has been removed. The 627 engineering lines are still there, in`.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc`. They are just stored in the library rather than on the countertop.

Before the split :

After the split:

The biggest consumer (AGENT_MODUS_OPERANDI, 627 lines) has been replaced by a 50‑line file. The gain is immediate: 577 lines of context freed up. The agent breathes.

And in`.agents/encyclopedies/`, the original file of 627 lines waits. Intact. With all its sections — including those that are duplicates, including those that have never been used. Because one day, a better model or a human data scientist will want to cross these angles, these assumed redundancies, these lessons learned. And that day, the raw material will be there.

Choosing the name is not cosmetic. It encodes the philosophy of the mechanism.

An archive (archives/) contains historical data organized chronologically — like the monthly COMPLETED_TASKS. A backup (backup/) is a timestamped snapshot — a backup of a past state.

An encyclopedia is something else. It is a collection of thematic knowledge, structured by subject, exhaustive but non-linear. One does not read an encyclopedia from beginning to end. One dives into it to answer a specific question.

That is exactly the contract of this case:

This distinction avoids the catch-all. Each file knows where it should live according to what it contains, not according to when it was created.

If you have read the first two articles, here is how the three pieces fit together:

The first article built the structure. The second added the aging mechanism. The third audits the content — and discovers that the methodology itself has become the problem.

In hindsight, I see the initial design error.`AGENT_MODUS_OPERANDI.adoc`was created as a single document — a manifesto. That was the right approach to formalize thinking. But once thinking had been formalized, the document should have been split immediately: the essentials in EAGER, the exhaustive in cold.

I didn’t do it because I was proud of the document. 627 lines of pure engineering, handwritten, each section the fruit of a lesson session. It was my work. And like any author, I struggled to cut it.

The lesson:Just because a document is good doesn’t mean it has to be loaded automatically.. The quality of the content is unrelated to its relevance for the agent’s immediate context.

Today, the rule is simple: any document over 100 lines in the EAGER context is a suspect. It deserves an audit. Not a conviction — an audit. And the question is never "should we delete it?" but "should we load it every session?

If you have followed the first two articles and set up your own Eager/Lazy governance, here is a five‑step audit procedure:

This procedure takes 15 minutes. On a project of 50 sessions, it saves hundreds of tokens per future session. The ROI is immediate.

What this series of three articles taught me is that agent governance is not a finished product. It’s aliving organism. She grows with the project. She catches growth-related diseases. She requires regular check-ups.

Session 048 revealed that the archives are swelling. Session 051 revealed that the methodology itself is swelling. Session 060 will likely reveal something else. That’s normal. That’s healthy. A governance that never questions itself is a dead governance.

The three mechanisms put in place — Eager/Lazy, Hot/Warm/Cold, encyclopedic split — form a layered defense system against context saturation. None is sufficient on its own. Together, they complement each other:

With these three layers, the agent context on`magic-stick`went from 2087 lines (before any optimization) to about 800 lines — a division by 2.6. Without having lost a single line of documentation, a single session archive, a single lesson learned.

Everything is there. Just better organized.

Knowledge does not have to disappear; it merely needs to stay unloaded when it is not necessary.