What Must Agents Agree On Before They Work Together?

A shared protocol helps systems communicate. The work still needs permissions, ownership, and a definition of done.

A procurement agent finds a compliance agent that offers supplier reviews. Both support the same protocol. They can exchange messages, but the procurement system still needs to decide whether this service may receive the supplier’s data and what its report will establish.

The compliance review may take hours and ask for a missing insurance certificate. Returning a report is different from approving the supplier. The requester needs to know how to track progress, provide the document, handle cancellation, and present an advisory recommendation to the person who owns the onboarding decision.

Agent interoperability concerns how independently operated systems exchange work and results. Discovery describes what a service offers. Protocol negotiation establishes compatible message formats and features. Authentication identifies the participants, while authorization determines what they may request and share. These checks address different problems; successful communication does not settle trust or business meaning.

This is Post 21 in The Abstraction Shift: How Software Keeps Moving Up.

Why independent agents need an agreement

The first agent system often lives inside one application. A model selects a tool from a local catalog, the runtime validates the call, and a host service executes it. The system can still be complex, but the integration boundary is owned by one team.

The next system needs work from somewhere else.

A procurement agent may need a compliance review from a different team. Support, incident response, and engineering follow the same pattern: account history comes from a billing agent, diagnosis from a specialist runtime, and test or deployment operations from a controlled engineering service.

The remote system may have a different runtime, model, language, deployment boundary, organization, policy set, or release cycle. The two systems cannot rely on shared memory or an in-process function call. They need a contract for finding one another and coordinating a task.

Without such a contract, every pair of agents grows an adapter:

agent A -> custom JSON -> service B
agent A -> queue wrapper -> agent C
agent D -> vendor SDK -> service B

The technical cost is only part of the problem. Pairwise integration also hides responsibility. Adapters disagree about whether a response is a final answer, an intermediate artifact, or a promise to do work later. Some retry non-idempotent operations, some pass a credential farther than its owner intended, and some publish capability descriptions that sound precise while leaving their limits unstated.

Interoperability is valuable because it makes those assumptions visible, and dangerous when teams mistake a common wire format for a common understanding of risk.

What existing integration practices still provide

Distributed systems already have a rich vocabulary for connecting independent components. RPC and APIs expose remote operations, queues and event protocols decouple senders from receivers, discovery and schema registries locate targets and coordinate data shapes, TLS and OAuth protect channels and bound access, and artifact repositories move outputs too large for a request message. An agent protocol should reuse these foundations where they solve the same problem.

The new pressure comes from the caller and the work itself.

Conventional integrations fix the endpoint and operation at design time. In an agent-mediated exchange, a model may interpret the goal, discover a capability, decide that it is relevant, choose a task shape, and decide whether to continue after seeing partial results.

The duration of the work changes too. A conventional response usually represents one operation’s result, while a remote agent may need minutes, additional input, human approval, several sub-operations, or a separate artifact channel before it can finish.

Descriptions change role as well. A service catalog entry mostly documents an integration an engineer already chose; an agent catalog entry may become part of a model’s context and influence what it attempts. That makes wording, examples, limits, freshness, provenance, and trust status part of the control surface.

The older ideas provide the lineage. The agent boundary adds semantic selection, variable task duration, and a result that may be a conversation, a structured object, a file, or a set of claims with supporting evidence.

What Is Agent Interoperability?

Agent interoperability means independently operated systems can exchange work and results through an agreed interface. In the supplier-review example, the procurement system needs to find the compliance service, request a review, follow its progress, and retrieve the report.

The agreement extends beyond message format. It must say what data can be shared, how the participants establish identity and permission, what happens when more input is needed, and who decides whether the report is sufficient. The following responsibilities make those questions visible.

Responsibility	Question it answers
Capability discovery	What does the remote system claim it can do?
Protocol negotiation	Which transport, version, features, and schemas do both sides support?
Identity and authentication	Which principal is on the other side, and how is the channel protected?
Authorization	Is this caller allowed to request this operation with this data and scope?
Task lifecycle	How is work created, read, resumed, cancelled, retried, or declared failed?
Message semantics	Is this content an instruction, question, progress update, refusal, or result?
Artifact exchange	How are files, structured outputs, references, and provenance carried?
Error and retry semantics	What failed, can it be retried, and who owns recovery?
Outcome and evidence	What proves that the requested result occurred?

The list is intentionally wider than serialization. A protocol can define all of these surfaces, but it cannot decide whether a particular capability is appropriate for a particular user or whether an artifact is factually correct. Those are policy and evaluation questions around the protocol.

