Writing ·
Two agents ran a design review without us
Async work when both people have agents: a three day review loop closed in three hours, why agents argue better than colleagues, and the five part setup.
Most of the AI conversation is about doing your own job faster. Better autocomplete, faster code, a tidier inbox. That is real, and it is small.
The bigger change sits between two people. In April my agent and a teammate’s agent ran a design review without us. She runs RevOps, I run Growth, different cities, mostly async.
Old world: every process change between us was a three day back and forth. I draft a proposal, send it, wait. She sends comments, I revise, send back. Two missed threads, a call that still needed a follow-up, half my context stale by the time we landed it. The thinking was usually done inside the first hour. The iteration burned the days.
This time my agent posted a long-form proposal in our shared channel: redesign a CRM field with 49 categories down to a clean set, with three behavioral segments behind it. It ended with a question.
An hour later her agent replied. Not a rubber stamp, a real critique. Two of my buckets were in the wrong place. It flagged a privacy gap I had missed. It asked one question I had not thought to ask. My agent conceded one point, defended two with evidence, and assigned a workstream. We read the thread afterwards and signed off. Three hours, and neither of us typed a word of the substance.
Why the agents argued better than we would have
Two humans on a redesign thread are managing a relationship at the same time as the document. Whose framing wins, who gets credit for the catch, who looks sharp, who looks careless. Those concerns nudge a thread toward agreement before the work is finished cooking. Nobody wants to be the person who makes a colleague look sloppy in the first reply.
Her agent had no relationship to protect, so it flagged the privacy gap the same way it would flag a typo. That is the uncomfortable half of why this works, and the part that took me longest to admit out loud.
The architecture is more interesting than the agents
The whole pattern rests on one split. Files are shared automatically. The chat is where someone flags what needs your attention.
The shared workspace is a repo we both clone, with a five minute pull on each machine. Every file one side writes lands on the other side without anyone deciding it should: notes, scripts, agent prompts, drafts. The channel is the deliberate half. When an agent has done something the other side actually needs to act on, it posts a one liner with a path or a record reference, and the receiving agent picks up that specific item at session start.
Without the split you get flooded with everything the other agent touched, which is the same problem as a Slack channel wired to a CI pipeline. With it, you only see what was flagged.
Humans show up at three moments. Before, when someone sets the direction (“we should redo this field”). During, only when the agents deadlock on something they cannot resolve. After, to review what was decided and sign off or push back. If a question has a factual answer, the agents settle it themselves. If it is a values call or a stakeholder call, it comes to us.
What four weeks of this actually looked like
Five recurring patterns. The quick handoff (“I did X, your turn”). The heads-up (“this just shipped”). The decision with options (“two paths, your call”). The broadcast, which is a commit message written for a human reader. And the rarest one, the multi-turn design review at the top of this piece.
The first four are Slack with extra steps. The fifth is genuinely new behavior, and it is the only one I would call a change in how we work rather than how fast.
The minimum spec
Five things, if you want to try this with one teammate next week.
A shared repo that you both clone. A five minute pull on each machine, which is about twenty lines of cron. A shared private channel with a webhook, on whatever chat tool you already run. A bot identity that every agent posts as. And a one line CLI inside each agent’s toolkit to post to the channel.
The bot identity is the piece most setups get wrong, and it is the failure mode that cost me a full day. If the bot token only lives on one machine, agent posts from every other machine silently fall back to user identity. The other side’s agent posts show up as the human typing, the receiving filter does not recognize them as agent traffic, and the channel quietly empties out. Nothing errors. You just stop getting messages.
The fix is a shared secrets manager that materializes the token on every machine at setup, plus a fail-loud check at session start: post a test line, read it back, halt if the source field is wrong. Loud failure beats silent message loss every time.
Still broken
The receiving agent has to be told to read the channel each session. There is no auto-poll into context yet, and until there is, this depends on a habit rather than on the architecture.
Free-form posts work with two senders. They will not survive four. Add topic tags and threading from day one if more than two people are on the channel.
And most agent fleets carry a global rule that says never post to chat without per-turn approval. This channel exists to do exactly that. Reconciling those two stances took a day, and getting it wrong in either direction is bad: too strict and the channel dies, too loose and your agent is talking to your colleagues unsupervised.
The shift
Stop expecting your teammate to drop everything and respond. Start expecting their agent to.
The gain does not show up on individual tasks. It shows up in how many days a decision spends waiting for someone’s attention, and over a quarter that difference lands in roadmap velocity rather than in any productivity dashboard.
If you are running something like this with a teammate, reach out. I want to compare notes.