The hardest project to shut down is the one that works. There is no bug report to point at, no benchmark that says stop, and every day it keeps running is an argument for keeping it. Two systems were built and abandoned on this machine before the one this series is about, and only one of them was broken — so the useful question is what standard retires a system that passes everything you ever asked of it.
This is The Vision Log, a series about one long-running agent that reads, changes and verifies its own source code, and this part is the two attempts that came before it. Vision is not an assistant and not an automation framework: it is designed as a digital counterpart to the developer who built it, and autonomy is a means it uses rather than the point of the exercise. This part rests on the project’s own engineering log and on what the developer said on the day they first told this story, and where neither supports a claim the claim is left out. Part 0 explains what the project is and the wish it came from.
Only one of the three attempts was abandoned for anything like failure
If you have shelved projects, you probably cannot say today which of them actually failed. Until 2026-09-11 the earlier attempts had not been described anywhere in this project’s record. On that day they were, and the short version is that this is the third attempt, that the first two are still sitting on this machine with their data intact, and that only one of them was abandoned for anything resembling failure.
The developer calls the two earlier systems Vision Alpha and Vision Beta, and this article uses those names from here on. They are worth reading carefully, because they look like version numbers and are not. Vision Alpha, Vision Beta and Vision are three attempts at the same wish, numbered in the order they were made. They are not three releases of one codebase: nothing was branched, forked or upgraded from one into the next, and the section below on what was carried over is the measurement that settles it.
| Attempt | Worked on | Built with | Why it ended |
|---|---|---|---|
| Vision Alpha, an orchestrator for local models | 2026-06-08 to 2026-07-03 | Python, a web API framework, a state-graph library, a local model server, a vector store | The direction itself was judged wrong |
| Vision Beta, an operating system for agents | 2026-06-21 to 2026-07-29 | TypeScript on Node, everything in one embedded database | It worked, and it was not what was wanted |
| Vision | 2026-08 to now | A different stack again, rebuilt from nothing | Running |
Both Vision Alpha and Vision Beta are readable on disk today, which is why this article can quote counts rather than recollections. Hold the same test against anything you shelved this year: if you cannot open it and count, what you have is a memory of it.
Vision Alpha: a local orchestrator that ended up being a worse way to call a provider
You can build the sound version of a thing and still end up with a worse way to call somebody else’s model. Vision Alpha was a personal orchestrator for local models. Its design document states seven principles, and the first one is the whole idea: local first, zero cost. Inference ran on a local model server on the developer’s own GPU, and external providers were an optional delegation rather than the engine. The second principle wired models by weight: small models for routing and review, large models for coding and reasoning, deliberately not one model for everything. The rest were a human approval gate before any file write or external command, a sandbox that confined file and process access to permitted roots, memory in three layers, and a reflection step that extracted lessons after each task.
That is a reasonable design. It is roughly the design most people arrive at. Here is what it left behind, read out of its own database today.
| What remains | Count |
|---|---|
| Tasks recorded | 295 |
| Knowledge entries | 124 |
| Conversation turns | 74 |
The task timestamps run from 2026-06-10 to 2026-06-21. The last write to its vector store is dated 2026-07-03. So the system ran, and did real work, for about two weeks.
The reason for stopping is the useful part, and it is not a technical complaint. In the end, the developer said, it was not distinguishable from calling a provider directly. By that point better orchestrators already existed, so making this one better was either impossible or pointless. The direction itself was wrong.
That judgment is worth separating from the usual reasons projects die. Nothing here was broken. The approval gate worked, the sandbox worked, the memory worked. The problem was that the finished thing sat between the user and a provider and added, on net, a worse interface to the provider.
Takeaway. If what you are building is not distinguishable from using the tool directly, and something better than it already exists, the direction is wrong. That verdict does not require a single bug report, and no amount of polish reverses it, so it is worth asking of your own project on a day when nothing is broken.
Vision Beta worked, and one of its 91 runs never finished
The harder case for you is the one that passed everything. Vision Beta was more ambitious, and its own documentation opens by refusing the obvious framing:
It is not a framework for building one agent. It is an operating system in which agents are born, work, remember, reflect, learn, and evolve.
The runtime shape was a lifecycle: execute, review, retry, remember, learn. The stack was TypeScript in strict mode on Node, with state, run metadata, vector memory and a graph all living in a single embedded database file, chosen because the hard part was the structural correctness of the state machines rather than anything to do with machine learning. A run could pause for human review, record the approval or the rejection, checkpoint the paused step, and resume after a restart. Generated code ran in a Docker sandbox with no network and read-only mounts, with a fail-closed mode for production-like operation.
This one left considerably more behind.
| What remains | Count |
|---|---|
| Runs | 91, of which 56 completed and 34 failed |
| Steps executed | 431 |
| Vectors in memory | 3,716, being 3,639 document chunks and 77 episodes |
| Patterns learned | 33, being 17 best practices and 16 strategies |
Read the first row again. Those 91 runs account for 90 outcomes, 56 completed and 34 failed, and the run missing from that arithmetic is still marked running — from a process that stopped months ago and is never going to report anything. Nobody is coming back to close it. The run timestamps span 2026-06-23 to 2026-07-06, and its scheduled daily outputs continue to 2026-07-20.
That unclosed row is what a retired system actually looks like from the inside, and it is the reason this article can be written from counts rather than from memory: nothing tidied the database up, so it still says exactly what was true at the moment the process stopped.
The reason for stopping this one is the reason this series exists. It did not fail. It was good to use, it handled a variety of jobs, and it would still work today if it were started. What it could not do was want anything. Nothing came out of it unless it was told to produce something. And the developer, working alone, wanted what a company has: someone to disagree with, to exchange opinions with, to pull a project along beside them.
Vision came out of that sentence. Not out of a performance problem, not out of a limitation, not out of a bug. Out of the fact that a system that works perfectly and waits is still, at the end of the day, a person working alone.
Takeaway. The reason to abandon a working system may not be a defect. If the standard is what you actually wanted, then "it works" is not an answer to it, and a project that passes every test it has can still be measured against the wrong thing entirely.
Nothing was carried over but one capability
Here is the story you will be tempted to tell, and it is false. The tempting story is that three attempts in four months describes an evolution, each system inheriting the last one’s parts and improving them.
The record is explicit that it does not. Exactly one capability was deliberately carried forward from Vision Alpha and Vision Beta into Vision: the ability to reference outside information. Everything else was built from scratch.
The disks agree with that account as far as they can. The three systems share no stack: Vision Alpha is Python behind a web API framework, Vision Beta is TypeScript on Node, and Vision is a different arrangement again. Vision Alpha’s 295 recorded tasks and Vision Beta’s 431 executed steps are still sitting in their own databases, carrying their June and July timestamps, and nothing was imported out of either one.
So the continuity is not in the code. It is in a sequence of judgments: local-first and cheap is not a reason for a system to exist, a working agent runtime that waits is not a colleague, and both of those conclusions had to be paid for with a finished system before they could be believed. That is the starting point Vision was built from — not a codebase, two verdicts. Write down the two or three you have already paid for, because those, and not the repository, are what you actually carry into the next attempt.
What changes for you
Two questions are worth putting to your own project early, while it is still cheap to redirect.
The first is whether a user could get the same result by calling the underlying tool directly. If they could, the layer you built is overhead, and the existence of a better layer elsewhere settles it faster than any benchmark you could run. Distinguishability is a design requirement, not a marketing one, and Vision Alpha shows what it costs to discover it at the end: a working approval gate, a working sandbox, a working memory, and no reason to keep any of them.
The second is what you actually wanted, written down before you measure whether you got it. Vision Beta passed on every axis it had. It was abandoned because none of those axes was the one that mattered to the person using it, and no amount of additional passing would have changed that.
There is also a cheap habit here worth copying. Two shut-down projects with intact databases are the only reason this article quotes counts instead of recollections, and keeping a dead project readable costs disk space and nothing else. A retired system you can still query is evidence; a retired system you deleted is an anecdote, and four months later you will not be able to tell the difference between what you built and what you remember building.
Where this goes next
Part 2 — what breaks when an agent edits its own repository. The most mature machinery in the project, and the four ways it has failed in production: how a recorded refusal becomes an isolated worktree, why an unproven fix ends up on a held branch instead of in the main line, and what happened on the morning the stack went down for seventy-eight minutes without telling anyone.
Part 3 — four wrong diagnoses before the real one. Four days of explanations that each measured flat, and the real defect four steps upstream of where the symptom appeared.
Part 4 — where this stands, against the standard it was given. The measurement this part stops short of: how much of the empty chair has actually been filled, which of the machines for acting unprompted are switched on, and the charter list that rules out almost everything this series counted.
Part 0, on what Vision is and the wish it was built from, is here.