# A practical review workflow for T3 Code threads

> Use T3 Code's stable release with a clear workflow for isolated agent changes, reviewing the complete branch, merging, and cleaning up finished work.

Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-10-18 | Topics: [AI](https://flaviocopes.com/tags/ai/) | Canonical: https://flaviocopes.com/t3-code-after-alpha/

A coding agent can finish its task while the change still needs substantial work from you. You have to read it, run it, and decide how it reaches the main branch.

[T3 Code's first stable Orchestrator V2 release](https://github.com/pingdotgg/t3code/releases/tag/v0.1.0) makes this a useful time to define that workflow. The release adds better tracking for child agents and puts workspace and Git controls in thread details.

I already have a [longer T3 Code guide](https://flaviocopes.com/t3-code/) covering installation and providers. Here I want to focus on taking one thread from a task to a reviewed change.

This is a proposed workflow, rather than a report of a new hands-on test.

## Start with a task you can review

Suppose an app lets users export invoices. We want the export button to show an error when the request fails.

Give the agent that behavior and its boundary:

```text
Handle failed invoice exports. Show an error beside the export
button and let the user retry. Keep the export format unchanged.
Explain how you checked both failure and success.
```

That is easier to review than asking the agent to “improve invoice exports.” You can open the page and verify the requested behavior without deciding whether an unrelated refactor was necessary.

## Choose where the files will change

T3 Code supports working in the current checkout or an isolated worktree. Choose according to the repository's rules.

For this blog, I keep agents in the existing checkout. A repository that permits isolated work can give each independent task its own worktree. A [Git worktree](https://flaviocopes.com/git-worktrees/) is another working directory attached to the same repository, usually on its own branch.

The figure follows the isolated option. The task gets a branch, then a review, then an integration decision. Closing the conversation comes after that decision.

Check what the environment shares before starting. Separate files can still talk to the same database. Two development servers can also compete for one port.

For our invoice example, use test data. If the export code updates invoice status, make sure the second environment cannot change real invoices. A worktree does not constrain the agent's network access or shell permissions.

## Review what the branch will introduce

When the agent finishes, ask it to list the files changed and explain any change outside the requested behavior.

Then inspect the full branch diff against its intended base. The last turn's diff can omit earlier edits that are still part of the change.

For our example, I would expect a small UI change and perhaps a focused check around the failed request. A new export format, dependency replacement, or database migration needs an explanation before proceeding.

Read the code around the change too. An error message may be correct in isolation but leave the button disabled forever. A retry handler may submit twice if the user clicks quickly.

These are behaviors to verify, even when the agent's summary sounds convincing.

## Use the changed flow

Open the invoice page in the environment containing the change. Try a successful export. Then make the request fail using the application's test setup or browser tooling.

Check that the message appears, the button becomes usable again, and retrying can succeed. Also check an account with no invoices. The UI should have a sensible result before the first export exists.

Record the checks in the thread. If something fails, send the agent the observed behavior and expected result. Keep the correction in the same task so the final branch contains one understandable change.

## Integrate, then clean up

Commit the reviewed files and integrate them through the repository's normal process. For a team that uses pull requests, include the behavior and verification in the description.

After integration, check that the intended commit reached the destination branch. Preserve any unfinished changes before removing an isolated working directory. Git's [worktree documentation](https://git-scm.com/docs/git-worktree) describes the checks around removal.

T3 Code can keep conversations and their linked pull requests together. Its stable release also distinguishes thread forking and context merging. Bringing a conversation's context back is a separate concern from integrating code through Git.

Before settling a thread, leave the result somewhere a future maintainer can find it: the pull request or commit should explain the fix and how it was checked. The next person investigating invoice exports should be able to understand the change without reopening an agent conversation.