The idea pipeline that mostly says no

Ideas are free and building is not. The failure I keep repeating is not picking a bad idea — it is picking a plausible one and finding out what was wrong with it four weekends in, at which point I have a half-built thing I am too invested in to kill.

The obvious fix is to research the idea first. The reason I never did is that research is boring, it takes an evening, and the whole appeal of a new idea is that you get to start it tonight. So the step that would save the four weekends is precisely the step that loses to enthusiasm every single time.

There is a fashionable answer to this now: point an agent at the idea and let it research, prototype, and build. I think that answer is wrong, and not for the reason people usually give. It is not that the agent is incapable. It is that an autonomous pipeline removes the only step that was ever going to save me — the moment where somebody reads the research and says no.

An idea enters by hand, or by voice from my phone. From there it moves through sixteen states, of which only two matter to this write-up, because they are the two where everything stops.

First the idea gets a market research run: a headless agent job, twenty to forty turns, four to seven minutes, a dollar or two. It produces a research card and moves the idea to research ready — and that is as far as anything automatic goes. I read the card. I approve a prototype, park it, or reject it. Nothing else can make that move.

If I approve, the idea gets a deliberately timeboxed prototype, which produces a second card and stops again. The second gate carries a decision the first one does not: approving a build also means choosing the stack. Only after that does an idea become a real repo built by finite, checked jobs.

The portal that shows all this has four sections, and the first is called awaiting you. It is the only section with large cards; everything else is a quiet row. The page exists to make decisions, not to be browsed.

Everyone building agent systems says there is a human in the loop. Usually what they mean is that the code politely asks first. That is a convention, and conventions lose to bugs, to refactors, and to the version of me who is in a hurry on a Sunday night.

The permission lives in the data, not the code

The state machine is a table of edges, and every edge carries the set of actors allowed to take it. Most edges permit the orchestrator. The two gate edges — research ready to prototype approved, prototype ready to build approved — permit exactly one actor, and it is not the machine. The orchestrator is not restrained from crossing those edges; it is simply not in the set, so the attempt raises rather than proceeds.

That distinction is the whole design. A check inside the dispatcher would be a rule the dispatcher could get wrong. A missing entry in a transition table is not a rule at all — there is nothing there to get wrong. The module holding it lives deliberately apart from the job code, it is the one thing the tests assert hardest on, and the practical consequence is that a bug in the part of the system I change most often cannot advance an idea past me. It can crash. It cannot decide.

Nothing is unrecoverable

The counterweight to a hard gate is that every terminal state can be revived by hand. Rejected goes back to the inbox; abandoned goes back to review. A misclick on a single button should never destroy work, and a system that makes saying no feel dangerous will quietly teach you to stop saying it. Every move, including the revivals, lands in an audit log with the actor recorded — which is how I can tell you that of the thirty-two transitions so far, the machine proposed and I disposed, every time.

One source of truth, and a render

An earlier agent-run project of mine kept its status in Markdown files, and they rotted — because two things could write them and neither owned them. Here the database is the authority and every document is a generated, read-only render of it. If a status file and the database disagree, the file is wrong by definition and regenerating it is the fix. It sounds like a filing decision. It is actually the difference between a system you can trust after a month and a pile of confidently stale documents.

Be clear about what this is: phase three of six, two days old. Gate 1 has been exercised eight times. Gate 2 has never had an idea reach it, and the build worker that would run past it is designed but not written. The zero in the impact strip above is honest in both directions — nothing has been built partly because nothing was approved, and partly because the half that builds does not exist yet.

The more interesting problem is that I cannot yet tell you what a six-in-eight rejection rate means. It could mean the research is doing its job and my ideas were mostly not worth four weekends. It could equally mean I have tuned a machine that is pessimistic by construction, and it is talking me out of things I should be doing. With eight ideas there is no way to distinguish those, and the honest version of this page in six months will either be a much better story or a retraction.

The thing I would watch for is a gate that stops being read. A decision point a human always approves is not a gate, it is a speed bump with extra steps, and the failure mode of every approval workflow ever built is that it degrades into one. If the rate ever settles near a hundred per cent approval, the gate has stopped doing anything and should be removed rather than admired.

Every team automating a workflow with models eventually reaches the same question, and mostly asks it backwards. The question is not how much of this can the machine do. It is: which single decision, if we get it wrong, costs us a quarter? Automate everything up to that decision, spend real money making the evidence in front of it good, and then stop dead.

The second half matters more than the first. A gate enforced by policy is a gate that will be crossed by accident within two releases, because the code that crosses it is the code you edit every week. If a decision genuinely requires a human, make it structurally impossible for the system to make that decision — not forbidden, impossible — and then make everything around it cheap and fast so that nobody resents the stop. Most of the value in an AI system is in the parts where you decided it would not act.