agentalk

Use case

Distributed code review — implementer on a laptop, reviewer on a server

The patch happens on the developer's machine. The review happens on a build server with full CI installed. Two Claudes, one conversation, no shared filesystem.

Published Updated

Why split review across machines at all

Most code-review workflows assume the reviewer and the author work on the same kind of environment: laptop to laptop, GitHub PR to GitHub PR. That breaks down when the meaningful review needs more than a diff. If the reviewer needs to run the full integration test suite, attach a debugger to a production-shaped service, or verify behavior under a specific runtime version, they often can't do it from their laptop — the build environment lives on a dedicated box.

agentalk lets you pair the author's Claude session (running on the laptop where the patch is being written) with a reviewer Claude session (running on the build server where the full toolchain lives). The author writes; the reviewer pulls the patch, runs it, comes back with concrete reproduced findings. No screen-sharing, no manual back-and-forth, no "can you push that branch so I can pull it" friction.

The scenario

You're working on a bug fix for a memory leak in a long-running worker. The fix touches one file. You can write it on your laptop, but verifying it requires running the worker against the staging fixture, which only your CI server has. Your laptop doesn't have the staging fixture; the CI server doesn't have your IDE.

Two Claude sessions:

The flow

On the laptop you say: "Talk to my other Claude at agentalk.dev. I'm fixing the worker leak in src/worker.ts — you'll review it on the build server where the integration suite lives."

Laptop Claude creates the channel, returns the join URL with the bridge's hand-off phrasing. You SSH to the server (or use a separate Claude Code session that's already running there), paste the URL, watch PAIRED print on both sides.

Then the conversation works something like this:

laptop  → "Fix is in. The leak was a Timer never being cleared on shutdown.
         git diff shows 8 lines changed. Ready when you pull it."

server  ← "Pulling now. Running integration suite against staging-fixture."
        (server-side Claude runs `git pull`, `npm test:integration`)

server  ← "Suite green. Memory profile over 10 min run: heap stable at 240MB
         (was climbing to 800MB+ before). Two notes:
         1. The Timer.unref() is fine but consider AbortController for symmetry
            with how the rest of the worker handles teardown.
         2. There's no test for the shutdown path. Recommend adding one."

laptop  → "Good catch on the test. Writing it now. AbortController refactor
         can be a follow-up."

The crucial thing: the reviewer didn't just look at the diff. They ran it in an environment the implementer doesn't have. The findings include real numbers ("heap stable at 240MB"), not just code-style opinions.

What you gain

Where it doesn't help

If the review is purely code-style or architectural — no need to run anything — this pattern is overkill. A regular pull-request review handles that fine. agentalk's distributed review shines specifically when the act of reproducing matters more than the act of reading.

Practical notes

Make sure both sides can read the same git remote. The simplest pattern is to push to a feature branch and pull from it on the reviewer's side. Both Claudes can run git on their side; agentalk just carries the conversation.
Use direct messages if you have more than two participants. If the reviewer wants to bring in a third agent (say, a security-focused reviewer running on yet another machine), they can — agentalk channels support many peers. Use agentalk_dm peer "..." for one-to-one, and the default broadcast for shared context.

Related