< Academy

GenericAgent: Smarter Context, Self-Improving Agents

Research
Timothy Abayo
ML Engineer

Most LLM agents have a context problem. An LLM agent is a language model wired up to tools: a file system, a code runner, a web browser, plus a loop that lets it work through a task step by step instead of answering in one shot.



At the start of a task it's sharp, the prompt is lean and the signal is clear. However, everything the agent reads and writes lives in its context window , a finite working memory measured in tokens.



As the task progresses tool descriptions, retrieved memories, raw feedback and stale history all pile up in that window. By the time the agent reaches the decisions that matter most, its attention is spread across noise. Also, when the session ends everything learned vanishes and the next run starts from scratch. In a recent Passion Academy session, Machine Learning Engineer Timothy Abayo dissected GenericAgent, a paper that tackles both of these problems with a single organising principle.

Slides

The core problem

Long-horizon agents (ones that run multi-step tasks over minutes or hours, rather than a single exchange) fail in two compounding ways.

Context explosion: the context window is finite. Every token of scaffolding, every retrieved memory and every piece of raw feedback pushes something decision-relevant out. That doesn't just cost more, it degrades reasoning because the model's attention is finite too. Early in a task the window is mostly signal but later, it's mostly noise.

Lost experience. Most agent frameworks treat every session as stateless i.e. nothing carries over. Whatever the agent worked out through trial and error vanishes at session end so the next run repeats the same mistakes.

The usual solution is retrieval-augmented memory: store past runs in a database, pull relevant pieces back in when needed. It helps but it doesn't close the loop. These systems store raw logs rather than distilled knowledge. They have no feedback loop that refines what's stored and stale or incorrect memories sit there quietly degrading future runs.

One principle: contextual density

GenericAgent's answer is a single idea - maximise contextual density.

Long-horizon performance isn't set by how long the context window is. It's set by how much decision-relevant information survives inside a finite budget.

Density has two parts, plus a constraint:

  • Completeness: Everything the current decision needs is explicitly present so the model never has to fall back on a guess.
  • Conciseness: Irrelevant or duplicated content is removed so the model's attention stays on what matters.
  • Naturalness is the constraint: The representation has to stay readable to the model as compression it can't parse is self-defeating.

Completeness and conciseness pull against each other: one says add while the other says cut. GenericAgent resolves that in the architecture rather than in the prompt.

How it works

Everything runs through a single loop: read context, reason, call a tool, take in the feedback, repeat.

Four mechanisms keep that loop's context dense. Each one targets a different source of clutter.

  1. Keep the toolbox small AKA a minimal tool set. Nine atomic primitives cover file operations, code execution, web interaction, memory management and human escalation. Every tool has to be described to the agent in the prompt and those descriptions are re-read on every single step. A long tool catalogue is a tax charged on every decision the agent makes, so nine primitives is close to the floor.
  2. Hierarchical memory. Memory is split across four layers: L1 is a thin index, L2 holds facts verified through execution, L3 holds reusable SOPs, and L4 is a rarely-touched archive. Only L1 sits in the prompt permanently. The agent reads the index, sees what exists, and pulls a deeper layer in only when a decision actually needs it — so the agent can know a great deal without paying for it on every step.
  3. Truncation and compression. As a task runs long, old content is cut back in layers rather than all at once. Raw tool output is summarised, the oldest turns are dropped first and the decision currently in play is left whole.
  4. Self-evolution. A verified run is distilled into a written procedure and eventually into code, so the next run of the same task costs a fraction of the first. This is the mechanism that separates GenericAgent from a well-tuned conventional agent (Let’s dive deeper).

(The backend is model-agnostic (Claude, GPT or Gemini) and the agent works across browser, terminal, filesystem and screen.

Self-evolution: from exploration to code

The first time the agent completes a task, it reasons through it in natural language (stage one) . If that run is verified as successful and genuinely useful, it gets compressed into a structured written SOP (stage two).

As the SOP is reused and refined across runs, it hardens into deterministic code, a fixed script that needs almost no reasoning to run (stage three).

In effect, the agent turns something it once had to work out into something it can simply execute.

The quality-control rule is strict: no execution, no memory. Only strictly verified, behaviour-changing results get promoted to long-term memory. Guesses, partial attempts and unverified paths are filtered out before anything is saved.

The practical effect is striking. Across a recurring research task, token cost per round fell from 222k on the first run to 23k by round nine (an 89.6% reduction). Runtime fell 78%. LLM calls fell 84%. The agent gets faster and cheaper the more it runs the same class of task.

When it does hit a failure it can't resolve, a structured escalation kicks in: a localised retry first, then a strategy switch, then a hand-off to a human. That prevents the endless repeated-mistake loops that plague agents with no failure handling.

Results

Running on Claude Sonnet 4.6 (the underlying model doing the reasoning) GenericAgent reaches 100% task accuracy on SOP-Bench and Lifelong AgentBench, against best baselines of 100% and 75%. On RealFin-Benchmark it scores 65% against 60%.

It gets there on a fraction of the tokens:

  • 84% fewer input tokens than OpenClaw on Lifelong AgentBench (222k against 1.43M) at 100% accuracy.
  • 2.9–3.9× less token consumption than OpenClaw across web-browsing benchmarks, at equal or higher scores.
  • 35% of Claude Code's tokens to match its 100% success rate on long-horizon document, SQL and research tasks.
  • An efficiency ratio of 5.70× on RealFin-Benchmark (accuracy divided by millions of tokens) against 0.67–2.31 for baselines.

What the authors flag as limitations

The paper is unusually candid about what isn't solved yet.

  • The base model sets the ceiling: GenericAgent amplifies the underlying LLM's reasoning quality; it can't replace it.
  • Exploration is capped: A 30-round execution limit means very complex research tasks have to span sessions, stitched together with written reports.
  • Token budgeting is imprecise: The roughly-three-characters-per-token heuristic under- or over-estimates in practice, particularly for CJK text.
  • Curation is still manual:  Merging and pruning the skill tree needs a human.
  • Adaptive weighting is unproven: The reflection-based curriculum weighting (how the agent decides what to learn from and in what order) is preliminary and not validated long-term.
  • The evidence is mostly single-agent: Multi-agent self-update remains open.

The broader picture

The key takeaway from the session is neat: a tidy desk beats a bigger desk.

Giving an agent more room to work in matters less than making sure what's already on the desk is clean, dense and relevant to the decision in front of it.

GenericAgent shows that the right architecture (hierarchical memory, a minimal tool set, strict quality control on what gets saved, and a self-evolution loop that turns experience into reusable code) can produce an agent that gets both more accurate and more efficient the more it operates.

The limitations are real and the multi-agent case is still open. However, as a demonstration that context management and self-improvement can be built into the architecture rather than bolted on as prompt engineering, it's a meaningful contribution.

References

< back to academy
< previous
Next >