How AQ works

Published July 10, 2026 · by the AQ team

AQ is the multiplayer workspace 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. This page explains the moving parts. It is a concepts overview, not an API reference: everything here is what you see in the product.

Workspaces: one task, one isolated worktree

The unit of work in AQ is a workspace. Creating one (manually, from a Linear issue, or from a GitHub PR or branch) gives the task its own git worktree: a separate working directory and branch (ai/{id}-{slug}) that shares the repo's history but never collides with anyone else's files. AQ installs dependencies in the worktree, can rebase it onto main on demand, and tears it down when the workspace closes. Ten agents on ten tasks means ten worktrees, zero stepping on each other.

Terminals: real CLIs, sessions that persist

Agents in AQ are not a proprietary model wrapper. A workspace runs the real agent CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, and plain shells) inside persistent terminal sessions on your infrastructure, streamed live to the browser. Close your laptop and the agent keeps working; open the workspace from your phone and the same session is there. Each teammate signs into the CLIs with their own accounts from Settings, so the team's model spend stays on the team's own subscriptions and AQ never proxies or marks up model usage.

Multiplayer: the workspace is a shared place

Any teammate with access can open the same workspace and see the same live terminal, the same editor, the same preview. That changes what "handoff" means: instead of describing what the agent did in Slack, you send a link and your teammate is standing in the session. Workspaces are public to the team or private, and private workspaces can be shared with specific people. Guest links go further: someone outside the team (a founder, a client) can view a workspace preview without a seat and without the workspace going public.

Previews and comments: review behavior, not just diffs

A workspace can run its dev server and expose it as a live preview with a shareable URL. Reviewers pin comments directly on elements of the running app (with screenshots and attachments), draw regions, and comment from mobile. Any comment can be handed to the agent as a follow-up prompt with one action: see an off-center button, pin a comment on it, send it to the agent, watch the fix land in the same preview.

Linear and GitHub: intake and exit

Work enters AQ from wherever it already lives. With the Linear integration, labeling an issue ai-task creates a workspace in the team's sidebar and moves the issue to In Progress; status syncs both ways, and workspace ownership follows the Linear assignee. AQ deliberately does not auto-launch agents from labels: a human opens the workspace, starts the CLI, and steers. On the exit side, agents commit, push, and open pull requests using each user's own GitHub access, and AQ attaches every PR to its workspace, tracking opened, merged, and closed.

Runners: your infrastructure, your rules

Agent execution happens on a runner: a dedicated AQ-managed VM (included with the paid plan, provisioned automatically in its own isolated network), or a VM you connect from your own cloud account. Either way the code, the worktrees, the agent sessions, and the CLI credentials live on that machine, not on shared infrastructure. Runner health is visible in the product, the installer preflights its own requirements, and aq-runner doctor diagnoses a misbehaving VM.

What AQ is not

• Not an IDE plugin. AQ runs in the browser and complements whatever editor your team uses.
• Not a model reseller. Your agents, your accounts, your spend.
• Not an autonomy play. AQ assumes a human is steering. The product makes steering (and reviewing) a team activity instead of a solo one.