Re-reading files already in context
Rule 1 detects when an agent reads file content that is already available in the current working context. ClevAgent compares new file pulls with previously observed content and only intervenes when the repeated work is clear enough to explain.
A different part of the same file is allowed. If the file changes, ClevAgent stops treating older content as reusable, so the Logic does not tell the agent to rely on stale context.
The visible warning happens after the repeated read has already appeared in the tool result. That is why Rule 1 uses a behavior-correction model instead of pretending the first duplicate was prevented.
Shell-based reads are included only when ClevAgent can map the file content safely. Ambiguous output is ignored rather than counted, because a false intervention is worse than missing a marginal optimization.
Forgetting its own writes
Rule 2 detects when the agent reads content it just wrote or edited itself. The agent already produced that content, so a readback is often a sign that it lost track of its own work.
ClevAgent uses structured write and edit evidence when available. If another process may have changed the file, the Logic backs off instead of assuming the agent still knows the current state.
This is intentionally conservative. The Logic only helps when the written content is known well enough to be reused safely.
Writing files in the wrong place
Rule 3 is a workspace-hygiene Logic, not a direct cost-savings Logic. It watches files the agent creates or modifies and asks whether the file will be easy to find in a later session.
ClevAgent infers the active project from the session cwd, repo markers, and nearby workspace folders. It also infers the active agent workspace root, such as ~/.claude, ~/.codex, ~/.gemini, or another detected agent root, then maps reusable artifacts into a two-level structure: {agentRoot}/{Project}/{Topic}/{filename}.
Standard routing is deterministic and based on visible workspace context. ClevAgent avoids calling an LLM for routine placement decisions; judgment can be added later only for genuinely ambiguous cases.
It stays quiet for normal source files, configs, generated folders, internal agent stores, and files already inside the right project workspace. Failed writes do not produce stale advice.
Piling everything into one file
Rule 4 is a long-term agent-efficiency Logic, not a large-read blocking rule. It fires when ClevAgent can verify that a working file has become large enough to slow future search, editing, or context loading.
File size can be observed from structured file actions or safe shell evidence. Failed commands do not create long-file warnings.
ClevAgent suppresses Rule 4 when the user explicitly asked for one long file. It also excludes formats where raw line count is not a useful signal, such as generated assets, lock files, logs, tabular data, and notebooks.
Letting memory files balloon
Rule 5 is a periodic memory-hygiene Logic. It is not a size alarm and it does not auto-edit memory. It creates a lightweight checkpoint for reviewing whether agent memory has obvious cleanup candidates.
At a configured session interval, ClevAgent checks whether monitored memory stores exist. Quick checks stay narrow: they look for obvious candidates by file metadata first and do not rewrite memory without a second explicit user approval.
The delivery mode is always user-suggestion. ClevAgent shows a lightbulb to the user; nothing is injected into the agent unless the user clicks Send. Deep memory compression is a separate explicit audit, not a periodic popup.