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`, my Linux live ISO build project. The Opencode agent automatically loaded my Eager files as usual —AGENT.adoc, PROMPT_REPRISE.adoc, .agents/INDEX.adoc. Everything is normal.

Except the responses are sluggish. The agent takes two seconds longer to reason. It forgets a detail it had right in front of it three messages ago. It’s not a crash, not an error — it’s a slow degradation, the kind you don’t notice immediately.

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

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

I open a terminal and type:

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

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

The irony is complete. The file designed to save context has become the primary consumer of context. It’s as if your car’s owner’s 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 unequivocal:

Out of 627 lines,382 are noise. And these 382 lines are loaded at the start of every session, consumed by the agent, diluting its attention before I even 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 — carefully written, never used. Only the green contains knowledge the agent cannot find elsewhere.

At this stage, the evidence is before my eyes: I must reduce`AGENT_MODUS_OPERANDI.adoc`. But I hesitate.

I wrote this file by hand. Each section is the result of a lesson learned in a real session. Part P3 was born from an`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 make again. This isn’t text — it’s crystallized experience.

That’s where I formulate the principle that will guide the solution:

_ Never delete. Always relocate.Knowledge does not have to disappear from the project. It just shouldn’t be loaded automatically when it is not necessary. _

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

For`AGENT_MODUS_OPERANDI.adoc`, this means:

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

That 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`LAZY_EAGER_ESSENTIALS.adoc`file looks like in practice, extracted and compacted from P1 and P2:

Fifty lines. That’s all the agent needs to understand the mechanics. Everything else — the history of lessons, detailed analogies, step-by-step procedures, appendices — lives in the encyclopedia.

And most importantly:nothing was deleted. The 627 lines of engineering are still there, in`.agents/encyclopedies/LAZY_EAGER_ENCYCLOPEDIE.adoc`. They are just stored in the library rather than on the workbench.

Before the split:

After the split:

The biggest consumer (AGENT_MODUS_OPERANDI, 627 lines) was replaced by a 50-line file. The gain is immediate: 577 lines of context freed. The agent can breathe.

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

The choice of 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 safety copy of a past state.

An encyclopedia is something else. It is a collection of thematic knowledge, structured by subject, exhaustive but non-linear. You don’t read an encyclopedia from beginning to end. You dive in to answer a specific question.

That is exactly the contract of this folder:

This distinction avoids the catch-all. Each file knows where it should live based on what it contains, not 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 the thinking. But once the thinking was formalized, the document should have been split immediately: the essential 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 session lesson. 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 should be loaded automatically. The quality of the content has nothing to do with its relevance to 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 condemnation — an audit. And the question is never "should it be deleted?" but "should it be loaded 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. Over a project of 50 sessions, it saves hundreds of tokens per future session. The ROI is immediate.

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

Session 048 revealed that archives swell. Session 051 revealed that the methodology itself swells. Session 060 will probably reveal something else. That’s normal. It’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 defense-in-depth system against context saturation. None are sufficient alone. 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 just shouldn’t be loaded when it is not necessary.