Workflow Hub

Instead of relying on a single AI chat, I structure the work as an executive team of specialist perspectives. I define the problem, assign roles such as CTO, product leader, economist, marketer, and skeptic, and have each expert analyze it independently. Then I run several rounds of critique so they can challenge one another’s assumptions before synthesizing their areas of agreement and disagreement. The process ends with a recommendation that includes the rationale and any remaining uncertainties. Step-by-step: 1. Define the problem clearly. 2. Assign specialist roles, such as CTO, product leader, economist, marketer, and skeptic. 3. Have each expert analyze the problem independently. 4. Run several rounds of critique in which the experts challenge one another’s assumptions. 5. Synthesize the areas of agreement and disagreement. 6. Produce a final recommendation with its rationale and remaining uncertainties.

I had a ChatGPT subscription that I knew I would not use during the coming month, so I wanted to find a productive use for the tokens I would otherwise pay for without using. I created a team of specialized agents on Raft that works persistently in the background. They continue working until all my allotted tokens are used, wait for the tokens to reset, and then continue. I assigned them a project: searching a stretch of LiDAR-mapped dense forest in Slovenia for archaeological discoveries. The agents scan the dataset for meaningful anomalies that could point to potential findings. Anything they identify will be handed over to the Slovenian authorities for further investigation. Even if they find nothing, that result is valuable in its own right. I encourage anyone with an idle AI subscription to use it for something beneficial. There are many publicly available datasets containing potential discoveries that no human would ever have time to examine manually. Step-by-step: 1. I identified a ChatGPT subscription that I would not be using during the coming month. 2. I created a team of specialized agents on Raft to work persistently in the background. 3. I configured the team to work until my allotted tokens were used, wait for the reset, and then continue. 4. I directed the agents to scan LiDAR data from a dense forest in Slovenia for meaningful anomalies. 5. I planned to hand any potential discoveries over to the Slovenian authorities for further investigation. 6. I treated a lack of findings as valuable information as well, since the dataset would still have been examined.

I never ask AI to “build the app.” I move the work through a fixed assembly line, and the most valuable stations are the ones whose only job is to attack what came out of the previous station. I’m a solo developer, and this is how I build and ship software for paying clients without a team to catch my mistakes. I choose the next chunk of work—a “phase”—and run one command. Each phase gets its own fresh context window, which matters more than any single agent because a long-running session gradually forgets its own rules. Step-by-step: 1. I discuss the phase with an agent that interrogates me until every gray area is decided. The decisions go into a file instead of staying in chat, where they can get lost. 2. A planner writes an executable plan covering the tasks, files to be changed, a threat model, and the acceptance checks that will prove the work succeeded. 3. A different agent, working from a fresh context, checks the plan by working backward from the goal and trying to prove that the plan will not achieve it. This agent can block the phase, and regularly does. 4. I execute the plan task by task, making one atomic commit for each task so the changes can be reverted cleanly. 5. I send the diff to a different model than the one that wrote it. I run Codex and CodeRabbit alongside Claude. This is the highest-value station in the line: my own tests verify only what I thought to check, while an independent model can catch the class of problem I did not anticipate. 6. An agent verifies whether the phase goal was achieved by re-deriving it from the actual code. “All tasks completed” and “the thing works” are different claims. Treating them as the same is how you ship a green checklist on top of a broken feature. 7. Before anything reaches a client, I run a security and handoff audit in a real browser against a throwaway clone of the production database. I check every page, every button, and every empty and error state. The part that compounds is what happens when a bug reaches me anyway—whether I find it in production or, worse, a client reports it. I log it as an escape, then walk the chain backward and ask each gate why it missed the problem: the planner, plan checker, executor, both reviewers, verifier, security check, and handoff audit. A one-off escape becomes a written rule. A repeat becomes a change to the gate itself. I have 42 logged escapes. That file is the most valuable thing I own because every entry represents a hole that is now closed. The pipeline I run today is mostly shaped by bugs that got past the pipeline I ran a year ago. The results so far: 29 projects, 17,657 commits, and 574 phase folders. I’ve completed six client engagements, with apps live in production and handed off to their owners, as well as mobile apps built and pushed through App Store review—all as one person, with no team. There are real costs and failure modes. A phase with every gate enabled costs meaningfully more tokens than simply asking a model for the code. That is worth it on client work, where a bug can cost me a relationship, but it is overkill for a throwaway script, so I turn the gates off for those. Gates can also be confidently wrong. My most expensive recurring failure is a check that passes on a signal adjacent to the thing it claims to verify—a green light that means nothing. My rule now is that I do not trust a new check until I have watched it fail against known-bad input. A green result you have never seen turn red is not evidence. A green test suite is not the same as a working feature. Nearly every bug that escaped me was covered by a passing test whose mock had quietly pre-satisfied the exact condition under test. Testing the real boundary is the only thing that catches those failures. This process is not hands-off. I deliberately run one phase per session, and I read what comes back. Anyone selling a fully autonomous overnight build is selling a merge conflict plus a confident summary of work that did not happen. If you want to take one idea from this, it is not the framework. The agent that writes the work must never be the one that approves it. Keep a running log of everything that gets through anyway, then fix the checkpoint that let it through instead of only fixing the bug.

