dax runs one pinned session that farms work out to subagents

dax says his work on his team's desktop app runs through a single pinned session he calls "gooey", and its job is to do none of the work itself. Everything gets handed to subagents. When a change is complicated enough, those subagents run in different worktrees (separate checkouts of the same repo, so parallel branches do not stomp on each other).

dax

@thdxr

X

because a lot is going on in parallel i often will ask "what do you need from me" so it tells me what is ready for review

The input is him using the app. As he runs into things he wants changed, he tells the session, and it dispatches. This is a step on from the setup he described earlier, where he kept one long-running session per project and delegated out of it.

The reporting channel is HTML

The part worth stealing is how results come back. dax says the session pops open HTML documents with screenshots showing before and after, and gives him options to pick from. For UI work that is the right format, because a diff does not tell you whether the thing looks correct and a paragraph of agent prose does not either. He looks at two images and chooses.

The second part is the prompt he falls back on when too much is in flight at once. He asks the session what it needs from him, and it answers with what is ready for review.

That inverts the usual problem with running agents in parallel. The bottleneck is not the agents, it is you keeping track of which of six things is waiting on a human. Asking the orchestrator to produce that list turns a swarm back into a queue you can work through in order.

This is one engineer's workflow on one app, not a benchmark, and dax has not said how many subagents typically run at once or how often the screenshots catch something he would have missed. What he is describing is a shape, a thin coordinating session that holds context and never edits files, with the actual work isolated in children.