106 Days Later: Why yoyo’s Harness Is Simple and Effective, and Thoughts on a Future “Persistent State Harness”

What long-running agents truly need isn’t a smarter model — it’s persistent state.

yoyo has been evolving itself for over a hundred days. Every 8 hours, a GitHub Action wakes it up. It reads its own source code, decides how to modify itself, completes the modifications and tests, then goes back to sleep. No human ever touches its code. The interesting part isn’t “an LLM can write Rust” — it’s this: why has this particular loop not drifted off course or silently stalled within a week, unlike most autonomous agent projects?

The answer is simple — a design insight carried through to its logical conclusion: keep the agent stateless and disposable, keep the state robust and persistent. Every thorny agent problem (memory, context, long-running duration, feedback, validation) — yoyo doesn’t solve with fancy agent-specific stacks. It solves them with plain, old system building blocks: files, processes, exit codes, cron, and git. The model is treated as an unreliable subprocess stuffed into a reliable workflow loop. Let’s break it down step by step.

Memory: Forced Into a Git Repository

yoyo has no vector database, no memory service to load. Its memory is just a few markdown files (JOURNAL.md, LEARNINGS.md, SOCIAL_LEARNINGS.md), committed into the same repository as the code. This works for yoyo because: first, memory is distilled at write time, not retrieved at read time. At the end of each session, yoyo condenses what happened into a few sentences, so the stored memory is small enough to load entirely at once. Second, writing is mandatory. The harness checks whether the log entry exists. If yoyo slacks off and doesn’t write, the harness runs it again with a prompt specifically for this purpose. If that fails, a fallback mechanism generates a minimal record directly from the commit log. The rules are defined in the harness, not left to the model’s “goodwill.” A memory system an agent forgets to use is no memory system at all.

As it turns out, git is a fantastic memory container: append-only, versioned, auditable, and free. A hundred days of “identity” is just a git log.

Context: Built Fresh Every Time

Most agents die from context. Conversations balloon until the model reasons through a fog of its own history. yoyo avoids this by design: it builds context from scratch every time, rather than letting it accumulate and bloat. Each run is a new process with a freshly constructed context. Identity, tone, and distilled experience are stitched together; the harness adds exactly one task, the task finishes, and the process exits. Nothing carries over to the next run except what was deliberately written to files. yoyo has an automatic context compression mechanism, but it rarely needs it because no single task runs long enough to fill the window. Identity is re-injected verbatim every time — that’s why the tone has stayed consistent across a hundred days of sessions. Personality drift is a symptom of context accumulation, and when you rebuild context from scratch each time, there is simply nothing to drift.

Long-Running: Many Short-Lived Processes, One Repository

yoyo’s harness never lets anything run for long. There’s a timeout for the planning phase, 15 minutes per implementation task, 5 minutes for fixes, 2 minutes for logging. What we call “long-running” comes from chaining a series of short-lived processes together, where the only shared resource between them is the file system. One hang loses at most one task. One crash loses nothing important. An API error cleanly aborts the current run and lets the Action retry. Those hundred days of duration do not live inside any context window, nor inside any process — they live inside the git repository. Cron keeps intent alive, logs keep the story alive, and each session handles exactly one bounded thing. Long-running is just persistent state plus a scheduler — and neither of those is a model.

Feedback: The Environment Is the Critic

There is no human in the feedback loop. The harness contains three feedback loops at different speeds. Inside a single task, compilation errors and test errors are fed back verbatim to the yoyo agent. Rust’s famously descriptive error messages become a free, precise, never-tiring critic. Inside a single session, the wrap-up phase runs up to three full cycles of validation and fix. Between sessions, the harness pulls CI results from the previous run, feeds failure logs into the next planning prompt, also ingests community issues (each must have a response: implement, won’t fix, or partial), and forces a round of reflection into LEARNINGS.md. yoyo never scores itself. The environment scores it, and the harness ensures that score is real and usable.

Validation: Checks Are Critical

Any result that wants to survive must pass tests. Automated fixes after validation failure are layered and honest. First cheap deterministic fixes (cargo fmt auto-fixes, no model involved), then errors are shown to the agent to rerun, up to three times, and if that still fails, roll back to the commit at the start of the session. And that rollback itself is also committed. Failures remain visible in the history, not silently erased. More importantly: the agent undergoes a “does this thing actually work” test. Code is the easiest domain for autonomous agents precisely because both success and failure are tangible and come with detailed information. yoyo’s harness works because it never skips a step it hasn’t checked.

Looking Ahead: Persistent State Harness

yoyo started as a simple 200-line agent: one language, one test suite, running on a schedule. But the fact that it hasn’t fallen apart in a hundred days shows that the harness is the real weapon for making agents robust over time. Reliability is built into the harness, not the model. And reliability is the line between a demo and something you can truly walk away from.

“Today’s harness is temporary — a sufficiently capable future model could replace it.”

That’s partly correct. The judgments in the harness will indeed move into the model over time: how to decompose a problem, when to retry vs. escalate, how large a task should be. yoyo’s planner is exactly that kind of stopgap — it should thin out as model capabilities grow. But some things are not meant to be owned by the model. For instance, validation rollback belongs to the environment. Persistent state, by definition, sits outside the model.

This last point points to the future. A context window, no matter how large, disappears when the process dies. Verifiable memory, identity, a record of what has been tried — all of this must live somewhere outside the model, or it won’t survive a crash, a restart, a model upgrade. So the harness that survives is not a planner or an executor — it’s a persistent state layer that the model can use. The stronger the model, the thinner the scaffolding around it, but the persistent foundation they run on only becomes more central. Agents will get smarter. State will outlive them. That’s what is truly worth building.