Current protocol work illustrates the separation. The A2A Protocol specification defines agent cards for discovery, messages, tasks, artifacts, asynchronous operations, authentication, versioning, and error behavior. MCP tools expose callable capabilities to a host and client, while MCP resources expose data or context that a host can retrieve and use. These are related surfaces, not interchangeable labels for every kind of agent coordination.

No single protocol needs to win for this to hold. A system needs explicit contracts for the boundaries through which model-mediated work moves.

Interoperability grows from message compatibility into a governed exchange for work, progress, artifacts, and outcomes.

Following remote work beyond the first message

The old integration question was:

Which endpoint do we call, with what request schema, and how do we parse the response?

The new question is:

Which capability is appropriate, what task contract does it accept, who may invoke it, how does the work progress, what artifacts will it produce, and what evidence will establish the result?

The request still matters, but the unit of coordination becomes a task with an identity and lifecycle:

discover -> negotiate -> authenticate -> authorize
  -> create task -> exchange messages and progress
  -> receive artifacts -> verify outcome -> close or reconcile

That lifecycle supports work that cannot fit into a single turn. It also gives the requesting runtime a place to preserve context, correlation, idempotency, deadlines, approvals, and recovery decisions.

This shift changes the role of a capability description. A useful description should communicate:

the purpose and boundaries of the capability;
the input types, required context, and data sensitivity;
whether the operation is synchronous, asynchronous, streaming, or interactive;
whether it creates side effects or only returns information;
the expected task states and possible human-input requirements;
the artifact types, schemas, references, and provenance it can return;
authentication, authorization, tenant, region, and policy requirements;
limits for size, duration, cost, concurrency, and rate;
version, compatibility, deprecation, and feature negotiation; and
who owns the final outcome and who is responsible for reconciliation.

A short name such as review_supplier is not enough. It tells a model what a capability is called, not what it means to rely on it.

Where the familiar comparisons stop helping

A shared protocol is not shared trust

Two runtimes can parse the same messages while one is compromised, misconfigured, deceptive, or simply unreliable. Transport security protects a channel. Authentication identifies a principal. Neither guarantees that the principal’s claims are true.

Trust needs an explicit basis: operator identity, credential chain, certificate or signed metadata, policy, reputation, attestation, audit history, or a human decision. The protocol can carry those signals and enforce required handshakes, but it does not create them by naming a participant.

Discovery is not authorization

A capability card, registry entry, or tool list answers “what is advertised?” It does not answer “may this caller use it for this target with this data?”

Discovery should be treated as untrusted input until identity, scope, policy, and current availability are checked. This is especially important when a model reads the description and chooses an action from it.

A task outlives the message that started it

A message can request work or communicate progress. A task has identity, lifecycle, ownership, state, deadlines, cancellation rules, retry behavior, and a completion condition.

If a remote agent needs another input tomorrow, the system cannot model the first message as a completed request. It needs durable task state and a clear way to resume, expire, or reconcile the work.

An artifact is not truth

A returned report, file, JSON object, or citation bundle is an output of the remote runtime. It may be useful evidence, but it can be stale, incomplete, malformed, unauthorized, or based on an unreliable source.

The artifact needs provenance, schema and version, producer identity, timestamps, source references, and an owner for validation. The requesting agent remains responsible for deciding whether the artifact supports its own claim.

Matching versions can still disagree on meaning

Two runtimes may negotiate protocol version 1 and still disagree about what “complete,” “approved,” “current,” or “high risk” means. Schema compatibility reduces parsing failures; it does not settle domain semantics.

Compatibility testing must include examples, invariants, error cases, side-effect behavior, and outcome expectations. A protocol handshake starts an integration; it does not certify business meaning.

An agent card needs a verifiable trust path

A capability description may say who operates a service, but its claims need a verifiable trust path. Metadata can be copied, altered, or served from an unexpected location.

Bind discovery to the authenticated endpoint and preserve the version and source of the description used in the decision. If identity changes, the system should re-evaluate authority rather than continue from cached text.

Progress is not completion

“Accepted,” “working,” and “artifact available” are different states. A remote runtime may report progress accurately while still failing the task’s postcondition.

The requester should distinguish transport acknowledgement, task completion, artifact production, and domain outcome. The evidence discipline from Post 20 applies across the agent boundary.

Creating, tracking, and verifying a remote task

An interoperable exchange can be implemented as a sequence of explicit boundaries:

