Running agents like a small team

Six months ago I wrote that I wanted a fast model, small pieces of work, and a tight feedback loop. That changed more than I expected. Now I give agents much bigger pieces of work, often several at the same time, and most of my time goes into deciding what to build and reviewing what comes back.

A lot of the setup that made this possible is inspired by pstack, the Cursor plugin that Lauren Tan (poteto) published. The idea behind it is that working with agents looks a lot like managing an engineering team. They need clear playbooks, a real standard for what counts as done, and a way to work in parallel without turning the repository into a mess. I took that idea and adapted it to the way I work.

Playbooks instead of prompts

I do not write a long prompt for every task anymore. My workflow skill looks at the request and picks a playbook for the kind of work it is: a bug fix, a feature, a refactor, a performance improvement, or an investigation. Each playbook has its own idea of what done means. For a bug fix, for example, the agent first has to reproduce the failure and show it to me, and only then fix it and show that it is gone, while performance work starts with a measurement so there is something real to compare against at the end.

This makes the agents much more predictable, because they are following the same process I would follow, and I do not have to explain it again every time.

Proof, not a passing build

The most important rule in my setup is that a passing typecheck or build does not prove that something works. A check only counts if it would have failed with the bug still there. For UI changes, the agent has to run the real app and take screenshots before and after, on desktop and on mobile, and it has to look at them itself before sending them to me. When it reports back, anything it could not verify is written down as a gap instead of being quietly skipped.

This is what lets me trust bigger pieces of work. I still read most of the code, but with changes this big, the evidence is what tells me it really works.

Paseo and named profiles

All of this runs in Paseo, an open-source app for running coding agents on your own machine. A small background service on my Mac starts and manages the agents, and I can connect to it from the desktop app, the command line, or my phone. The agents are the same tools I already pay for, like Claude Code and Codex, and my code stays on my Mac.

I use it for two reasons. The first one is that models change so fast that I want switching between them to be as easy as possible. In Paseo I save named profiles, where each profile is a provider, a model, and its settings, with a name and a short note about what it is good for. When a new model comes out, I add a profile or pick a different one, and my instructions, skills, and workflow stay the same. The second reason is the mobile app, which I love. From my phone I can start a task, check how an agent is doing, and approve a permission prompt, while the work keeps running on the Mac.

One model, for now

For a while I split the work between several models. Astra 6 and Sol 5.6 did most of it, and DeepSeek 4.1 Flash took the cheap and fast tasks. Recently I moved to Opus 5.5, and now I use it for everything, both at my job at Buffer and on personal projects like this site. If that changes again, switching back is one profile away.

Work lanes

For bigger batches of work, I split the job into lanes. Each lane is its own Git worktree in Paseo with only one agent writing to it at a time, and it can hold a whole stack of pull requests. A coordinator agent stays read-only. It writes a brief for each lane, launches the workers, and reviews what they deliver against the original requirements, including the full diff and the evidence. The rules, the queue, and my decisions live in files, so if an agent crashes or I lose context, nothing important is lost.

Work lanes are a hack in a way. Cloud agents are not available for the kind of work I do, so I built the closest thing I could on my own machine. It is not as clean as a real cloud setup, but it makes the most of the resources I have locally.

I pick what goes into each batch and make the decisions the agents cannot make on their own, and then I review what comes back. Some days it feels like running a small team.

What stayed the same

I still want to be in control of the work. Six months ago I did that by checking every small piece myself, and now I do it by deciding the scope and never accepting a result without real proof. The model is also still a replaceable part, so if a better one ships next month, I only need to change a profile and everything else stays.

I do not think this will last for long either. It is the first one that lets me take on work of this size, though, and I am curious where it goes next.