Team Workflows for Coding Agents: Who Runs, Who Watches, Who Reviews

Published August 25, 2026 · by the AQ team

A team workflow for coding agents is a set of explicit decisions about four things: who runs which agent on which task, where those agents execute, who can see and steer a session while it is running, and who reviews and merges the result. Teams that skip these decisions do not end up with a bad workflow, they end up with no workflow: each engineer runs agents alone on a laptop, reviews their own agent's output, and merges it, and the team learns nothing from any of it. This guide walks through each decision with the vendor-neutral options as of August 2026, then covers where a shared harness helps.

The default is solo, and the data shows it

Left alone, agent adoption does not become teamwork. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. The same analysis found most projects concentrated agent use in a small minority of contributors.

That pattern is the path of least resistance: every agent CLI is a single-player tool by default, running in one person's terminal under one person's account. Making agent work visible to a second human takes deliberate structure. The four decisions below are that structure.

Decision 1: how work gets assigned to agents

The strongest predictor of a functional team workflow is whether agent tasks flow through the same tracker as human tasks. When agent work starts from ad-hoc prompts in private terminals, nobody can answer "what are the agents working on right now?" When it starts from tickets, everybody can.

The vendors have converged on the same model. Linear's agent support, as of August 2026, keeps issues assigned to humans and delegated to agents, so accountability never transfers to software. GitHub's Copilot cloud agent works the same way from the other end: assign an issue to Copilot and it opens a pull request for human review. OpenAI's Codex cloud tasks start from the web, the IDE, or a bot mention on GitHub, and every path ends in a PR a human reviews.

The practical norms that fall out of this:

• One ticket, one agent task. An agent gets a scoped issue with acceptance criteria. Work that cannot be stated as a ticket is not ready for delegation.
• The assignee owns the outcome. Whoever the ticket names is responsible for what the agent produces, including deciding when to stop it and do the work by hand.
• Write the routing rule down. Which tasks go to agents first (test coverage, migrations, well-specified bugs) and which never do (auth, billing) should be a team decision, not sixty individual ones.

Decision 2: where agents run

Laptops are where team workflows go to die: an agent on a personal machine is invisible to everyone else and dies when the lid closes. The moment two people need to see the same session, or one person runs more than a couple of agents in parallel, execution has to move somewhere shared and persistent: a VM the team controls, or a vendor's cloud environment. The guide to always-on coding agents covers those tradeoffs in depth.

Wherever agents run, isolation between tasks is non-negotiable. Two agents in one checkout will trample each other's files; the standard fix is one git worktree or clone per task, each on its own branch. Vendor clouds enforce this by construction (Copilot's agent, for example, can only push to branches it creates). On your own infrastructure you script it, or use a harness that does it for you.

Decision 3: who watches while agents run

Between "assigned" and "PR opened" there is a stretch of time where an agent is making decisions nobody asked it to make. Teams handle this stretch in one of three ways, and the choice matters more as runs get longer:

Shared visibility is what separates a team workflow from parallel solo workflows. It enables the two habits that make agent fleets manageable: spot checks (a teammate glances at a session and catches a wrong turn early) and handoffs (the person ending their day passes live sessions to a teammate in another timezone instead of killing them). A handoff needs three things stated explicitly: what the agent has done, what it should do next, and what to decide if it stalls. Teams that hand off through prose in Slack lose context; teams that hand off a live, inspectable session lose much less.

Decision 4: who reviews, and what counts as review

This is where the 79 percent number bites. Whoever shaped an agent's output through prompts and course corrections has already accepted the code's framing, and is the worst-positioned human on the team to catch its blind spots. The fix is old and boring: the person who drove the agent does not solo-approve the result. A second human reviews, exactly as if a new teammate had written it.

To keep that second human's attention worth spending, layer the gates so cheap checks run first:

1. Deterministic gates. Type checks, linters, tests, and security scanners run before any human looks. An agent PR that fails CI goes back to the agent's driver, not to a reviewer.
2. Provenance in the open. Label agent-authored PRs as agent-authored, and link the ticket. Reviewers calibrate differently when they know what they are reviewing, and the team can measure agent outcomes later. Verifying AI coding agent work covers what to actually check.
3. A human merges. Whatever assists the review, the merge click belongs to an accountable person. Every major vendor has landed on this line: Copilot's agent PRs require independent human approval, and Codex cloud tasks end in a PR a human merges.

Write the conventions down where agents read them

Norms only stick if agents themselves follow them, and the mechanism is now standardized: an AGENTS.md file in the repository, a cross-vendor convention (stewarded by a Linux Foundation project as of August 2026) that Codex, Cursor, and most other agents read automatically, with CLAUDE.md as Claude Code's equivalent. Put the team's rules there: branch naming, test expectations, what agents must never touch, how to format PRs. A convention in a wiki is advice; a convention in AGENTS.md is behavior. Running multiple agent brands? Keep AGENTS.md and CLAUDE.md in sync.

Start the rollout smaller than feels natural: one workflow (say, ticket-to-PR on well-specified bugs), a handful of engineers, two weeks, then a retro that edits the written norms. The guide to getting your whole team building with AI agents covers the adoption arc.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ is decisions two and three answered by default, so a team only has to argue about assignment and review norms.

Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on the team's VM, streamed live to the browser: sessions survive a closed laptop and resume from any device, which makes the timezone handoff a matter of opening a link. Teammates open the same workspace and watch the same live session; typing into someone else's terminal is delegated, with the owner approving a control request in one click while keeping their own input. Workspace visibility is owner-managed: team-visible by default for shared work, or private and shared with specific people. Each workspace gets its own isolated git worktree on a branch named ai/{id}-{slug} with dependencies installed automatically, so parallel tasks never collide, and agents commit, push, and open PRs under per-user GitHub auth, with PRs tracked per workspace. Assignment can flow straight from the tracker: label a Linear issue ai-task and a workspace appears, status syncs both ways, ownership follows the assignee, and a human starts the agent (nothing auto-launches). Each engineer signs into the CLIs with their own Claude or OpenAI account, and AQ never marks up model usage.

Two plans: Free is a personal sandbox for one person (AQ creates a private machine in an isolated network, nothing to install, no time limit), and Team is $50 per user per month in early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, with the rate locked for your first 12 months. Inviting a teammate costs nothing until they accept and join. If you are still comparing the landscape, the roundup of AI coding tools for team collaboration and the overview of multiplayer coding agents map the options.