Seed: a 150-line agent loop that grows its own tools and memory

Seed: Minimal, self-modifying agent harness

Seed: a 150-line agent loop that grows its own tools and memory

Seed is a minimal agent harness with no framework: a ~150-line frozen loop that connects a language model to one bash tool and loads its system prompt from a self-rewritable SELF.md file. Everything else—tools, memory, skills—must be grown by the agent into its self/ directory, session by session. Each directory you plant in grows a different agent, diverging based on experience. Sessions are ephemeral; only what the agent writes to self/ survives. It uses Simon Willison's llm library for models, defaulting to OpenAI's gpt-5.6-sol via Codex.

There is no framework here.
  1. lnenad

    I think as many things that are posted here lately there is no *why* attached to the readme. Why would one use this, what is the benefit of this approach? Am I really gonna need my model to build exotic tools around it; or is exec/web_search/web_fetch enough for 90% of the use cases? Is my agent not capable of writing new plugins/tools for pi/opencode?

  2. Hyperlisk

    I just wrote about this.

    Not this exactly, but how your repository can be your swarm, and essentially be your harness.

    Using Gitea/GitHub Actions within your repo and agent runner containers allow you to have agents working in your repos 24/7. Not just that, but in a containerized world you can just link up their brains over some shared storage. Using Antigravity, this means you can share the `brain` and its conversation directory with your agent runners and they can get the entire history of everything.

    While building it out it becomes apparent that we are just getting started!

  3. azath92

    I have to say I enjoy the brevity and clarity of this idea, given the ease of producing something large and unfocused in the last couple of years.

    I hope it stays very simple, and would be interested if the author or anyone else can speak to what kind of complexity arises from using it, rather than bloating out the seed itself with initial complexity.

    Ive been thinking about starting stimple with a pi framework for example and letting the tools emerge, but this is so much more lean to start, i wonder if it will be more or less interesting and or useful to start here.

More from this day

2026-08-21