An AI Agent Running Nested Claude Code, Live on Twitch

A single AI agent on a Mac Mini spun up copies of itself, handed them build orders, and streamed the whole thing to Twitch so viewers could request software in chat and watch it get built live. It is a wild demo. But strip away the glitch filters and the live audience and what is left is a pattern quietly useful to ordinary businesses: one agent that manages other agents, keeps a queue of work, and runs two workers at once, one building and one testing. I am Madhuranjan Kumar, and rather than just explain the demo, I want to walk through how a real business would adopt this same pattern, told as the journey of one auto repair shop over a few months, with illustrative numbers so you can see the shape of the payoff.

The starting point: a wish list nobody had time to build

The shop I have in mind is a three bay independent with a service writer at the counter and an owner who does everything else. Like most small operations, it had a mental list of small software it always wished it had and never got. A quick estimate calculator so the service writer could quote labor and parts at the counter without a spreadsheet. A little page that texts customers when their car is ready. A cleaner way to pull the week's numbers into one screen. Each of these was too small to justify paying an agency four figures to build, and too fiddly for the owner to make between oil changes. So the list just sat there, quietly costing a few hours a week in manual workarounds and missed follow ups.

That is the exact gap the nested agent pattern fills. In the demo, the top level agent read requests from Twitch chat, decided which were real projects, and dropped them into a JSON queue for the nested terminals to build. For the shop, the chat feed becomes a shared note where the owner types the tools they wish existed. The mechanism is identical. A request comes in, it gets queued, and a worker picks it up. Before the shop wrote a single tool, the only thing it needed was that list and a machine that stays on.

Chapter one: standing up the orchestrator on a machine that never sleeps

The first real step was infrastructure, and it was smaller than it sounds. The demo runs on a Mac Mini because everything works locally, which keeps the loop fast and responsive. The shop already had an old desktop in the back office that stayed powered on. That was enough. On it we ran one top level agent as the orchestrator, the equivalent of the manager that reads the queue and assigns work.

The tool that makes the nesting work is tmux, a terminal program that lets the top agent open and control several terminals stacked below it on the same machine. It was chosen in the demo because it is fast and local, and that reasoning holds for a business too. The nested terminals were set to run with skip permissions turned on, so they build without stopping every few seconds to ask for approval. That single setting is what makes the loop autonomous rather than a thing the owner has to babysit. In week one, nothing shipped. The whole point was to get the orchestrator reading a queue and able to open one worker terminal reliably. Boring, but it is the foundation the rest sits on.

Chapter two: the first tool ships in an afternoon

By week two the shop was ready to build. The owner added one line to the shared note: a labor and parts estimate calculator the service writer can use at the counter. The orchestrator turned that line into a queued task and assigned it to a nested terminal. That terminal wrote the tool as plain HTML and a bit of logic, the same way the demo shipped its builds as plain front end code.

Here the parallel design earned its place. The demo ran two nested terminals at once, one writing code and one testing, and the shop copied that exactly. While the first terminal built the calculator, a second stood ready to test it against a handful of real jobs, a brake pad replacement, an oil change, a diagnostic hour, checking that the totals matched what the service writer would have worked out by hand. The estimate tool that used to live in a fragile spreadsheet became a clean page in a single afternoon. Call it four hours of agent time and about thirty minutes of the owner reviewing the result. The first item was off the wish list.

Chapter three: the queue turns into a shelf of tools

This is where the pattern compounds, and it mirrors how the demo shipped one thing after another, a spinning particle galaxy, then bouncing balls, then a viewer requested snake game that ended up playing itself. None of those were one polished engineering project. They were a series of small, real builds knocked out fast. The shop worked the same way.

Week three, the owner queued the customer ready text page. One terminal built a small page that sends a message when a car is finished, and the second terminal tested it against a few sample numbers before it ever touched a real customer. Week four, a dashboard that pulls the week's job counts and revenue into one screen. Week six, a simple intake form that captures the customer complaint and vehicle details so nothing gets lost between the phone and the bay. Each build followed the same loop: a line in the note, a queued task, one terminal building while another tested. When the shared note ran empty, the orchestrator did what the demo did during quiet chat and fell back to a few preset improvements, tidying earlier tools rather than sitting idle.

