Running AI Coding Agents on Client Work: A Playbook for Agencies

Published July 27, 2026 · by the AQ team

Agencies and dev shops are adopting coding agents faster than almost anyone, because the economics are irresistible: an agent that does a day of implementation in an hour changes what a fixed-bid project costs to deliver. But client work adds constraints that solo-developer tooling ignores. Client code must stay isolated from other clients. Non-technical stakeholders need to see progress without a deploy ceremony. And every dollar of metered AI usage on a client project comes straight out of your margin or lands awkwardly on an invoice.

This guide covers the three problems in turn, the common workarounds, and how AQ was built to handle each one.

Problem 1: one agent setup, many clients

An agent working on client A's repository must never see client B's code, credentials, or environment. On a single laptop, that separation is a matter of discipline: separate checkouts, separate environment files, and hope. It gets harder with contractors, and harder again when several projects are active in the same week.

The clean pattern is one isolated workspace per engagement. In AQ, every workspace is an isolated git worktree on a VM, so client A's sessions, files, and environment never share state with client B's. Repositories connect per workspace, agents sign in per user, and closing an engagement means closing its workspaces. If a client requires that their code never leave infrastructure you (or they) control, the workspace can run on your own VM, or on one inside the client's cloud account.

Problem 2: clients want to see progress, not read about it

The status-update treadmill exists because clients cannot see work in progress. Screenshots go stale, staging deploys are ceremony, and "we're about 70% done" convinces nobody. Meanwhile the actual work, an agent building the feature in a terminal, is invisible to exactly the person paying for it.

Two AQ features were built for this. Every workspace has a live preview of the running app, shareable as a link, so a client clicks and uses the feature as it exists right now. And guest review links let a client leave comments on the preview without an account, comments that can be routed straight to the agent as instructions. The feedback loop that used to be a Friday call becomes a Tuesday-afternoon link.

Problem 3: metered AI billing eats agency margin

Most AI development platforms bill agent work through platform credits, priced per task or by effort. For a product team, that is a cost line. For an agency, it is worse: iteration on client work is your core activity, every round of "make the header more like the mockup" burns metered credits, and you either absorb the spread or itemize a fuzzy AI line on invoices. Client work is exactly the usage pattern that per-task pricing punishes.

The alternative is to own the agent relationship. Your engineers already carry Claude or OpenAI subscriptions; agents like Claude Code and Codex run on those subscriptions directly. AQ never meters or marks up model usage: the agents sign in with your accounts, the hundredth iteration costs what the first did, and AQ charges a flat seat price for the workspace. Your AI cost per project becomes a known quantity you can price into bids instead of a variable you discover at month end. (Coming from a credits-based tool? See how the models compare: AQ vs Replit and AQ vs Lovable.)

The handoff problem, solved by accident

Agencies live on handoffs: between engineers and contractors, across time zones, and past the end of engagements. Because AQ sessions run in tmux on an always-on VM, a workspace is a persistent place rather than a state trapped on someone's laptop. The contractor in another time zone opens the same workspace, with the same terminal scrollback and the same running preview, and continues where the agent left off. When someone leaves the project, nothing leaves with them.

A working setup, end to end

• One workspace per client engagement, named for the project, with that client's repository connected and its environment configured once.
• Engineers and agents work in the open. Anyone on the team can open a colleague's workspace, watch the agent, and take over when needed; nobody reconstructs context from a pull request description.
• Clients get a preview link, and for review rounds, a guest link where their comments land in front of the team and can be handed to the agent verbatim.
• Billing stays clean. Seats are flat, model usage rides subscriptions you already pay for, and the AI line on your invoice is whatever you decide it should be, not whatever the meter said.

What this looks like commercially

The agencies moving first are not selling "AI development" as a novelty; they are quietly compressing delivery time on ordinary engagements and keeping the difference. The tooling requirement for that play is exactly the list above: isolation a client would sign off on, visible progress that shortens approval cycles, and an AI cost structure that does not scale against you as you iterate. That is the workload AQ was built for.