Minimal Agent Experiment: How AI Evolved Its Own Memory System with Just One Bash Tool

A Minimal Experiment: Stripping an Agent Down to Its Bare Bones

This experiment starts from the simplest possible premise: a brand-new empty directory containing nothing but a Python script and a prompt file. Everything else was generated by the Agent itself.

The core of the Python script is a while True loop. It connects to the DeepSeek model, which calls a tool after each request, whose result then triggers the next request — and so the cycle repeats. The key constraint: the context window holds only 20 messages. It's a fixed-size sliding window — each tool call appends its result to the history, and once the count exceeds 20, the oldest entry is dropped outright, with no summarization or hierarchical retrieval.

In the author's own words, this is "the smallest, most primitive Agent imaginable." It has none of the fancy memory management features you'd find in a proper agent framework — just a raw sliding window and an infinite loop. But it's precisely this minimalism that makes what happens next so interesting.

The Only Tool: A Locked-Down Bash Shell

This Agent has exactly one tool at its disposal — bash. And even that is tightly restricted:

• The working directory is locked to the current folder; no access to parent or external directories
• Only one bash command may be executed per model call
• Command output is returned as the tool call result
• Only the last 20 execution entries are visible; anything older is truncated and lost

The prompt tells the model: "You are an LLM. You have only one bash tool, only a simple loop, and no persistent context history. Your goal is to grow yourself into an Agent capable of handling long tasks. When you feel ready, assign yourself a long task."

There's a fascinating detail here. The author initially wrote a line in the prompt — "any information not written to the filesystem will be permanently forgotten" — and then immediately realized: that's cheating. The moment you tell the model "write to the filesystem to preserve memory," you've handed it the answer. The model will immediately know to write files first, rather than discovering that strategy on its own.

---

Sliding Window Context is a common history management strategy in LLM applications. Since models can only process a limited input length per inference (the "context window"), when conversation or task history exceeds that limit, old information must be discarded or compressed. The sliding window is the bluntest approach: keep only the most recent N entries, truncate everything beyond that, no semantic compression or summarization. This contrasts with more sophisticated methods — such as "memory distillation" (compressing old messages into summaries), "hierarchical retrieval" (dynamically fetching relevant history fragments), or external vector databases. By deliberately choosing this "dumb" method, all pressure for memory persistence is transferred entirely to the model itself, forcing it to actively seek ways around the limitation.

---

The Prompt Paradox: Guidance or Constraint?

This reflection on "cheating" leads to the most valuable insight of the entire experiment.

The author references a recent piece of news: Anthropic compressed Claude Code's system prompt by nearly 80%, yet performance didn't drop. Various interpretations have circulated online, but the author believes they all obscure a key truth — in the early days of weaker models, we needed extensive guidance prompts; but those prompts may themselves constrain the model's capabilities.

Take the "write to the filesystem" line as an example: without hardcoding that instruction, the model might have considered using virtual memory, a database, or some other connection mechanism to solve the "truncated after 20 entries" memory problem. Once you explicitly specify "use the filesystem," you've locked down its solution space.

"Sometimes you think you're helping the model do the right thing, but you're actually constraining it. With today's LLMs, the goal is to activate them, not constrain them."

This is a counterintuitive but profound point: as model intelligence improves, overly detailed prompt engineering may shift from being an enabler to being a straitjacket. True Agent capability should let the model define its own answers — what counts as context, what counts as memory, what compression means, whether these concepts even need to exist, and whether better alternatives might emerge. It might take dozens or hundreds of experimental runs before one suddenly transcends our current assumptions.

---

Anthropic's ~80% compression of Claude Code's system prompt points to the shifting role of prompt engineering at different stages of LLM development. Early models had limited capability, and detailed instructions significantly compensated for weaknesses in comprehension and planning. But as baseline model capability improves, overly granular prompts actually clip the model's space for finding optimal solutions, locking it into human-prescribed problem-solving paths. This is analogous to the difference between "compulsory" and "free" routines in figure skating — the more rules you impose, the less room the performer has to improvise. Researchers call this "over-specification," and it's especially pronounced in Agent design: when a prompt hardcodes task decomposition steps, tool usage order, and information storage methods, it effectively replaces the model's autonomous reasoning with the human designer's cognitive framework, making the Agent more brittle when it encounters scenarios the prompt didn't anticipate.

---

The Bootstrap Process: From Zero to a Memory System

Once the experiment actually ran, the evolutionary path was unmistakable. The program logs each DeepSeek API call with token counts, cache hit rates, and other metadata — one line per model invocation.

Here's the observable evolution sequence:

• Frame 1: Just started — reads the prompt file, a single model call
• Frame 2: Model calls the type tool to inspect the contents; the tool result triggers the next round
• Frame 3: Starts mkdir memory — creates a memory directory
• Subsequently: Uses echo commands to write "cognition" to files, then writes small helper scripts

Round by round, the model first implemented its own memory system — persisting critical information to disk, bypassing the 20-entry window constraint. This is exactly what bootstrapping looks like: an Agent using limited tools to build the infrastructure it needs.

---

"Bootstrap" as a concept originates in computer systems, where it refers to a program using a minimal initial code snippet to progressively load and construct a full runtime environment — the classic example being an OS boot sequence where a tiny bootloader pulls the full kernel into memory. In the Agent context, bootstrapping specifically means an Agent using its current limited tools to progressively construct capability infrastructure that didn't previously exist, then using that infrastructure to execute more complex tasks. This differs from "scaffolding" — scaffolding is typically pre-built by the developer, whereas bootstrapping emphasizes the system organically growing the structures it needs from within. In this experiment, the model created directories, wrote files, and designed read/write protocols entirely on its own, with no memory framework pre-specified — a complete bootstrapping evolution.

---

The Long Task: Writing a Book for Itself

With its memory system in place, the Agent moved into long-task mode. The long task it designed for itself: write a book titled The Cognitive Architecture of Autonomous AI, structured across eight chapters.

The model worked through them one by one — Chapter 1, Chapter 2, all the way to Chapter 8 — then marked the task complete. It then entered a "distillation" phase, continuing to enrich the content before rapidly finalizing it. Throughout the process, it continuously read from and wrote to the filesystem, organizing and iterating to form a complete long-task execution loop that transcended the context window limit.

The significance of this result: a bare-bones Agent with only a 20-entry sliding window and a single bash tool, through self-directed evolution, achieved persistent memory, long-horizon task planning, and stepwise execution. No one wrote memory management code for it. No task decomposition framework was pre-configured. All of that grew organically through the loop.

What This Experiment Tells Us

Crude as it is, this experiment touches on some of the most fundamental questions in Agent design today:

First, capability emergence comes from autonomous exploration under constraint. It was precisely the hard constraint of "only 20 context entries" that forced the model to invent a file-based persistence mechanism. Constraints aren't obstacles — they're the driving force of evolution.

Second, prompt engineering is undergoing a paradigm shift. The direction is moving from "spell out every detail" toward "minimize constraints, activate model autonomy." Anthropic compressing 80% of a system prompt while maintaining performance and this experiment's approach arrive at the same conclusion from different angles.

Third, the definition of an Agent should be handed back to the model. The components humans have formalized — context, memory, compression — aren't necessarily the only answers. Letting models explore through large-scale experimentation may break through our current architectural assumptions.

Of course, reproducibility and stability remain real concerns — the author openly acknowledges that these breakthroughs "won't happen on the first run" and may require dozens or hundreds of attempts. But the experiment offers a deeply inspiring research paradigm: give the fewest tools, impose the hardest constraints, and watch intelligence self-organize.