Oizom builds a separate stack for every ticket so one developer can keep several tickets moving with one agent

The author, who leads Oizom's software team, says the parts that make this work are "mostly scripts, not AI" ^[1]. The diagnosis came first. "The agent was fast. The developer was the bottleneck," the author wrote ^[2].

The answer is to isolate by ticket. Oizom's Envizom platform spans separate repos for hardware drivers, a simulator, a backend and a frontend, and getting a working local setup used to take a new developer days ^[4][5]. Orch now does that setup for every approved ticket ^[8]. Each developer has a devbox on the dev VM, with VS Code in the browser and orch running inside it, and each orch picks up only tickets assigned to that developer's paired agent ^[7]. The board is shared. Machines and agents belong to one person each ^[7].

The database copy is the decision I like most. "If an agent does something silly to the database, it did it to a copy," the author wrote ^[9]. The copy also gives the agent a place to build fixtures. In the demo, the follow-up asked it to "set up 8 test cameras on this device", and the agent created that data in the ticket's own copy ^[12].

Isolation at this level costs running processes. The post's scheduling example has one ticket sitting in QA for a week while three others ship ^[15]. Four live tickets means four workspaces, each with four services and its own database copy: up to 16 service instances and four database copies at once ^[1]. The post says a developer can have "several" tickets in flight ^[10]. Now that the agent is the fast part, that number depends on how many previews one person can test and answer in a thread, and on how many full stacks the dev machines can hold ^[11][10].

The stored prompts are the second payoff. The ticket thread is the prompt history, and the author wrote that reading it to coach people "has been more useful than any prompting guide" ^[13].

The push step keeps agents out entirely ^[16]. I think that is the right split, because committing, merging and opening pull requests across several repos is a fixed sequence that needs no judgement from a model.

The order of that sequence has a cost. Orch merges the current dev branch into the ticket branches only after the developer has approved the preview ^[16][11]. A ticket that waited a week in QA ^[15] ships combined with whatever reached dev that week, and its preview never ran that combination. The listed steps also go straight from opening pull requests to merging them, even though review and CI are on the post's list of practices that agents must not weaken ^[16][14]. The supplied text ends mid-list at "posts", so it does not show where those gates sit ^[16].