Sign in Try the live demo

Use case

Human-in-the-loop for coding agents

A coding agent that redeploys a preview after every change can outpace any human's ability to look at each version. Human-in-the-loop for coding agents means keeping a person's judgment in that loop without making them the bottleneck: one click on the live preview, one comment, and the agent gets back something it can act on without a human translating first. Patchrooms is that checkpoint. You embed one script tag on the preview, staging, or local build the agent is iterating against. A reviewer clicks whatever's wrong and says what should happen instead. The agent reads it back as a structured instruction, not a screenshot it has to guess at.

Try the live demo

The problem

Loop-driven development multiplies how much an agent ships, but it doesn't multiply how fast a human can look at each result. When an agent redeploys a preview every few minutes, a reviewer stops being able to keep a running mental list of "this button's misaligned," "that state didn't reset," "the error toast never disappears." Those notes get lost in a Slack thread, or worse, never written down, and the next iteration repeats the same miss. The usual fixes make this worse, not better. Skipping review to keep pace ships broken UI the agent had no way to know was broken: it never gets told. Routing everything through a person who retypes each bug into the agent's chat turns that person into a translation layer, doing manual work an agent-readable report could have done automatically. Either way, the review step that loop-engineering is supposed to speed up becomes the thing slowing it down.

The workflow

  1. Embed the room on the preview the agent is iterating against

    One script tag, `<script src="https://room.patchrooms.com/v1/patchrooms.js" data-project-key="pr_..."></script>`, on any staging, preview, or local URL the agent redeploys to. No build step, no account needed by anyone who's going to click around.

  2. A human reviews the live app, not a description of it

    The reviewer clicks the element that's wrong and says what should happen, typed or as a voice note. They stay in the browser, looking at the real running app, not a screenshot pasted into chat or a bug tracker form.

  3. The click becomes a structured report automatically

    Patchrooms captures the DOM selector of what was clicked, a screenshot, the page URL, viewport, browser, and any console errors present, alongside the comment (voice notes are auto-transcribed). Status starts at new.

  4. The agent reads the report, not a paraphrase of it

    "Copy agent feedback" produces a Markdown block, selector, goal, constraints, screenshot reference, ready to paste into Claude Code, Cursor, or a builder chat. With MCP access, the agent pulls it directly: list_reports, get_report with the screenshot inline.

  5. The agent patches, and the loop advances on its own signal

    The agent fixes the element behind that selector and, if it has MCP access, calls set_status to mark the report in-progress or closed. The reviewer's next pass checks the same spot, not the whole app from scratch.

Example

A Cursor agent is iterating on a signup flow, redeploying a preview build after every change. The room is embedded on that preview URL with `data-project-key="pr_..."`. A reviewer clicks the disabled submit button, leaves a voice note ("this should be enabled once both fields are filled, right now it's stuck grey even after I type"), and moves on. No account, no context-switch out of the browser. The voice note is transcribed automatically. The report now holds the selector for the submit button, the screenshot, the page URL, viewport, browser, any console errors on that page, and the transcribed comment, tagged `new`. The developer running the agent copies "Copy agent feedback" into the Cursor chat, or the agent pulls it itself via `get_report`. Cursor patches the disabled-state logic, the developer redeploys, and marks the report `in-progress` via `set_status` (or the agent does, over MCP) once the fix is live for the reviewer to confirm.

Agent-ready export

Every report has a "Copy agent feedback" button. It renders a Markdown block with the DOM selector, the reviewer's comment (or transcribed voice note) as the goal, any constraints implied by the report (viewport, browser, console errors present), and a reference to the screenshot. Paste that block into Claude Code, Cursor, or a builder chat and the agent has what it needs to locate the element and act, no re-describing the bug in your own words. If the agent has API access, skip the copy-paste step. The MCP server exposes list_reports and get_report (screenshots inline) so the agent can pull the queue directly, and set_status so it can mark a report triaged, in-progress, or closed as it works through the list. Read and set_status are real and shipped; there's no native Slack, Linear, or Jira sync yet, so the loop is: reviewer clicks in the browser, agent reads via MCP or pastes the Markdown, agent patches, reviewer looks again.

A report exports as Markdown like this:

# Patchrooms feedback: report #a3f1c2

**Selector:** `button[data-testid="submit-signup"]`
**Goal:** Enable the submit button once both email and password fields have valid input. Currently it stays disabled (grey, unclickable) even after both fields are filled.
**Constraints:**
- Viewport: 1440x900 (Chrome 126)
- Console errors present on page: `TypeError: Cannot read properties of undefined (reading 'valid')` at `SignupForm.tsx:44`
- Status: new

**Screenshot:** https://room.patchrooms.com/blob/a3f1c2.png

**Reviewer comment (transcribed from voice):** "This should be enabled once both fields are filled, right now it's stuck grey even after I type."

FAQ

Does the reviewer need a Patchrooms account?
No. Anyone with the preview link can click, comment, and submit. Reports are free and unlimited for reviewers. Only the person triaging the queue and reading exports needs an account.
How is this different from a screen-recording tool or a Slack thread?
A recording or a Slack message is something a person has to watch and re-describe before an agent can act on it. A Patchrooms report already carries the selector, screenshot, URL, and console state, and exports as a Markdown block an agent can read directly, or an agent can pull it itself over MCP. The structuring happens once, at capture time, not every time someone hands it to an agent.
Can the agent close the loop without a human re-typing anything?
Yes, if it has MCP access: list_reports to see the queue, get_report to pull the selector, screenshot, and comment, set_status to mark it in-progress or closed once patched. The human's only input was the original click and comment.
Does this work with local or air-gapped agent setups?
Yes. Set storage: 'local' and reports never leave the browser, no key, no signup, no network call. Export as Markdown or JSON and hand it to the agent by hand instead of over MCP.
Which coding agents and builders does this work with?
Claude Code, Cursor, Codex, Windsurf, and Cline on the terminal/IDE side; Lovable, Bolt, v0, and Replit Agent on the builder-chat side. The report format is the same either way: selector, screenshot, comment, status.
Does Patchrooms replace the human, or automate review away?
Neither. It keeps a human in the loop deliberately, at the one point that still needs judgment, what's actually wrong and what should happen instead, and removes the busywork of writing that down in agent-usable form.