Hand work between agents that don't share a vendor.

The teams doing the most interesting agent work aren't loyal to a single provider. They've noticed that one model writes better code, another is a better critic of it, a third is cheaper for the bulk pass that reads four hundred files. Those aren't marketing claims to them — they're observations from watching the same task run both ways.

And the ranking keeps moving. A model that was the obvious choice last quarter isn't this quarter, pricing shifts, rate limits bite at the wrong moment. Building a workflow that assumes one vendor forever is building something you'll rewrite.

Every vendor's memory stops at their walls

Each of these tools has its own idea of persistence — projects, threads, saved instructions, a memory feature. All of it is genuinely useful, and none of it crosses to a competitor. That's not an oversight; it's what those features are for.

Which leaves you as the transport layer. You read the first agent's output, summarize it into the second agent's prompt, and lose the specifics every time — because summarizing is lossy and you're doing it by hand, at the end of a long session, from a scroll-back buffer.

Neutral ground the protocol already reaches

Markbase is a remote MCP server at a public HTTPS endpoint, with OAuth 2.1 sign-in. There is no Markbase SDK and no per-vendor integration to wait for: a client that speaks remote MCP and can complete the authorization flow reads and writes the same workspace, whoever built it.

So the handoff stops being a summary you compose and becomes a path. The first agent writes its output to platform/reviews/retry-backoff.md. The second agent reads that path. Nothing is lost in translation, because there is no translation — both sides see the same Markdown.

Check your client, though. Support for remote MCP servers and OAuth varies by vendor and by version, and it's moving quickly. Markbase implements the standard; whether a given client speaks it yet is a question about that client.

The conventions travel too

The subtler win is that you only write the working agreement once. An _markbase.md at a folder root says what that folder is for, what the frontmatter contract is, and what's append-only — and every agent that touches the folder reads it, regardless of which company trained it.

Compare that with maintaining the same instructions in one vendor's project settings, another's config file, and a third's system prompt, and keeping all three in step as your conventions change. The conventions belong with the data, not replicated into every harness.

Overlap is the normal case here

Agents from different vendors are the least coordinated writers you'll ever have. They don't know about each other, they run at different speeds, and the fast one will happily write over the slow one's work if the store lets it.

Markbase doesn't. Every write says which version it is changing; if something landed in between, the write is refused with the current version rather than applied, and the agent re-reads and redoes its edit. The server never merges on an agent's behalf — that's a decision an agent should make with the current text in front of it.