This is a design argument about continuity across systems, using an illustrative supplier-review handoff. The cited MCP architecture is the dated June 2025 specification; the proposed handoff contract is not presented as a feature guaranteed by that protocol.
A team moves a supplier-review agent to a different environment. Its tools reconnect. Its prompt loads. It can read documents and draft a recommendation. The demonstration looks successful—until someone asks whether the supplier was already contacted and whether a confidential attachment was permitted to move.
Compatibility matters, but these questions ask for something additional: continuity of meaning and responsibility. A migration should preserve what the assignment means, what has happened, and what the receiving environment is allowed to do. Copying the conversation cannot establish all three.
Protocols move messages, not responsibility
Protocols can do more than transport bytes, and it is important not to dismiss their boundaries. The June 2025 MCP architecture describes capability negotiation, isolated server connections, and a host responsible for policies, consent, and authorization decisions. Those are useful responsibilities with explicit places in the architecture.
But support for a protocol feature does not answer every task-specific question. A tool advertised as available does not, by that fact alone, establish that this supplier may receive this attachment under this organization’s current approval. The application still needs to connect the request to its work context and enforce the applicable decision.
The continuity layer should build on protocol boundaries rather than bypass them. In the supplier review, that means retaining the assignment identifier and decision history while establishing new connections through the destination’s permitted mechanisms. Existing access is evidence to examine, not authority to copy without review.
Context needs ownership and provenance
The source environment might contain a supplier proposal, an internal pricing note, a personal reminder, and an unfinished assessment. They may appear in one conversation, but that does not mean they should travel as one bundle. Each has a purpose, an origin, and an audience.
A handoff should identify what the next step requires and disclose missing or restricted material. The receiving agent might get the proposal and the approved review criteria while the pricing note stays behind. It can continue the work supported by those inputs; it should not imply that its conclusion reflects material it cannot inspect.
Summaries introduce a further tradeoff. They make a handoff smaller and easier to understand, but they can omit a qualification that matters later. Keep references to the authoritative records where access permits, distinguish summarized interpretation from source material, and preserve unresolved questions explicitly. A compact handoff should reduce volume without manufacturing certainty.
Capability negotiation must include policy
After moving, the agent may find a tool with the same name and different behavior. One “send” operation might create a draft; another might contact the recipient immediately. A matching interface shape is not enough to establish that both are suitable substitutes for the approved step.
The destination needs to check the operation’s meaning, its side effects, the available controls, and the authority required. If equivalence cannot be established, it should narrow the action or request review. This can make a migration less seamless, but it prevents a smooth interface from concealing a consequential change.
Credentials should follow the destination’s access process and scope. The supplier-review agent may retain responsibility for finishing the assessment while losing the ability to send external email from that environment. Responsibility can survive reduced capability: the agent can prepare the message, explain the remaining dependency, and route it to an authorized participant.
A handoff is a small contract
For this scenario, the handoff record should answer six plain questions: What is the assignment? Who owns it? What is the last confirmed state? Which decisions remain open? What evidence supports that state? What can the receiving environment do next? These answers are more useful than an undifferentiated export of every message.
Include any outstanding external action. If a supplier email was submitted but no receipt was recorded, the receiving system should not send it again merely because its local history is empty. It needs to reconcile the earlier attempt or expose the uncertainty to a person. A migration is incomplete while that ambiguity is hidden.
The source also needs to know whether it still owns execution. Copying state into a new environment while leaving both agents free to act can turn portability into duplication. Make transfer, parallel contribution, and rollback different modes with explicit ownership. Useful independent work can continue without giving two sessions the same release authority.
The migration test
Test the destination with a realistic assignment containing an expired permission, a restricted attachment, a pending approval, and an uncertain external result. Check whether the agent resumes the permissible work and stops at the actual gaps. A convincing test includes refusals and partial progress, not only successful tool calls.
Then change the model while keeping the environment fixed, and change the environment while keeping the model fixed. Separating those transitions helps reveal whether a failure comes from reasoning, missing context, tool behavior, or permission mapping. It also prevents a clean prompt response from being mistaken for a successful migration.
Finally, ask a reviewer to reconstruct the handoff without interviewing its authors. Can they see what moved, what remained inaccessible, who assumed responsibility, and which checks were repeated? Interoperability becomes useful at this level: people can choose different infrastructure without abandoning the work or silently broadening its authority.
A portable worker does not need identical surroundings. It needs an explicit account of what continues, what changes, and what must be decided again.