Parley Lets Coding Agents Talk

Parley is a Show HN project by its maintainer on Weldra.dev that lets one coding agent talk to another coding agent through an MCP hub. It deals with a very specific annoyance in agentic coding: when two agents need to coordinate, the developer often becomes the message bus. The useful idea is simple: give agents names, scoped tokens, and file claims, then make their coordination visible enough for a human to review.

For Cursor, Anysphere's AI code editor, this lands near the practical edge of agentic coding governance: not policy decks, but small boundaries that keep parallel agent work understandable. Parley is a coordination layer for coding agents, not a replacement for code review, ownership, or taste.

See the bug hiding in parallel agent work

The Parley author described a familiar loop: their coding agent would stop and ask them to decide something with a teammate, so the human copied context from one agent session into another human conversation, then copied the answer back. That works once. It gets silly when several agents are editing related files.

Parley's bet is that the agents should be able to ask each other directly. An agent connects to a hub over MCP with a team-scoped token, addresses another agent by name, asks a question, or hands over a task. It can also claim files so other agents see overlapping work before two separate diffs collide.

MCP is an open protocol that lets AI applications connect to external tools and context servers through a shared interface. In Parley, MCP is not being used for another database lookup or GitHub action. It is being used as the transport for agent-to-agent coordination.

A concrete example: one Cursor agent is refactoring src/billing/taxes.ts, while another is adding a checkout edge case in src/checkout/applyDiscount.ts. If both need src/billing/money.ts, a file claim is a cheap early signal. Nobody has to wait until Git shows a conflict.

The trap is pretending this removes human judgment. It does not. It removes low-value relay work, which is different.

Notice why developers cared

The Hacker News interest was not about novelty for its own sake. Developers recognized the “human as network layer” problem because coding agents are already good enough to run in parallel, but not yet good enough to coordinate socially.

That gap matters in real repos. A single agent can follow a local instruction file and produce a patch. Two agents can each do that and still break each other's assumptions. Add a teammate's agent, and the coordination problem starts to look less like prompting and more like distributed work.

Parley's interesting pieces are small and infrastructural: agent identity, team-scoped tokens, directed messages, handoffs, file claims, a trust model, and a way to wake an agent. Those are boring in the best sense. They sound like the parts you would want before letting background workers negotiate around your codebase.

The obvious objection is also fair: agent-to-agent chat can become another hidden channel. If the conversation is not logged, reviewable, and tied back to the patch, it can make work harder to audit. A helpful coordination layer should leave receipts, not vibes.

This is where Cursor users should squint at the workflow, not just the demo. Can you see the file claim next to the change? Can you review what the other agent answered? Can your repo rules still win when agents disagree?

Keep the boundary in the repo

The cleanest version of this idea treats Parley as a coordination helper and the repo as the source of truth. Cursor rules, AGENTS.md, and review checklists should still define what an agent is allowed to change.

For example, a small repo rule can tell any agent using a coordination hub how to behave around claims and handoffs:

---
description: Coordination rules for parallel coding agents
alwaysApply: true
---

When working in parallel with another agent:
- Claim files before editing them when the tool supports file claims.
- Do not treat another agent's answer as approval to bypass tests or review.
- Summarize any agent-to-agent handoff in the final response.
- If two agents disagree about architecture, stop and ask the human reviewer.
- Never share secrets, tokens, customer data, or private logs in agent messages.

That rule is intentionally plain. It does not try to encode all of engineering culture into one prompt. It names the unsafe edges: silent edits, skipped review, unresolved architecture calls, and secret leakage.

You can pair that with an AGENTS.md boundary in the part of the repo most likely to see overlap:

# Payments workspace boundary

Agents may edit files under `src/payments/**` for bug fixes and tests.

Ask for human review before changing:
- payment provider selection
- retry semantics
- ledger write paths
- customer-visible receipt text

If another agent has claimed a file in this directory, coordinate first and include the result in the PR summary.

The trap is moving the boundary into the chat channel. If the rule only lives inside one agent session, the next agent will miss it. Put durable constraints where the repo can carry them.

Try it when coordination is the bottleneck

Parley is worth trying when you already have multiple coding agents doing real work and the annoying part is passing messages between them. It is probably overkill if one developer runs one agent at a time, or if your repo still lacks basic review and test habits.

A good experiment is narrow. Pick one low-risk slice, like docs fixes plus tests, or a small service with clear ownership. Have two agents work in parallel, use file claims, and require each agent to summarize any handoff in its final message.

For Cursor users, keep the human review inside the IDE. Use the agent transcript, the diff, and the test output as one review surface. The moment you need to replay a hidden conversation to understand why a file changed, the experiment has outgrown its safety rails.

The same coordination pressure shows up from the opposite direction in Ante Ships Offline Coding in One Binary: once agents can run in more places, the question becomes how their work stays inspectable.

Try Parley safely

Use this as a lightweight fit check before connecting coding agents through Parley or a similar MCP server.

Check	Fit	Not fit
Agent count	Two or more agents work in parallel on the same repo	One agent handles one task at a time
Work type	Low-risk code, tests, docs, refactors with clear ownership	Security-sensitive flows, payments, auth, migrations without close review
Coordination need	Humans are copying questions and answers between agents	Agents mostly need better local context, not peer coordination
Review surface	Messages, claims, diffs, and tests are visible to the reviewer	Agent-to-agent decisions disappear into chat logs
Repo rules	AGENTS.md or Cursor rules define boundaries	Each agent relies on ad hoc prompts

A safe first run is small: two agents, one branch, one clearly owned directory, no secrets, no production credentials, and a reviewer who reads both the diff and the handoff summary.

One next step

Try the idea on one low-risk directory with two agents and one reviewer. If the handoff summary makes the diff easier to review, Parley is solving a real problem; if it creates another hidden thread, tighten the boundary before expanding it.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Cursor artifact first: a .mdc rule stub, an AGENTS.md boundary, a custom subagent note, or a Cursor review checklist.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Cursor?

  Start by writing down one visible team rule for Cursor, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Cursor artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a .mdc rule, AGENTS.md note, or review checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Cursor teams deciding which rule, subagent, skill, or MCP boundary to standardize next around “Parley Lets Coding Agents Talk.”
• Best first artifact: turn the named fix into a .mdc rule, AGENTS.md note, subagent receipt, or review checklist before the next automated run.
• Best comparison angle: compare the workflow against the current Cursor review path, connector scope, and team rule file; keep the path that leaves the shortest auditable trail.

Further reading

• Parley — source
• Cursor — Agent
• Model Context Protocol — specification
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.