Describe. Publish or retrieve a capability description with purpose, inputs, outputs, limits, task behavior, supported protocols, and freshness.
Select. Let the requesting runtime compare the capability with user intent, policy, data sensitivity, cost, latency, and required assurance. Selection is a decision, not a lookup.
Negotiate. Establish protocol version, transport, features, schemas, streaming behavior, artifact references, and error semantics.
Authenticate. Verify the remote principal and bind credentials to the intended audience, endpoint, tenant, and session or task.
Authorize. Evaluate caller, subject, resource, operation, data boundary, policy, approval, and expiry. The remote agent should enforce its own authority boundary too.
Create. Assign a task identity, correlation context, idempotency key, deadline, owner, and initial input. Record the exact capability description and protocol features used.
Coordinate. Exchange messages, progress, requests for additional input, refusals, retries, and cancellation. Preserve ordering and distinguish duplicate delivery from new work.
Transfer artifacts. Return structured content, files, references, or intermediate outputs with schema, provenance, integrity, sensitivity, and retention information.
Verify. Check that the artifact is usable and that the requested domain outcome occurred. Reconcile with a source of truth when the remote system cannot establish the outcome itself.
Close. Record completion, failure, cancellation, expiry, or unresolved state. Preserve who owns follow-up and how the task can be inspected later.

Discovery, negotiation, identity, authority, task exchange, and verification are related boundaries, not one promise made by a protocol.

The sequence does not have to be linear. A task can require renewed authorization, negotiate a new artifact format, pause for human input, or return a partial result. The important property is that each transition is explicit enough to audit, retry, test, and govern.

Following the example through the system

Consider a procurement agent with this request:

Evaluate supplier Northstar Components for onboarding. Return a sourced risk report, flag missing evidence, and recommend whether a human reviewer should approve the supplier.

The procurement agent does not own the compliance data or the risk model. It discovers a compliance-review capability operated by another team.

The exchange might look like this:

The procurement runtime retrieves a capability card. It records the provider identity, endpoint, description version, supported task protocol, input requirements, expected artifacts, limits, and last-updated time.
The runtime compares the capability with policy. The request contains supplier identifiers and financial information, so the data boundary, tenant, region, and permitted purpose are checked before sharing anything.
The runtimes negotiate a protocol version and an artifact schema. They agree that the review is asynchronous, can request missing documents, and returns a report plus an evidence manifest.
The caller authenticates the compliance service and presents a task-bound authorization. The compliance service authenticates the caller and applies its own policy for supplier data.
The caller creates task review-7341 with an idempotency key and a bounded scope: one supplier, one onboarding decision, and a specified review window.
The compliance agent retrieves approved sources, checks sanctions and certifications, and emits progress. It asks for a current insurance certificate rather than silently treating the missing document as a low-risk result.
The compliance agent returns a structured report, an evidence manifest, source timestamps, confidence and coverage fields, and a recommendation. It marks the recommendation as advisory and identifies the human approval boundary.
The procurement agent validates the schema, verifies artifact integrity and producer identity, checks the source freshness and required evidence, and compares the recommendation with onboarding policy.
The procurement system presents a human reviewer with the report, missing evidence, authority basis, and unresolved uncertainty. It does not turn “artifact returned” into “supplier approved.”

The protocol makes this exchange possible, but supplier safety, source reliability, the procurement user’s onboarding authority, and the human-approval requirement remain questions for the participating systems and their governance.

The example also shows why artifacts matter. Beyond its text, the report is a durable object with a task ID, producer, schema version, source references, freshness, sensitivity, integrity information, and a statement of what remains unverified.

A useful capability description says what can be requested, how it behaves, which constraints apply, and who owns the result.

What the team needs to design and operate

Architecture

Treat interoperability as a boundary layer around tasks and artifacts, not as a single client library. Separate discovery, protocol negotiation, identity, authorization, task state, artifact storage, and outcome verification so each can evolve without silently changing the others.

Keep local and remote capabilities distinct. A local tool may share process state and a policy engine. A remote agent requires transport protection, endpoint identity, replay controls, timeout and retry semantics, explicit data transfer, and a durable correlation model.

Use capability registries carefully. The registry is a source of descriptions and routing hints, not a universal source of truth about availability, trust, semantic quality, or authorization.

Engineering

Build conformance tests around behavior, not only JSON schemas. Test duplicate task creation, lost progress, late cancellation, expired authorization, partial artifacts, schema evolution, provider restart, unknown task IDs, malicious capability descriptions, and a successful transport call that produces no domain change.

Make idempotency and correlation first-class. A retry should not create two refunds, two deployments, or two supplier-review tasks because the first response was lost. A task ID should survive worker changes and allow the requester to distinguish an update from a new operation.

