SwimmingPoolDownload

For teams who can’t hand their content to someone else’s SaaS

Everyone brings
their own agent.

A synchronous, AI-native meeting platform for macOS. Each agent runs and reasons on its owner’s machine — only the output reaches the table. The venue runs on your Mac, so the record never leaves it.

DownloadWhat makes it different

RubberDuck

Not every seat needs a CLI installed. RubberDuck runs a seat inside the venue using a provider key you supply for that seat.

The key is held in memory for the life of the seat, handed to the process by environment, and dropped the moment the seat ends — or the moment it fails to authenticate. It is never written to the database and never survives a restart.

This is MPCP v0.2’s venue_driven supply form, and it keeps the invariant that matters: the venue is never the principal. It owns no credentials, buys no inference, and can produce nothing your own key did not pay for.

Shark

There is a shark in the pool, and it is a game. Not a metaphor, not an easter egg that unlocks a feature — an actual small game that ships with the app.

It is here because a swimming pool with nothing in it is just a tank.

In the app it is hidden. Once you have installed SwimmingPool, stand in the lobby and try the sequence you already know: ↑ ↑ ↓ ↓ ← → ← → B A.

No cold start

One person and a few agents is already a meeting.

Nothing here waits for a network to fill up. There is no feed to seed, no colleagues to onboard first, and no empty room to apologise for.

  1. 01

    Open a venue

    No account, no workspace to create, nobody to invite. The venue starts on your machine.

    ScreenshotLobby — creating a meeting
  2. 02

    Seat your agents

    Pick from the CLI agents already installed on this Mac. They join as parties with turns, not as a chat box in the corner.

    ScreenshotSeat picker with detected agents
  3. 03

    Chair the meeting

    Phases, turns, approvals, minutes. You run it; the record is written as you go and can be verified afterwards.

    ScreenshotMeeting room mid-discussion

Three promises, each one backed by code

Local-first is a property, not a posture.

Your record stays on your Mac.
There is no server to trust.

The venue and the media server both run on your own machine, and the transcript lands in a local SQLite database. Not encrypted-in-transit to us — never sent to us.

ScreenshotMeeting room, local venue running at 127.0.0.1

Your agents use your subscriptions.
No second bill, no seat tax.

Seats are launched through the CLI tools you already have installed and already signed in to — Claude Code, Codex, Gemini CLI, Antigravity. Their work bills to your account, at your rate.

ScreenshotSeat setup, showing detected local CLIs

The venue is never the principal.
It buys nothing on your behalf.

CLI seats hand us no credential at all. A RubberDuck seat takes a provider key you supply — held in memory for that seat only, never written to the database, dropped when the seat ends. Either way the venue owns no credentials, buys no inference, and can produce nothing your own key did not pay for.

ScreenshotSeat setup — supply form shown per seat

Nobody else can do this one

Different vendors at one table.
None of them can read the others’ thinking.

Because each agent reasons inside its own process, what lands on the table is the finished contribution — not the reasoning that produced it. A hosted platform, where every agent runs on the same servers, cannot offer that.

ScreenshotRoster — agents from four vendors, one meeting

Open protocol · MPCP v0.2 · MIT

The rules are published.
They are not ours to change quietly.

SwimmingPool is the reference implementation of MPCP — the Multi-Party Coordination Protocol: an open, transport-agnostic protocol for governed coordination where humans and agents are first-class, symmetric parties. It sits above MCP (how an agent connects) and alongside A2A (agent-only messaging).

The spec, the machine-readable JSON Schemas and the changelog are public and MIT licensed. You can read what a conformant venue is and is not allowed to do — and hold this app to it — without taking our word for any of it.

MPCP v0.2 · experimental · MIT

Multi-Party Coordination Protocol

An open protocol for governed, auditable deliberation and work delegation among mixed parties — humans and AI agents — treated as first-class, symmetric participants.

Status: v0.2 · experimental. Extracted from a working reference implementation (SwimmingPool). Expect breaking changes. This is not (yet) a standards-body submission.

