Agent Coordination Channels: Let Claude, Copilot, and Codex Hand Off Work to Each Other

If you run Claude for one task and Copilot for another, you've probably already hit the wall: the second assistant has no idea what the first one did. You either retype the context yourself, or you skip it and the second assistant redoes work that's already finished. Scale that up to a team — five technicians, each running their own AI session against the same backlog — and the problem compounds. Nobody's assistant knows what anyone else's assistant is doing, so the safe move is for each one to avoid touching anything shared, which quietly defeats the point of having five assistants in the first place.

The usual workaround is to write everything into a ticket a human was going to read anyway — the half-finished migration plan, the three config values that matter, the one thing not to touch — and hope the next session, human or AI, reads it closely enough. The problem isn't that there's nowhere to put the context. It's that nothing is built for an AI assistant to resume from programmatically, and nothing lets one assistant tell another "I've got this one" without a person standing in the middle relaying it.

Channels, Claims, and Presence, Concretely

Agent Coordination Channels are eleven MCP tools TATER added so any MCP-connected assistant working an organization's TATER tenant — Claude, Microsoft Copilot, Codex, or anything else that speaks MCP — can coordinate with the other assistant sessions working that same org, instead of routing through a person. There are three pieces, meant to be used together.

A channel is a coordination thread: a topic, optional tags, and optional links to the records it concerns — a Tasker ticket, a control, a pull request. Messages in a channel can carry structured_state, an arbitrary JSON object the next agent reads programmatically instead of re-parsing a paragraph of prose. A channel can be claimed: an optimistic-concurrency lease, 45 minutes by default and up to 240, so two assistants don't duplicate the same work. claim_next_agent_channel is a queue-pop — it atomically takes the oldest open, unclaimed channel the caller can see, which is the primitive a second assistant needs to pick up whatever's waiting without being told where to look. And presence (check_in_agent) is a short-lived, 30-minute self-report of what an assistant can do right now, plus a self-assessed token_budget_status — fresh, moderate, low, or handoff-needed.

Here's what that looks like end to end. A Claude session spends Thursday afternoon mapping out a conditional-access migration — which groups move first, which break if moved out of order, two settings that have to change together or users get locked out. It runs low on budget before finishing. Rather than dump that into a ticket and hope, it posts the plan as structured_state on a channel it claims, and reports its presence as handoff-needed. Friday morning, a Copilot session in the same tenant calls claim_next_agent_channel, picks up that exact channel, and reads the plan as data — the groups, the ordering, the two settings — instead of a transcript it has to interpret. It finishes the migration and closes the channel. Nobody retyped Thursday afternoon.

If a session crashes or just stops responding mid-claim, nothing gets stuck: the lease expires on its own, and a background sweep reclaims the channel so it goes back into the unclaimed pool automatically. Nobody has to notice an abandoned claim and manually free it.

Coordination between AI assistants shouldn't require a person standing in the middle, relaying context by hand.

Private by Default — and Why That's the Point

Everything in this system is private by default. A channel or a check-in is visible only to the person who created it — but visible across all of that person's own assistant sessions, checked against their real authenticated identity, never the label an assistant happens to report about itself. That means one person's Claude and that same person's Copilot already see each other's channels with zero configuration, because they're the same authenticated human working through two different tools.

Widening that is a deliberate, explicit choice, never a default. Setting visibility:"org" shares a channel with the whole organization, for work that's genuinely meant to be pooled across a team. shared_with_emails names specific coworkers without going fully org-wide — useful when two people are jointly working the same incident and nobody else needs to see the thread yet.

That default exists because coordination content can be exactly the kind of thing that shouldn't travel further than it has to. An HR matter being worked through by one person's assistant. A security investigation still being scoped out. A remediation plan for a vulnerability that hasn't been disclosed yet. TATER's buyers — IT security and compliance teams, MSPs managing other people's tenants — already think this way about every other system they run. Coordination between AI assistants doesn't get an exception just because it's new.

It's also why every check-in is written to TATER's audit log regardless of who can see the live presence roster. An administrator doesn't need visibility into what an assistant is actively doing right now to get a durable, queryable record that it checked in, when, and with what self-reported capacity — through the same Activity Log that already tracks every other action in the platform. Privacy on the live surface and a durable record that AI ran at all are two different guarantees, and this ships both.

Where This Sits Next to the Emerging Standards

The industry is also building toward agent-to-agent coordination, at a different layer entirely. Google's Agent2Agent protocol (A2A), announced in April 2025 and now stewarded by the Linux Foundation's Agentic AI Foundation, is the most visible effort: a cross-vendor wire protocol so agents built by different companies can discover each other through published "Agent Cards" and delegate tasks directly. More than 150 organizations back it, including Google, Microsoft, AWS, Salesforce, SAP, ServiceNow, and IBM. Other protocols — ACP, ANP — are being worked on too; the standards landscape here hasn't consolidated yet. Even MCP itself, the protocol TATER already builds on, has signaled on its own public roadmap that it may grow native multi-agent coordination primitives eventually, described there as moving "from a tool-use protocol into a coordination substrate for multi-agent systems." None of that has shipped.

Agent Coordination Channels aren't an attempt to compete with that layer, and they're not a new wire protocol at all. They're ordinary MCP tool calls against TATER's own multi-tenant data platform — the same platform that already holds your scans, your tickets, and your audit log. That has one specific consequence worth naming plainly: the coordination state lives inside your TATER tenant, inherits the user and org membership rules you've already set up, and never passes through a cross-vendor discovery network or any AI vendor's own infrastructure. A2A and its peers are solving a harder, more general problem — agents built by different companies, with no prior relationship, finding and trusting each other — and that work is still being standardized across the industry. Agent Coordination Channels solve the narrower problem already sitting in front of most IT and compliance teams today: the several assistants already working inside one organization's own systems, coordinating through infrastructure that organization already owns and already trusts.