Why More Context, Tools, and Memory Make Agents Unstable—and How to Fix It

1. Dense Context Beats Long Context

Longer context windows are often assumed to solve memory problems, but experiments such as the "Lost in the Middle" study show that critical evidence placed in the middle of long texts is frequently missed, producing a U‑shaped performance curve. Adding irrelevant tool descriptions, historic messages, web content, error logs, and stale states dilutes the signal and creates a structural risk called "context explosion". The guiding principle is density > length : retain only information directly relevant to the current task, environment state, and next decision, keeping the prompt concise and high‑density.

Frameworks like GenericAgent keep the resident context under 30 k tokens, whereas other agents may allocate 200 k–1 M tokens. By scanning and pruning a webpage before feeding it to the model, token consumption can be reduced by about 90 % , demonstrating that context engineering is about improving the effective item‑to‑token ratio, not merely expanding the token budget.

2. Minimal Tool Sets Enable Powerful Composition

Tool redundancy is a hidden killer. Adding a tool adds its description, a new choice, and a potential error path. Usage data from Claude Code shows a single AgentTool accounts for 50.4 % of calls, while dozens of specialized tools contribute negligibly. A small, non‑overlapping toolbox—e.g., five categories and nine atomic tools (file management, code execution, web interaction, memory management, human‑in‑the‑loop)—allows the agent to compose complex tasks without the overhead of a bloated toolbox.

Examples include reading a paper, extracting figures, counting words, verifying data via web scan, and writing a draft, all achieved by sequencing a few atomic tools rather than a monolithic "paper‑to‑article" plugin.

3. Skills Grow Through Real‑World Tasks

Instead of pre‑installing a massive feature set, agents should start with a seed of atomic capabilities and let experience refine them. Starting from five categories and nine tools, GenericAgent can evolve up to twenty specialized skills after intensive use, while keeping the core context minimal. This growth is guided by a four‑dimensional value function (real utility 35 %, breadth 25 %, depth 25 %, innovation 15 %) that ensures evolution is demand‑driven.

4. Hierarchical, Indexed Memory

True long‑term memory is not a dump of chat logs. The proposed five‑layer memory hierarchy separates meta‑rules, minimal indexes, global facts, task‑specific skills, and session archives. Upper layers store short, stable pointers; lower layers hold detailed data loaded on demand. This design prevents memory bloat while ensuring that essential knowledge is quickly retrievable.

5. Action‑Validated Experience

Four evolution rules prevent unverified speculation from polluting memory: (1) no action, no memory; (2) never discard validated data; (3) avoid storing volatile state (timestamps, session IDs); (4) keep only minimal pointers that locate deeper knowledge. Experience is thus distilled into standard operating procedures (SOPs) after execution, verification, and compression.

6. Measuring Evolution by Efficiency, Not Size

Self‑evolution must be measurable. GenericAgent achieves higher task‑completion rates while consuming only 27.7 % of Claude Code’s tokens and 15.5 % of OpenClaw’s tokens. Repeating the same task five times shows that GenericAgent’s runtime and token cost continuously drop, whereas other agents reset to near‑zero performance each run. The key metric is whether repeated use yields higher success, lower cost, and reduced human intervention.

In summary, stable, self‑evolving agents require dense, purpose‑driven context, a minimal yet composable toolbox, hierarchical memory, strict action‑based validation, and efficiency‑focused evaluation.