I built an episode with the wrong voice. It was not a bad take; it was the voice of a different project entirely—a narrator I had cloned for another series months earlier. Nothing in my files identified which voice belonged to which show, so the assistant picked the one it had seen most recently. I did not catch the mistake until the mix. That is what working with agents on anything long actually costs you: not bad output, but amnesia. Every session starts cold, so settled decisions get reopened, undocumented rules get broken, and the same argument returns every week wearing a different hat. I run several short-form historical and science-fiction series at once, and they all survive on one file each. It is not documentation or a spec. It is what film crews have used for a century: a series bible combined with a daily production report, pointed at an agent instead of a hundred people. I use one Markdown file, read at the start of every session and updated when the session closes rather than when it opens. Four sections do the work: Step-by-step: 1. Closed canon: Each decision includes its reason. Mine says the opening shot is never a contemplative establishing shot. It opens mid-action, with the text hook on screen by the first second, and the beautiful wide shot comes second as the breather. I write the reason next to the decision because the plan for the current episode came back with that wide shot opening the sequence, and I had to reorder it again. The decision alone stops nothing; the reason keeps the rejected version from returning. 2. Rejected list: I record what was already tried and exactly why it was dropped. The wrong voice lives here now as one line: never reuse assets across projects without confirming. This is half the value of the document, and it is the half almost nobody writes. 3. State table: I track each item, its known defects, and the decision already made about it. Mine currently reads: lips at 62.5 to 63.5 seconds, native voice at 64.1 to 65.6, voice moved forward and the original position ducked. A defect written down with its fix is an instruction. A defect nobody records is work you pay for twice. 4. Next three actions: I list concrete next steps, each naming the file it touches. Never “keep going.” Step-by-step: 1. Create `HANDOFF.md` at the root of the project before any real work starts. 2. Write the goal, deadline, and delivery constraints. Anything external that forces your hand goes here instead of staying in your head. 3. Add every consequential decision to the canon, along with its reason and what broke with the alternative. 4. Whenever something is tried and rejected, add a row to the rejected table. It takes fifteen seconds and can save an afternoon. 5. Maintain a state table of the real items, including their defects and agreed fixes. 6. Close every session by updating only three things: the state, the new rejections, and the next three actions. 7. Open every session with: “Read `HANDOFF.md` in full before proposing anything. The canon and rejected list are not up for discussion. Verify the real state against the files, then tell me where we are in two lines.” The discipline that makes this work is updating the file when you close a session, not when you open one. At the end of a session, you still remember why you made the decisions. The next morning, you do not—and neither does the agent. The template is at the bottom. It costs nothing and it is a text file.

I built my agent fleet around one question: could a single assistant become a coordinated team that keeps useful work moving even when its main machine goes dark? I didn't want a pile of chatbots. I wanted specialists with clear jobs, a shared board, a second set of eyes, and a real failover drill. Here's how it works. THE STACK Cloud: GrokBot runs as Fleet Commander. It routes work, runs routines, and stays with me on my phone. Specialist GrokBots take focused research, design, and budgeting assignments. Mac Studio (M2 Max, 64 GB) with two Studio Displays: home base. It runs Codex (my Chief of Staff), Hermes (my local operator), ChatGPT Dot, and Hindsight shared memory. Hermes runs Qwen3.6-35B-A3B, a 4-bit quantization served by llama.cpp with a 256K-token context. With about 3B active parameters per token, it stays responsive on Apple silicon. NVIDIA DGX Spark (128 GB unified memory): my independent compute node. It runs Qwen3.5-122B-A10B in NVFP4, with about 10B parameters active per token, and the model can read images. It also hosts a backup Hermes operator. Windows PC with a GeForce RTX 5090: dedicated GPU capacity for image work. MISSION CONTROL Mission Control is a Kanban board on a private GitHub repository. Every card opens with the question, deadline, evidence links, and done criteria. Labels route ownership. An urgent label fires a webhook that wakes the reviewing agent, and a needs-me label is the one that pulls me in. Agents hand off, report, and raise concerns in card comments, so the work and its evidence stay together. The roles are simple. GrokBot owns routine board moves. Codex checks evidence and records verification. Hermes handles local execution and machine-level evidence. Dot watches for new work and changes. Hindsight holds the shared operating rules, and the jobs themselves stay on the board. A REAL DEADLINE CROSS-CHECK Right before a major application package went out, Dot ran an independent, read-only cross-check of the narrative, the budget justification, and the walkthrough across connected email and Drive. It found three places where the documents contradicted each other and quoted the exact sentences, so each conflict was easy to find. Fleet Commander fixed all three before submission. That's the job of a watcher: spot the mismatch early, show the evidence, and hand whoever owns the work a clear fix. THE FAILOVER DRILL I wanted to know what happens if the Studio's primary Hermes gateway pauses. On October 5, I ran a controlled, reversible soft-pause to find out. During the pause, Hermes on the Spark stayed active through its own Telegram connection and answered a one-shot request with the local Qwen3.5-122B-A10B NVFP4 model. From that worker, I listed a Mission Control issue, verified service-account access and a vault credential check without exposing a secret, and ran the Studio health probe. The probe flagged the Studio Hermes gateway as paused and reported the other checked Studio services as passing. So I had an evidence-backed result: the independent worker could respond, use its local model, read the work queue, and report the primary gateway's health during a real, reversible pause. THE PATTERN Give each agent a narrow job. Put the work on one shared board. Require evidence before anything counts as done. Then pause one piece on purpose and record exactly what the backup can do. That's how capable models turn into dependable operations. The fleet catches contradictions before they get submitted, keeps routine work moving, and shows me exactly where its limits are. I set the goal. The fleet does the work. The evidence shows what actually happened.