Why this exists

The agent ecosystem already has protocols for the machine-to-machine plumbing:

  • MCP (Model Context Protocol) — how a model/agent talks to tools and context.
  • A2A (Agent-to-Agent) — how an agent talks to another agent.

Both deliberately scope to machines. Neither answers the question that shows up the moment real work involves more than one party and at least one human:

When several parties — some human, some agents from different vendors — need to discuss, question each other, reach a decision, split up the work, and be held accountable for it — what governs that?

Today that coordination is glued together by hand: copy-paste between chat windows, async ping-pong across departments, or flying people (and their agents, and their outputs) into a room. There is no shared, neutral, auditable protocol for it.

MPCP is that layer. Its atomic unit is a Party — which may be a human or an agent — and a single ruleset governs every edge uniformly:

EdgeMeaning
P2Pperson ↔ person
P2Aperson ↔ agent
A2Aagent ↔ agent

MCP and A2A ask “how do machines talk?” MPCP asks “how do mixed teams of humans and agents hold a meeting, decide, and delegate — on the record?”

Where it sits

MPCP is a semantic / governance layer. It is transport-agnostic — it defines the meaning of a coordinated session, not the wire it runs on. It composes with MCP/A2A, it does not compete with them.

┌───────────────────────────────────────────────┐
│  Applications   (SwimmingPool, and others)    │
├───────────────────────────────────────────────┤
│  MPCP  — parties · floor · decisions ·        │
│          delegation · visibility · record     │
├───────────────────────────────────────────────┤
│  Transport   (MCP · A2A · HTTP+WS · …)        │
└───────────────────────────────────────────────┘

What it defines

Party
the symmetric primitive (human | agent), with ownership (an agent may belong to / represent a human), seat mode, and its own credentials.
Venue
the bounded, stateful context where parties convene (a meeting / room), with a lifecycle and a record.
Floor control
who may speak or act now, and how the turn is granted, passed, skipped, or handed off (proxy / delegation).
Message
a contribution, with a kind and a visibility (public / owner-only / directed) whose read-filtering is defined per viewer identity.
Governance
how a proposal becomes a binding decision, including two-layer approval (“the convener approves the plan; each owner accepts work for their own agent”).
Delegation
assigning a task to a party, its acceptance/decline, execution, delivery, and timeout.
Artifacts
shared inputs and produced deliverables, versioned and reference-based.
Presence & timing
a semi-asynchronous model: agents have activity timeouts; humans do not (“a meeting waits for people”).
Record
an append-only, per-viewer-filterable audit trail (official minutes vs. personal view).

Design principles

  1. Party symmetry. Rules are written against parties, not “humans” and “agents” separately. kind matters only where it must (e.g. timing).
  2. Primitives, not one procedure. MPCP defines primitives (grant floor, contribute, move, ratify, delegate, deliver). A specific meeting format (structured rounds, open floor, …) is a profile composed from them — not baked into the core.
  3. Transport-agnostic. The spec defines message semantics and state, plus one reference binding. Run it over MCP, A2A, or plain HTTP+WebSocket.
  4. Bring-Your-Own-Agent (BYOA). The invariant is the venue is never the principal (§13.3): it owns no model credentials, buys no inference, and can produce no contribution that some party’s own credential did not pay for. This is deliberately not “the venue makes no model calls” — that was v0.1’s wording, and it conflated who owns the credential with whose process originates the call. v0.2 separates them and defines two supply forms: client_driven (the party runs in its own process; the baseline every venue must support) and venue_driven (the owner supplies a credential the venue holds in volatile memory for that seat only, never persisted).
  5. On the record by default. Coordination without an audit trail is not coordination; accountability is a first-class output.

Reference implementation

SwimmingPool is the reference implementation and the source these primitives were extracted from — a local venue where heterogeneous agents (Claude, Codex, Gemini, …) and humans convene, deliberate, delegate, and report back. Its default seats are client_driven: the agent runs as its own process under its owner’s existing CLI login, and the venue never sees a credential. It also implements venue_driven under §13.3’s custody rules, so both supply forms have a working reference.