By the end of the second month the shop had five custom tools that fit the way it actually worked, instead of generic software it had to bend itself around. The owner reviewed each finished tool, kept the ones that helped, and tossed the couple that missed. That review step is important. The agents produced drafts fast, but a human decided what stayed.

The numbers, framed honestly

Let me put illustrative figures on the journey, because the point of a case walkthrough is the shape of the return, not a promise. Before any of this, the owner and service writer lost roughly six hours a week to the manual versions of these jobs, the spreadsheet estimates, the phone tag over ready cars, the Friday scramble to add up the week. Across a month that is around twenty four hours. The build phase cost real attention, maybe two to three hours a week of the owner queuing tasks and reviewing output over about six weeks.

Once the tools were in place, the weekly six hours dropped toward two. The estimate that took the service writer several minutes per quote became near instant. The ready car texts stopped falling through the cracks, which quietly recovered a few pickups a week that used to sit until the next day. The clean intake data flowing off that new form is exactly the kind of structured customer record that makes a real CRM and website stack worth having, because follow up is only as good as the data feeding it. None of these numbers are guaranteed for your shop. They are the illustrative arc of what happens when small tools stop being wishes and start being built.

Chapter four: the mistakes the shop made and fixed

No honest walkthrough skips the missteps, and the shop made a few that are worth passing on, because you will be tempted by the same ones. The first mistake was ambition. Early on, the owner queued a big, vague request, something like build me a full shop management system. The nested terminals churned, produced a tangled half finished mess, and burned time. The fix was to copy the demo's actual rhythm, which never asked for one giant system. It shipped small, self contained builds, a particle galaxy, then a snake game, each a single clear thing. The shop relearned the same lesson. Small, specific, testable tasks succeed. Big, fuzzy ones fail. Break every wish into the smallest useful piece before it goes in the queue.

The second mistake was trusting output without the test loop. On one early build the owner accepted a tool that looked right but had a subtle math error in an edge case, which only surfaced when a real quote came out wrong at the counter. That is exactly why the demo ran two terminals, one building and one testing, in parallel. The shop had been running only the builder. Once it restored the tester as a permanent second worker, checking each tool against real sample cases before it went live, the quality problems largely stopped. The parallel design was not a flourish. It was the quality gate.

The third lesson was about the fallback tasks. Left with an empty queue and no fallbacks, the orchestrator would sometimes sit idle or, worse, invent low value busywork. Adding a short list of preset improvements, tidy this tool, add input validation to that one, gave it something genuinely useful to do in the quiet gaps, mirroring how the demo fell back to preset builds when Twitch chat went silent. An idle agent is wasted spend. A fallback list turns idle time into maintenance.

What the demo teaches that the shop absorbed

The valuable idea was never the Twitch stream or the ffmpeg glitch filter that gave the broadcast its hacker look, clever as those were, right down to Claude Code writing its own streaming command. The valuable idea was orchestration. One agent managing a queue of build requests, running two workers in parallel, and always having a fallback task so the machine never sits idle. That is how a non technical owner gets a steady drip of custom tools without hiring a developer for each one.

There is a broader lesson for how the shop spends its energy elsewhere, too. The same instinct that says small internal tools are worth building applies to the marketing side, where a queue of small, tested experiments beats one big bet, whether you are rotating creatives on Facebook and Instagram ad campaigns or tuning bids on Google Ads. Build small, test in parallel, keep what works, discard the rest. The auto shop learned that rhythm from a Twitch demo and applied it to its back office.

The move to make if this is your business

If you keep a mental list of small tools you wish existed, this pattern is for you, and you will never touch Twitch to use it. Start with a single agent on a machine that stays on, and give it a written list of tasks instead of a chat feed. Once that is comfortable, use tmux to let it open a second nested terminal, so one can build while the other tests. Turn on skip permissions inside the nested terminals so they do not stop at every step. Keep a plain queue so the agent always knows what to build next, and add a couple of fallback tasks so it has something useful to do when the list is empty.

The building blocks, a machine that stays on, tmux, a queue, parallel terminals, and skip permissions execution, are all things you can wire up today, and that is exactly why this matters. You can absolutely learn this yourself, and many owners enjoy the process. But if you would rather have a working setup handed to you, tuned to the specific tools your business actually needs, that is the kind of thing an expert can stand up for you in an afternoon so you skip the trial and error and go straight to the shelf of tools that fit your shop.