The Work, Review Workflow
How to use a second Claude Code session as a dedicated reviewer to catch errors, improve output quality, and eliminate confirmation bias.
--- title: The work-review workflow for Claude Code author: FractionalSkill description: Most people use AI agents like a solo contributor. The operators getting the best results run them like a team: one agent works, a separate agent reviews. ---
The work-review workflow for Claude Code
Most people who use multi-agent systems think about parallel execution. Two agents running at the same time, splitting tasks down the middle. That model works in some situations.
But there's a different pattern that gets overlooked. Sequential review. One agent does the work. A separate agent, with no knowledge of how that work was done, checks it. Same instinct as sending a pull request to a colleague who wasn't in the room when you wrote the code.
This is the work-review workflow. It's simple to set up, and it catches errors that a single agent will almost always miss.
---
Why a single agent misses its own mistakes
When you ask Claude to build something and then ask it to review that same output, you're working against how context windows operate.
The agent that completed the task carries its entire reasoning history. Every assumption it made, every shortcut it took, every decision about what to check and what to skip: that's all baked into its context. When you ask it to review its own work, it's not approaching the output with fresh eyes. It's looking at the result through the same lens that produced it.
This is the same reason engineers don't review their own pull requests. You've already mentally validated the approach while building it. You'll miss edge cases you never considered in the first place.
A second agent doesn't have that baggage. It sees only the deliverable. No message history. No context about how the work unfolded. That clean slate is the entire value of the pattern.
---
How to set up two Claude Code sessions
The mechanical setup takes about 30 seconds.
Open two terminal tabs. In each one, navigate to your project folder and start a separate Claude Code session by typing claude. You now have two independent agents with no shared context.
# Tab 1 - work agent
$ cd ~/clients/acme-project
$ claude
# Tab 2 - review agent
$ cd ~/clients/acme-project
$ claude
Both sessions point at the same files. Neither session knows what the other has done.
Label them mentally before you start. Tab 1 is the work agent. It gets the task. Tab 2 is the review agent. It only ever sees the output, never the instructions or the reasoning that produced it.
> One codebase, two perspectives. Both agents read from the same files on disk. When the work agent edits a file and saves it, the review agent reads the updated version. You don't need to sync anything manually.
---
Running the workflow on a client deliverable
Here's how this plays out in practice across a typical fractional engagement.
Step 1: Assign the task to the work agent. Give it a clear, specific instruction. "Update the Q3 pipeline report to reflect the two new client wins from the Meridian account." The work agent reads the relevant files, makes edits, and reports back when it's done.
Step 2: Switch to the review agent without describing the task. This matters. Don't explain what the work agent was supposed to do. Don't summarize the changes. Point the review agent at the file and ask it to check for accuracy, completeness, or whatever criteria fit the deliverable.
You [to review agent]: Review the updated Q3 pipeline report.
Flag any data inconsistencies, missing entries, or formatting
issues you find.
The review agent reads the file cold. It has no expectation about what should be there, which makes it much more likely to catch what's actually wrong rather than what you expected to be wrong.
Step 3: Relay findings back to the work agent. When the review agent returns issues, copy those findings over to the work agent. The work agent has the full task context in its history, so it can locate and fix the specific problems faster than the reviewer could. It knows exactly where it made each decision.
Step 4: Confirm the fix with one more review pass. Send the review agent back to check the corrected file. This second pass is quick. You're just confirming the identified issues are resolved, not running a full audit again.
| Step | Agent | Action |
|---|---|---|
| 1 | Work agent | Executes the task |
| 2 | Review agent | Audits the output cold |
| 3 | Work agent | Fixes the flagged issues |
| 4 | Review agent | Confirms corrections |
---
Where this pattern fits in your practice
The work-review workflow isn't necessary for every task. For quick, low-stakes edits like reformatting a doc, updating a single data point, or renaming files, a single agent is sufficient.
Deploy the two-agent review pattern when the stakes of a mistake are higher than the cost of a second pass.
Client-facing deliverables. Board decks, financial summaries, competitive analyses, quarterly reports. Anything a client will read without you in the room to clarify errors deserves a second agent's eyes.
Data-heavy documents. Numbers are where single agents make quiet mistakes. A transposed figure, a missing row, an incorrect total. The review agent isn't reading for narrative quality. It's reading for factual consistency, and it's reliable at that.
Code and structured outputs. If you're using Claude Code to generate scripts, automations, or structured data files, the review agent can run a logic check on the output before you deploy it to a client environment.
> This mirrors how mature engineering teams work. The discipline of never shipping your own unreviewed work, even when you're confident, is what separates practitioners who rarely have to explain mistakes from those who spend Monday mornings cleaning them up.
---
Connecting this to your GitHub workflow
If you're already using the Claude Code GitHub integration, you may already be running a version of this pattern without realizing it.
When you open a pull request, the Claude Code GitHub app can review that PR automatically. That reviewer has no knowledge of the working session that produced the code. It reads the diff cold, the same way a human reviewer would.
The two-terminal version described here is the same idea, deployed locally before the PR stage. Think of it as a pre-review that catches issues before they reach the automated reviewer, or before a client stakeholder opens the document.
More review checkpoints, not fewer. The goal isn't to create friction. It's to catch mistakes at the cheapest possible moment, before they cost you time, credibility, or a client conversation you didn't want to have.
Running two agents sequentially costs minutes. The deliverable quality improvement is consistent. That's the kind of workflow that compounds across a multi-client practice.