Browser agents find it. Coding agents fix it.

Computer-use and browser agents are getting good at exercising a running app: clicking through flows, catching broken states, reading contrast. Coding agents are getting good at shipping fixes. What's missing is the handoff — a durable, human-auditable format that carries a finding from the agent that saw it to the agent that can fix it. That's what a Pincushion pin is.

The problem with agent-to-agent chatter

If a QA agent messages a coding agent directly ("the submit button is unreadable on mobile"), three things go wrong. The context is lossy — no selector, no screenshot, no viewport, so the coding agent re-derives everything. The handoff is ephemeral — when the session ends, the finding is gone. And no human ever saw it — an agent can now change your codebase because another agent said so, with no triage step in between.

A pin is a work packet with a paper trail: selector, screenshot, viewport, thread, acceptance criteria — and a human triage state between "found" and "fixed."

How the handoff works

  1. The finding agent files a pin. Any agent with the Pincushion MCP server (or the REST surface) calls create_agent_pin with the page URL, a CSS selector, what it found, and optionally a testable acceptanceCriteria. The pin renders as "Playwright a11y check (agent)" — agents never impersonate humans or the Pincushion AI critic.
  2. The pin lands in triage, open like any other. You (or your reviewers) see it in the extension, the share report, or /pins — with an agent chip so provenance is obvious. Approve it, edit it, or archive it.
  3. The coding agent implements it. Approved pins flow through the normal loop — implement_approved_pins groups them into per-page packets, assign_pin_to_agent dispatches one, fix_and_resolve records the commit, branch, and PR on the pin.
  4. Verification closes it. On deploy, Pincushion AI re-checks the page and writes a verdict back to the pin.

What this unlocks if you work alone

The classic problem with feedback tools for solo builders: there's no second human to leave the feedback. With agent pins there doesn't have to be. A nightly Playwright pass, an axe-core accessibility check in CI, or a browser agent walking your critical flows can each file findings as pins — and in the morning you triage a queue of concrete, selector-anchored issues instead of reading logs. Your coding agent burns them down one packet at a time.

Filing a pin from your own tooling

From any MCP-connected agent it's one tool call:

create_agent_pin({
  pageUrl: "https://staging.yourapp.com/checkout",
  selector: ".checkout-form .btn-submit",
  body: "Submit button contrast is 2.1:1 on mobile — fails WCAG AA. Suggest --accent-dark token.",
  agentName: "nightly axe-core patrol",
  severity: "high",
  acceptanceCriteria: "axe-core reports 0 contrast violations on .checkout-form"
})

Scripts without MCP can POST the same shape to the sync API with your license key — see the automation guide. Agent pins are metered as AI actions (25/month free, unlimited on Pro), and they start open — never pre-approved — so the human stays in the loop by construction.

Why a ledger beats a pipe

Point-to-point agent integrations rot: every pair of tools needs custom glue, and nothing is auditable after the fact. A ledger inverts that. Any agent that can describe a finding can write to it; any agent that can code can read from it; every entry keeps its provenance, triage history, and the commit that closed it. That's also why the format is boring on purpose — a pin is JSON with a selector and a screenshot, not a protocol.

Works with pins from Cursor, Claude Code, VS Code, Windsurf, and Codex on the implementing side. New to Pincushion? Start with what a visual feedback MCP server does.

Get started — free Back to home