Preserve protocol and capability metadata with the evidence record. When an artifact is questioned, the team should be able to reconstruct which description, version, principal, policy, schema, and task state produced it.

Product and UX

Expose the right level of remote-work state. A user should be able to see who is doing the work, what was requested, whether more input is needed, which artifact is ready, what remains uncertain, and who owns the final decision.

Do not show “connected” as “trusted” or “complete.” A healthy protocol connection can coexist with a denied task, an unverified artifact, or a pending human approval.

Operations and governance

Operate the inter-agent network as a distributed system with a model-mediated control plane. Monitor discovery freshness, negotiation failures, auth failures, authorization denials, task age, progress gaps, retries, artifact integrity errors, and unverified outcomes.

Define ownership for every cross-agent task. Someone must own data minimization, policy enforcement, cost, availability, incident response, artifact retention, and final outcome verification. “The other agent did it” is not an accountability model.

Failure Modes

Capability catalog treated as a trusted command source

A model receives a description that contains hidden instructions or overclaims authority. Treat descriptions as data, authenticate their origin, constrain what can be executed, and validate their claims against policy.

Protocol compatibility mistaken for semantic agreement

Both sides accept the same schema while using different meanings for priority, completion, freshness, or risk. Publish examples and invariants, test semantic cases, and record the negotiated contract.

Remote task treated as a synchronous function

The caller times out, retries, and creates duplicate work while the remote task continues. Use durable task identity, idempotency, status reads, cancellation, and reconciliation.

Authorization stops at the first hop

The requesting agent is allowed to act, so it forwards a broad credential to a specialist. Bind authority to the task, audience, resource, operation, expiry, and delegation rules. Require the downstream agent to enforce its own boundary.

Artifact accepted without provenance

The caller stores a polished report but cannot establish who produced it, when its sources were current, or which inputs it used. Carry provenance, integrity, producer identity, schema version, source references, and freshness.

Progress update interpreted as outcome

The remote agent says “completed” because it produced a response, while the business record remains unchanged. Define a postcondition and verify it in the authoritative system.

Discovery cache outlives authority

A cached card points to an old endpoint, expired policy, retired schema, or changed operator. Set freshness rules, bind discovery to identity, invalidate on change, and re-authorize sensitive tasks.

Partial interoperability hidden by a happy path

The first demo works, but cancellation, human input, rate limits, artifact size, version skew, and provider failure are undefined. Treat those behaviors as part of the contract and test them before broad adoption.

Reviewing the handoff between agents

Before one agent delegates work to another, complete this capability exchange card:

Question	Record
Who operates the capability?	Provider, endpoint, authenticated identity, and operator contact
What problem does it solve?	Purpose, boundaries, non-goals, and examples
What inputs are accepted?	Schema, required context, sensitivity, tenant, region, and freshness
What can it change?	Read-only behavior, side effects, resources, limits, and approval requirements
How does the task behave?	Synchronous or asynchronous, states, progress, input requests, cancel, retry, and expiry
Which protocol and features apply?	Transport, version, negotiated extensions, streaming, and error semantics
What authority is required?	Principal, scope, audience, delegation, credential, policy, and re-authorization
What artifacts can it return?	Type, schema, integrity, provenance, source references, sensitivity, and retention
What does completion mean?	Provider completion, requester acceptance, domain postcondition, and unresolved states
Who owns the outcome?	Requester, provider, domain owner, human approver, and reconciliation path
How will it evolve?	Compatibility promise, deprecation, version selection, and change notification
How will it be tested?	Happy path, duplicates, failure, denial, cancellation, stale data, and semantic cases

The card turns “another agent can help” into an integration contract that can be reviewed, implemented, tested, and retired. Labels such as “agent-to-agent,” “capability discovery,” and “task protocol” may be reorganized as platforms converge, and the protocol carrying the exchange may change. Independent systems will still need shared contracts: in a supplier review, both teams need to know what was requested, what may be shared, how progress is recovered, and who evaluates the returned report.

Sources

A2A Protocol specification: defines agent cards, messages, tasks, artifacts, asynchronous operations, authentication, authorization, versioning, idempotency, and error semantics for agent-to-agent interactions.
MCP Tools: defines callable tools, input and output schemas, tool results, annotations, and notification behavior in the Model Context Protocol.
MCP Resources: defines resources, resource templates, content, annotations, subscriptions, and list or read operations for context exchange.
MCP Tasks extension: describes an experimental task primitive for tracking long-running work and retrieving task results.
MCP 2026-07-28 release candidate: records current protocol changes and the separation of task support into an extension while the specification evolves.