The index
2026-09-12 Draft
I run Chippy with agents, and the thing that made that work was not a better prompt. It was an index.
What it is
The index is a job database for humans and agents, with a page on top of it. Every piece of work is a row. A row has a brief, a status, notes and a place in the order. Humans write rows. Agents read them, do the work, and write back what they found. Nothing else counts as the record. If it is not on the row, it did not happen.
Think of it as issues on steroids. The difference from an issue tracker is who the reader is. An issue is written for a person who will ask a follow-up question. A row is written for an agent that cannot, so the brief has to carry everything, in my own words, and it is copied onto the row verbatim rather than summarised. A summary is the first place a mistake hides.
Why a database and not a chat
Agents do anywhere from a couple of seconds to a couple of hours of work on their own. That changes how you work. Either you throw twenty things at the wall and see what sticks, or you think about everything worth doing, put it in rank order, and queue it to run while you sleep. The first way is good for a prototype. The second way is the only one that survives a real project, and it needs a place where the order lives that is not a chat window.
The question was never whether I had enough leverage. Agents can write more code in a day than I can read in a week. The question is whether I have enough alignment. If I do not know what I am building, or whether what I built is good, it does not matter how many tokens I can spend, because those tokens do not add up to a worldview. The index is where the alignment lives, one row at a time.
Rows
A row is a job. It has a title, a brief, a status, an owner, an ordered position, and a running list of notes. The brief is the spec. When I say something about the job, my sentence goes on the row with a timestamp, in my words, before anyone acts on it. When an agent lands the work, the landing note says what changed, where to look, and what it found that it did not fix. The notes are the row's own history, and the history is the thing I read when I come back cold.
A row moves through a few states: queued, in progress, verification, blocked, done. The moves are the story of the job. A row that sits in progress for a day with no note is a lie, and the index makes lies visible.
Lanes
A lane is one agent with one job at a time. That is the whole rule, and it is the one that took me longest to learn. A lane holds exactly one row in progress. Everything it is not working on goes back to the queue or on to verification. An agent with three things open is an agent that is doing one of them and forgetting the other two, and it will not tell you which.
Lanes have names, because the notes have to say who wrote them, and because I talk to them. When two lanes have to touch the same file, one of them owns it and the other asks. Ownership is written down on the row, not remembered.
Threads
A thread is a set of rows that belong to one campaign, in the order they should run. The index can hold many threads, but only one is active at a time per project. The others keep their rows and their statuses and wait. A thread's page reads like the plan, because it is the plan: this, then this, then this, and the row at the top is the one being worked right now.
Ranking is a verb. Rows get ranked, re-ranked, and pulled forward when something changes. The order on the index is the order the agents run in, so changing the order is how I steer without interrupting anyone.
One row at a time
The one-row rule exists because verification is where agentic work actually costs time. Writing five hundred lines is minutes. Proving that they do what the row said, on the real thing, with evidence I can look at, is the slow part, and it should be. If an agent is allowed to start the next row before the last one is verified, the verification never happens, and you find out a week later that three rows in a row were built on something broken.
So a lane finishes a row, writes the landing note, moves it to verification, and only then reads the next brief. The row moves to in progress before the first command on it, not after. It sounds like bureaucracy. It is the opposite. It is the only reason I can leave for six hours.
The verification lane
Verification is a status, and it is mine. Everything an agent lands sits in verification until I have opened it cold, the way a stranger would, and passed it. The row tells me where to look. If I cannot find it from the note, the note failed, not me. A row in verification carries its evidence: the commit, the film or the screenshots, the tester's report, the things the agent found and did not fix, and the picks it is asking me to make. My verdict goes on the row too, in my words, and the row closes or goes back.
That is the division of labour. Agents do the work and produce the evidence. I do the judgement. I do not review code line by line, and I do not have to, because the row asked for a behaviour and the evidence shows the behaviour. If the evidence is not there, the row is not done, whatever the code looks like.
What it changed
I stopped losing things. That sounds small. It is the entire difference between a hobby and a factory. Before the index, every idea I had lived in a chat, and every chat ended. Now an idea is a row, a row has a place in the order, and the order runs whether I am watching or not. I come back in the morning, read the thread from the top, and the day's work is either in verification with its evidence or it is blocked with a reason.
Agents do not have agency. They have your instructions and the record of what was tried. The index is that record. I can guarantee perfect context. I cannot guarantee a perfect product, and neither can anyone selling you one. But context is the part that was missing, and it turns out to be most of it.