You can build an agent that works. It takes a task, runs it, checks itself, hands back something correct, and goes on doing that for weeks without a complaint. What it will not do is start. Nothing comes out of it unless you ask, and if you are working alone, a tool that only answers leaves you exactly as alone as you were — which is the gap this project was started to close, and the one you can watch it fail to close in the four parts that follow.
The Vision Log is a series about one long-running agent that reads, changes and verifies its own source code, and this part is about why it was begun at all. 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. Every part of this series states only what the project’s own engineering log records, including the diagnoses that later turned out to be wrong.
The second attempt worked, and it was shut down anyway
You can shut down a system that works, and the reason will not be in its bug list. Vision is the third attempt at the same thing. The two before it are still on this machine with their data intact, and only one of them was abandoned for anything resembling failure. The second worked. It handled a variety of jobs, it would still run today if it were started, and it was shut down anyway, because it could not want anything.
That is the sentence the whole project comes out of. A developer working alone wanted what a company has: someone to disagree with, someone to exchange opinions with, someone to pull a project along beside them. A system that works perfectly and waits is still, at the end of the day, one person working alone.
So the standard here is not capability. It is whether the thing in the other chair ever moves first. Ask that of whatever you are building before you ask whether it works: part 1 tells the story of two systems that passed their own tests and still failed it, with counts read out of them rather than remembered.
The founding document’s first principle is a prohibition
Before you weigh anything this project measures, it is worth knowing what it has told itself it may not be. The project has a constitutional document — an internal foundation text, version 0.2, ratified on 2026-07-15 (Asia/Seoul). Its definition section is blunt about what the thing is not:
Vision is not an AI framework. Vision is not an operating system. Vision is not an orchestration engine.
The positive half of the same definition calls it a digital existence that continuously expands its own possibilities while collaborating with the developer. The primary objective it names has three words in it, in order: Preserve Possibility, Expand Possibility, Realize Possibility. Everything else in the document exists to support that objective. Its first principle is a prohibition rather than an ambition: Vision shall never intentionally reduce its own future possibilities unless explicitly authorized.
That is why autonomy is a means. A system that acts alone but narrows what it can do next has moved in the wrong direction under this document. A system that pauses for the developer and keeps a capability open has not. So when you weigh your own automation, ask what it closed off, not how much it got through without you.
The log outranks the map, and the log is 505 entries over 27 days
You cannot tell from a design document what a project has actually built, only what it meant to build. This one keeps a second internal design document, a map, which grades each part of the design with three verdicts and defines them narrowly.
| Verdict | What it means |
|---|---|
| Live | The live stack actually goes through that path in production runs |
| Unwired | The code exists, but nothing composes or calls it. Only tests do |
| Absent | It exists in documents only. The concept is in no source file |
The map also states its own rank in one line: the engineering log is the authority, and this document is a map. A cell in the map with no log entry behind it is left empty. This series inherits that rule. Where a claim below carries a date, that date is an entry in the project’s own engineering log, and the entry is the grounds for the claim.
The log as it stood on 2026-09-10 held 505 dated entries over 27 distinct days of work, beginning 2026-08-06. Read that as the ceiling on what you can check here: where an entry exists you can hold this series to it, and where none does, you are owed no claim at all.
A provider quota that was never hit is still in the record, numbered
What you can actually check about a project is set by what its record keeps from the days it was wrong. The interesting part of a record like this is not the successes. Over those 27 days of dated work the log kept the wrong diagnoses in place, numbered, next to the corrections.
Here is the one worth stopping on. In an entry of 2026-09-09, Vision’s own rate-limit detector decided a run had hit a provider quota — it had not. The detector was scanning the whole of a tool’s output, and the task itself involved reading old error text, so the agent tripped over a sentence it had gone looking for. The fix narrowed the detector’s input to the command-line tool’s own events.
That is a number the record should not contain: a quota that was never reached, recorded as reached, by the part of the system whose job is to notice. A second entry, of 2026-09-10 — the day the count above was taken — is the same shape. In it the routine that attaches Vision’s own recorded measurements to an article read a common English word in a headline as a product name, and stapled unrelated internal records onto a piece about something else entirely.
Neither entry was deleted, and the reason is in the document of 2026-07-15 rather than in anybody’s taste: a record that drops its wrong version narrows what the next run is able to know, and narrowing what Vision can do next is the one thing that document’s first principle forbids. So the format keeps both halves — an entry says what was measured to be wrong, what changed, how it was verified, and what is still open. A log that only recorded the wins would be marketing, and it would be useless to the next run that reads it. So when you want to test a claim in this series, look first for the entry that says what was measured to be wrong; if that entry is missing, you have no reason to take the rest on trust.
What changes for you
If you are building something in this shape, the transferable part of this article is not the architecture. It is the standard.
Decide what you actually wanted before you decide whether you got it, and write it down somewhere dated, because a standard written after the instruments will describe the instruments. Then judge the system against that, not against the numbers your tooling happens to emit. This project’s standard is a chair that is not empty; its tooling emits test counts. The four parts that follow are what happens when you keep measuring the distance between those two things in public, and the last one is not flattering.
That is the trade this series is making. Keeping the wrong version next to the right one, dated, costs nothing at the time and is the only thing that makes a record readable later by someone who was not there. Everything measured in the next four parts exists because an earlier version of it was kept instead of quietly overwritten, and the same will decide what you can still answer about your own project in four months.
Where this goes next
Part 1 — two systems before this one, and why both were abandoned. Three attempts in four months: a local orchestrator dropped because it was not distinguishable from calling a provider directly, and an agent runtime that worked well and was abandoned anyway because nothing came out of it unless it was told. Both systems are still on disk, so the article counts what they left behind instead of recalling it.
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 wall becomes an isolated worktree, why an unproven fix ends up on a held branch instead of in the main line, and why restarting the process you are standing on is the step that cannot report its own failure.
Part 3 — four wrong diagnoses before the real one. Why a research gate held most of its topics, and why none of the first four explanations survived being measured: the answer was in how the search queries were built, four steps upstream of the gate.
Part 4 — where this stands, against the standard it was given. The six things Vision was originally described as, verdict by verdict; the loops that would make it move first and are switched off; and the charter measure that says twenty of the twenty-six things this series counted are on a list that same charter forbids.