# I gave two Claude Code sessions a PM and an engineer job. My job was to watch > Source: > Published: 2026-10-16 07:56:57+00:00 Since August, Claude Code sessions can talk to each other. The feature is called [cross-session messaging](https://code.claude.com/docs/en/whats-new/2026-w32) and arrived in v2.1.224: a session finds your other sessions with `ListAgents` and sends one of them a message with `SendMessage`. What travels is only the text Claude writes for the other session, never the conversation history or files. I've been using it to build rind-ui, a headless UI component library, with two sessions that have different jobs. One is the PM. The other is the engineer. This is how that went, including the parts that didn't work the first time. The repository's `CLAUDE.md` says it plainly: two sessions work on this repo, one writes specs and reviews, one implements. **The PM session** writes each component as a spec (an OpenSpec change: the requirements, the scenarios, the tasks) and validates it before any code exists. When the engineer is done, the PM reviews the result. **The engineer session** takes one spec, implements it, and when it thinks it's finished, sends a message back asking for review. That hand-off lists every file it touched, so the review knows exactly what to look at. Neither session has the other's context. Each sees the repository and the messages it receives. I think that helps: the reviewer doesn't share the implementer's assumptions, so it reads the code more like the next person would. The first version allowed up to three review rounds per change. It's now down to two, with stricter rules. I see it as the [slot machine](https://reado.watermelon-studio.it/blog/the-code-review-slot-machine) problem in miniature: a reviewer asked to find problems will always find one more, so the loop has to be told where to stop. Today the rules are: `docs/review-backlog.md`, to be picked up later. Then the change is approved, archived, and merged. The severity line and the cap on passes are what turned an open-ended loop into one that ends. This is the part I like most, and the reason I'm writing this on the blog of [Reado, the IDE for reading the code your AI agent writes](https://reado.watermelon-studio.it). The PM session doesn't write its findings into a chat message. It leaves them as Reado comments, anchored to the exact lines they're about, each one typed (bug, refactor, performance…) and marked as a task. They're Markdown files in `.reado/` inside the repository, so both sessions read the same list, and so do I. The engineer fixes each one, and the task is closed with a command that proves the fix: `task done` with a `--verify` test command. Usually the engineer runs it; during verification the PM sometimes runs it itself. Reado records the task as done only if that command passes; a fix without a passing check stays visible as unverified until someone looks at it. So far the PM has left 128 of these tasks: 115 bugs, 5 refactors, 3 performance issues and 5 notes. All 128 are closed, and every one of them was closed by a verify command that passed. That has a side effect I didn't plan for. When I open the code in Reado, I don't need to reconstruct what the two sessions were arguing about. Each finding sits on the line it's about, with what was wrong, and the test that proved it fixed. It's easier for the session that has to fix the bug, and it's easier for me to see what's happening, where, and how it's being resolved. Mostly, I watched them work. The two sessions pass the work back and forth on their own: spec, implementation, review, fixes, verification. My job is the one I wrote about in [my last post](https://reado.watermelon-studio.it/blog/what-are-the-humans-for): deciding what's worth keeping. Each spec ends in a single change, and I review that change before it lands. Not to proofread every line (the sessions already did two passes on the diff), but to judge whether it's what I wanted, and to read the comments that explain why the code looks the way it does. The part I didn't expect is how well the PM role scales sideways. The PM doesn't have to stay on one project: it can write three specs for one, move to the next project and write three more there, then switch again. The engineer sessions always have a spec waiting, and several projects move forward at once. The token bill goes up with it, but for the amount of work that gets done, it's a cost I find reasonable. It works best when the project has clear edges. rind-ui is a good example: a complete headless component library, plus a library that makes it easier to test components built on top of it. The scope is defined, the agent knows what to do, and not many decisions are left open. When one is, the PM doesn't guess: it asks me. One warning before you copy this. Two sessions reviewing each other's work produce good results, but they're expensive: every spec gets written, implemented, reviewed, fixed and verified, and each step reads a lot of code. I've run out of tokens more than once doing this. What I'd do differently from the start: tell both sessions, the PM and the engineer, to use a lighter model such as Sonnet for the less complex parts, and keep the strongest model for the steps that need judgment, like writing the spec and the review itself. Along the way the two sessions became three: a third one joined and built the documentation site. You can see the result at [rind.watermelon-studio.it](https://rind.watermelon-studio.it), with live examples for every component, React for now. The library is already [on npm](https://www.npmjs.com/package/@rind-ui/react), and it changes every day: new components land as their specs go through the loop, and many more are already specced. If it keeps working the way it has, I'll write the follow-up when there's more to show. If you want to try the review side of this yourself, the Reado app is free and MIT-licensed: [download it here](https://reado.watermelon-studio.it/#download).