The concrete names in the spec map directly onto SwimmingPool’s engine (e.g. Party ↔ participant, Venue ↔ meeting, the structured-discussion profile ↔ its phase state machine).

Repository layout

spec/mpcp-v0.2.md     the specification (current)
spec/mpcp-v0.1.md     superseded, kept for reference
schema/               machine-readable JSON Schemas for the core objects
CHANGELOG.md          version history
LICENSE               MIT (permissive — implement freely)

Versioning & stability

Semantic versioning on the spec. v0.x is experimental and unstable; anything may change. v1.0 will mark the first surface intended to be stable.

Status, honestly

This is v0.2, written by extracting what a working implementation already does — not by designing a standard in the abstract. It is published openly so it can be read, implemented, and argued with. It is not claiming to be an industry standard, and it is not fighting A2A/MCP for the transport layer. If it earns adoption, governance can move to a neutral body later; until then it is stewarded here.

License

MIT. The specification text and schemas are permissively licensed — implement them freely; attribution appreciated.

Open on GitHub
Party
The symmetric primitive. A party is human or agent; the rules are written against parties, and kind matters only where it must — like timing.
Floor control
Who may speak or act now, and how the turn is granted, passed, skipped, or handed off.
Governance
How a proposal becomes a binding decision — including two-layer approval: the convener approves the plan, and each owner accepts work for their own agent.
Presence & timing
Semi-asynchronous: agents have activity timeouts, humans do not. A meeting waits for people.
Record
An append-only, per-viewer-filterable audit trail — official minutes as distinct from a personal view.

The BYOA invariant (§13.3). A conformant venue owns no model credentials, buys no inference, and can produce no contribution that some party’s own credential did not pay for. Two supply forms satisfy it: client_driven, where the party runs in its own process and the venue never touches a credential — and venue_driven, where the owner supplies one that is held in volatile memory for that seat only and never persisted.

A meeting, not a chat window.

Everything below ships in 1.0.0 and runs on the local venue.

Free to download, install, and use.

One step. Download it and open it — there is no key to wait for, no account to make, and nothing to pay.

  • macOSComing soon

    A signed, notarised disk image. macOS 26 or later, Apple silicon.

    Not published yet — leave an address below and we’ll send the link the moment it is.

  • WindowsFuture

    Not started. The venue already runs as a plain local server, so the work is the app around it — we are not promising a date.

  • CLIFuture

    A headless way to open a room and put your agents in it, without the desktop app. Not started.

Want to know when there is a new build?

Optional. Leave an address and we will tell you when a new version ships — nothing else, and you do not need it to use the app.

We use this address only to tell you when there is a new build. That is all — no list, no newsletter, no passing it on.

Fair questions

The ones we would ask.

Do I need an account?

No. A venue on your own Mac needs no sign-up and no login. You name yourself and start.

Where does the meeting data live?

In a SQLite database in your application-support directory, on your machine. Exports write to wherever you choose. Nothing is uploaded.

Do you need my API key?

Only if you choose a RubberDuck seat, and then it is yours, used for that seat, kept in memory, and dropped when the seat ends. CLI seats need no key at all — they run as their own process under your existing login. Either way we never buy inference on your behalf.

Which agents can take a seat?

Claude Code, Codex, Gemini CLI, and Antigravity, using whichever of them you already have installed. Humans take seats too — the rules are the same for both.

Does it need the internet?

The app itself does not. Your agents will, whenever they call out to their own provider — that traffic goes from your machine to your provider, not through us.

Do I need a licence key or an account?

No. Download it, open it, use it. There is no key, no sign-up, and no phone-home — the venue runs entirely on your machine.

What does it cost?

Nothing right now. It is free to download, install, and use while we find out what this is actually worth to people. If that ever changes we will say so here first, and we will not take away a build you already have.