An interoperability contract starts by naming who is communicating, which protocol role each participant occupies, what information crosses the boundary, and which authority remains with a human or controlling system.
Learning boundary. Protocol roles describe communication responsibilities. They do not establish identity, trustworthiness, authorization, safety, truth, or successful execution. A declared tool or capability still requires an application-level consent and policy decision.
Learning objective
Turn an ambiguous agent handoff into a bounded interaction map.
By the end of this lesson, you should be able to name the user, host, client, server, agent, tool, resource, and workflow authority in a proposed interaction, then mark what the protocol does and does not decide.
01 · Initiator
Who is asking for work?
Identify the user or controlling application that initiates the request. A model-generated message is not automatically a user authorization.
02 · Peer
Which system receives it?
Name the client, server, or remote agent at the protocol boundary. Avoid collapsing the transport peer and the organization operating it into one object.
03 · Capability
What can the peer expose?
Separate resources, prompts, tools, skills, modalities, and extensions. A capability declaration describes an interface; it does not prove implementation quality or safe behavior.
04 · Authority
Who may approve an external effect?
Mark the boundary between preparing, recommending, requesting consent, and executing. Keep the approval rule outside the message description when the effect matters.
Practice lab
Draw the boundary before the tool call.
A host connects to a server that exposes a search resource and a “send invoice” tool. A remote agent can ask the host to invoke that tool, while a human owns the payment policy.
List each participant and assign its protocol role without using vendor names as role definitions.
Mark which data is read, which operation is proposed, and which effect would leave the system.
Write the approval point and name the actor responsible for the decision.
List the facts that remain unknown until the server’s implementation, policy, and authorization context are inspected.
Source shelf
Study roles before selecting a binding.
Model Context Protocol specificationRead the host, client, and server architecture and the distinction between resources, prompts, tools, sampling, roots, and elicitation. The specification also states that implementors must address consent and safety in their applications.
Agent2Agent Protocol specificationCompare client, remote agent, Agent Card, task, message, part, and artifact. A2A’s opaque-execution model is useful precisely because it does not require peers to share internal state.