Two agents speaking the same protocol can still misunderstand the job
A protocol can let one agent discover another, send a task, receive status, and collect an artifact. It cannot guarantee that both agents mean the same thing by customer, approved, complete, urgent, refundable, or compliant. It does not decide whether the caller is allowed to delegate the task, whether the receiving agent may see the context, or which organization repairs the outcome when a downstream action is wrong.
That is why enterprise agent interoperability is larger than agent-to-agent messaging. A production system needs at least five compatible contracts: transport, capability, semantics, trust, and operation. Transport moves messages. Capability describes what a service can do. Semantics preserve the meaning of data and outcomes. Trust governs identity, delegation, policy, and evidence. Operation covers task state, errors, observability, versioning, recovery, and ownership.
Open protocols are valuable because they reduce repeated plumbing and vendor dependence. Model Context Protocol standardizes common ways for AI applications to work with tools, resources, and related capabilities. Agent2Agent provides a task-oriented pattern for communication between agents. AGNTCY and other efforts address discovery, identity, messaging, and observability around distributed agent ecosystems. None should be interpreted as a universal enterprise authorization or business ontology.
The objective is not to connect every agent to every agent. It is to make a small set of useful interactions portable, testable, secure, and replaceable. Most enterprise workflows need fewer direct agent relationships than architecture diagrams suggest. A durable orchestrator, typed business APIs, and explicit human decisions often create a clearer system than a free-form society of mutually delegating agents.
Bizz API engineering helps organizations turn proprietary and legacy systems into stable capabilities that can serve applications, workflows, and agents through controlled interfaces. The protocol is one adapter around those capabilities. The business contract and authority remain owned by the enterprise, which is what makes future protocol or vendor change survivable.
- Transport contract: how messages, streams, tasks, artifacts, and status move.
- Capability contract: how a tool or agent describes what it can do and under which constraints.
- Semantic contract: what fields, entities, decisions, units, states, and outcomes actually mean.
- Trust contract: who is calling, who they represent, what can be delegated, and what policy permits.
- Operating contract: task ownership, timeout, retry, cancellation, evidence, cost, recovery, and lifecycle.
Integration and interoperability are complements, not moral opposites
Integration connects specific systems so a workflow can deliver value. Interoperability uses shared contracts so more systems can cooperate without redefining every common behavior. A point-to-point API is not automatically technical debt, and a standards-based connection is not automatically robust. The correct design depends on stability, consequence, performance, semantics, and ownership.
A typed internal payment capability with one carefully controlled consumer may be safer than advertising it through a generic agent protocol. A common resource interface may reduce repeated read integrations across many assistants. An A2A task contract may help a parent agent delegate research to several providers. A custom event contract may still be necessary to preserve the organization's exact order state and idempotency rules.
Standards reduce the N-by-M problem only at the layer they standardize. MCP can give different hosts a recognizable way to enumerate and call tools, but each tool still has a schema and business behavior. A2A can normalize task exchange, but a receiving agent still needs a domain contract. OAuth can help establish authorization, but the resource server still needs policy for the requested operation.
Use adapters at the edge and stable business contracts at the center. Protocol clients and servers translate transport and discovery into internal capabilities. Domain services enforce semantics, identity, state, policy, and evidence. This prevents protocol-specific fields from spreading through core applications and makes it possible to support more than one interface without duplicating business rules.
Measure interoperability by substitution and composition. Can a new approved agent use an existing capability without a bespoke rewrite? Can one provider be replaced while the business contract and tests remain? Can two components cooperate while preserving authority and observability? Those outcomes matter more than the number of protocol badges on a product page.
- Use direct integrations when the relationship is narrow, high consequence, performance sensitive, or semantically unique.
- Use open protocols where common discovery, tool access, task exchange, or portability creates real reuse.
- Keep domain policy and business state behind protocol-independent services.
- Test standards implementations for behavior, security, and version compatibility instead of assuming conformance.
- Score interoperability by safe reuse, replacement, composition, and reduced integration effort.
MCP standardizes access to context and tools, not a complete multi-agent society
Model Context Protocol was introduced in 2024 and is now hosted under the Linux Foundation's Agentic AI Foundation. It defines an architecture in which a host uses clients to communicate with servers that expose capabilities such as tools and resources. Its adoption makes it easier for AI applications to discover and invoke a common interface instead of requiring a bespoke connector for every host.
MCP is useful for exposing a read-only knowledge source, an internal search service, a development tool, or a narrow business operation to approved AI hosts. A server can describe a tool and its input schema, then return structured content or errors. The same server can potentially serve several models or agent applications, reducing duplicated integration logic.
MCP does not make every published tool safe for every caller. Tool descriptions are not authorization policy. A valid schema does not prove that the caller may access the account, that the requested action is allowed, or that the model populated fields correctly. Resource servers should authenticate clients, evaluate user or workload authority, validate current state, constrain output, and log evidence independently of the model.
It also does not solve domain semantics. Two servers can expose a tool named create_case while one creates a temporary lead and another opens a regulated complaint. Names and JSON shapes need organization-owned meaning, versioning, and conformance tests. Avoid publishing raw database or administrator functions merely because MCP makes them easy to enumerate.
Treat each MCP server as a security and software-supply-chain component. Verify implementation and SDK versions, transports, process execution, network destinations, dependency integrity, secret handling, logging, and update policy. Local servers can inherit powerful workstation access; remote servers can introduce third-party trust and availability. Least privilege and isolation remain essential.
- Best role: a standard interface from AI hosts to approved tools, resources, and related context capabilities.
- Not provided automatically: business authorization, shared ontology, safe tool behavior, or final-state verification.
- Enterprise pattern: protocol adapter outside, typed domain service and policy inside.
- Security pattern: authenticate, authorize, isolate, constrain egress, protect secrets, validate inputs, and audit outputs.
- Lifecycle pattern: version servers, schemas, SDKs, dependencies, transports, evaluations, and client compatibility.
A2A provides task-oriented agent communication and still needs domain contracts
Agent2Agent began at Google and is now a Linux Foundation project. Its current direction focuses on communication between independent agents through discoverable agent descriptions, tasks, messages, artifacts, status updates, streaming, and related interaction patterns. This is a better conceptual fit for delegation to a remote specialist than treating that specialist as a low-level tool.
A useful A2A interaction might ask an approved logistics agent to assess delivery options and return a structured artifact while the parent workflow tracks task state. The remote agent can operate in its own framework and environment. The caller does not need access to the specialist's internal prompts or tools, and the specialist can report progress or request more information through the protocol's task model.
The protocol does not decide whether the advertised capability is truthful, competent, available under contract, or permitted for the caller. Discovery metadata can help selection, but enterprise use needs an allowlisted registry, ownership, assurance, version, jurisdiction, data class, cost, latency, and evaluation record. Dynamic discovery without admission control can turn convenience into a supply-chain problem.
Task status also needs business interpretation. Protocol-level completed can mean that the remote agent returned an artifact, not that a purchase order changed, a customer received a refund, or a control owner approved the outcome. The parent process should validate artifacts, apply policy, and verify authoritative state before closing the business workflow.
Use A2A where an agent is an independently operated service with meaningful task autonomy and a stable result contract. Use a typed API or MCP tool where the capability is a narrow operation. Use events for state changes that many consumers need. Use durable process orchestration when work waits, escalates, compensates, or requires accountable human tasks.
- Best role: task exchange between independently implemented and operated agents.
- Useful primitives: agent description, messages, task lifecycle, progress, artifacts, streaming, and cancellation patterns.
- Not provided automatically: provider trust, domain meaning, business completion, liability, or outcome quality.
- Enterprise pattern: approved registry, explicit task schema, artifact validation, budgets, and parent-workflow authority.
- Selection rule: remote agent for specialist autonomy; tool for narrow capability; event for state; process for durable work.
ACP has merged into A2A, while AGNTCY addresses adjacent infrastructure
Protocol comparisons age quickly. IBM's Agent Communication Protocol was an early open effort for framework-independent agent communication, but IBM now states that ACP has merged with A2A under the Linux Foundation. A 2026 architecture should not present ACP as a separate competing protocol with an independent enterprise roadmap unless referring to a specific legacy implementation.
AGNTCY is another Linux Foundation project with a broader infrastructure scope. Public project material describes components for federated agent and MCP-server discovery, schemas for capability description, identity, secure low-latency messaging, observability, and testing. These concerns complement MCP and A2A rather than requiring one protocol to solve every layer.
The lesson is architectural humility. A standard can merge, split, revise its data model, change stewardship, or reach production maturity unevenly across SDKs. Avoid writing domain workflows directly against a protocol's raw objects. Put a compatibility layer between external messages and internal task, identity, capability, and evidence models.
Track specifications, not only announcements. Pin supported versions, run conformance tests, monitor security advisories, and record implementation differences. Two vendors can claim A2A support while implementing different versions, transports, authentication profiles, streaming behavior, or extensions. Interoperability begins when their systems pass the same scenario, not when both logos appear on a slide.
Keep a standards watchlist with owners. Review MCP, A2A, AGNTCY, relevant identity and authorization work, and industry-specific data standards according to the organization's roadmap. Adopt standards where they remove real duplication now; design adapters where maturity is uncertain; and avoid waiting for a universal protocol that can encode every business rule.
- Current status: IBM's ACP is part of A2A rather than a separate long-term competitor.
- AGNTCY scope: discovery, capability schemas, identity, messaging, observability, and multi-agent infrastructure.
- Design implication: isolate protocol objects from internal domain and workflow models.
- Procurement implication: verify specification version, SDK, transport, auth profile, extensions, and tested scenarios.
- Governance implication: maintain an owned standards roadmap rather than following product announcements reactively.
Capability discovery needs an admission process before it needs a search box
Discovery answers which agents and tools appear able to perform a task. Enterprise selection must also answer who operates them, what version is deployed, which data they may receive, where they run, how they authenticate, what they cost, what evidence supports their capability, and who responds when they fail. A public description is an advertisement until governance turns it into an approved asset.
Create a registry with stable identifier, owner, provider, purpose, capability schema, input and output classes, protocol and version, endpoint, environment, authentication, allowed callers, data classification, regions, models, tools, dependencies, service objectives, cost policy, evaluations, incidents, and lifecycle state. Distinguish experimental, approved, restricted, deprecated, and revoked assets.
Use semantic capability names rather than broad roles. A finance agent label says little. Capabilities such as explain_invoice_status, prepare_credit_memo_review, or compare_contract_terms expose narrower intent. Include prerequisites, prohibited uses, side effects, approval requirements, expected artifact, timeout, and error model. Discovery can then filter candidates instead of asking another model to infer scope from marketing prose.
Do not let an agent select an unknown provider and send sensitive context dynamically. The orchestration layer should resolve requested capability against policy and an approved registry, then issue the minimum delegated authority. Novel providers can enter a sandbox or evaluation path. Production discovery is constrained selection, not open internet matchmaking.
Monitor registry drift. Endpoints, owners, models, policies, contracts, and evaluations expire. Automatically flag stale attestations, failing conformance, unused capabilities, excessive permissions, and orphaned agents. Retirement should revoke identity, routes, secrets, directory entries, scheduled work, retained data, and dependent workflows.
- Register owner, provider, purpose, version, endpoint, identity, callers, data, region, dependencies, cost, and lifecycle.
- Describe narrow capabilities with schemas, prerequisites, side effects, approvals, outputs, errors, and prohibited use.
- Select only from policy-approved assets for production data and actions.
- Send new or changed providers through conformance, security, quality, performance, and commercial admission.
- Continuously detect stale, failing, overprivileged, unused, deprecated, and orphaned entries.
Shared JSON is not shared meaning
Semantic interoperability is where most cross-system programs become expensive. One system's customer can be a person, household, legal entity, account, subscriber, patient, or organization. One agent's approved may mean a recommendation passed a confidence threshold; another may mean an authorized person signed a decision. If those values cross a boundary without qualification, syntactically valid messages can produce materially wrong work.
Define domain contracts with entity identity, field meaning, type, unit, allowed values, jurisdiction, source, effective time, version, null behavior, confidence, and provenance. Use established industry standards where they fit, but profile them for the use case. A standard with dozens of optional fields still needs implementation guidance and validation.
Separate fact, assertion, inference, recommendation, decision, and action. A source system can assert an address. An agent can infer a likely duplicate. A rules service can determine eligibility. A person can approve an exception. An API can execute a change. The artifact should preserve those distinctions so the receiving component does not treat generated analysis as authoritative state.
Use canonical identifiers or explicit mapping services. Names are not stable keys. Entity resolution should report method, confidence, conflicts, and review requirements rather than silently merging records. Dates need time zone and effective meaning. Money needs currency. Quantities need units. Enumerations need version. Semantic bugs often survive schema validation because the bytes are correct.
Bizz data management services can establish lineage, quality, master data, taxonomy, contracts, and reconciliation beneath agent workflows. This work is less visible than a conversational demo and more reusable. Every application, report, automation, and model benefits when the organization knows what its important data means.
- Define entity, identifier, field, unit, time, jurisdiction, source, confidence, provenance, and version semantics.
- Distinguish observed fact, source assertion, model inference, recommendation, authorized decision, and executed action.
- Profile industry standards for required fields, extensions, validation, and local policy.
- Make entity resolution, conflicts, confidence, and human review explicit rather than silently merging.
- Test semantic invariants even when transport and schema validation pass.
Agent identity must carry delegation without becoming transitive trust
A remote agent request involves several identities: the original user or event, the calling application, the delegating agent, the receiving agent, the tool or service it invokes, and the organization operating each component. Authentication proves an identity or credential. Authorization decides whether that identity may perform the current operation. Delegation explains whose authority is represented and within what scope.
Do not forward a user's broad token through an agent chain. Use token exchange or another approved mechanism to issue short-lived, audience-bound, purpose-bound authority for the exact task or capability. Include tenant, subject, actor, scope, assurance, resource, limits, and expiry where appropriate. Each receiving service should enforce policy rather than trusting the upstream agent's statement that permission exists.
Prevent confused deputy behavior. A powerful internal agent may be authorized to access several systems, but an unprivileged caller should not gain those capabilities by sending it a persuasive task. Bind the request to the originating actor and re-evaluate policy at every consequential boundary. Tool selection by a model never grants permission.
Represent service and provider identity in a verifiable registry. Rotate credentials, revoke compromised agents, constrain network paths, and record ownership. For cross-organization interactions, contracts and technical trust need to align: accepted issuers, keys, certificate or token profiles, data use, subprocessors, incident notice, retention, and liability cannot be inferred from protocol compatibility.
Approvals must bind to exact proposals. If an agent asks a person to approve a supplier, refund, production change, or access grant, record the approver, role, authenticated channel, immutable details, policy, time, and expiry. A later agent cannot reuse that approval after changing the amount, destination, or scope.
- Trace user, client, delegating agent, remote agent, tool identity, operator, and authoritative executor.
- Issue short-lived, audience- and purpose-bound delegated authority instead of forwarding broad credentials.
- Evaluate authorization at every data and action boundary using original actor and current context.
- Register, rotate, constrain, monitor, and revoke agent and service identities across organizations.
- Bind human approval to exact immutable details, role, authentication, policy, and expiry.
Context should be minimized at every handoff, not copied as a transcript
A receiving agent needs enough context to complete its task, not the delegating agent's entire conversation, memory, and tool history. Full-context forwarding leaks unrelated data, carries hostile instructions, exceeds model limits, increases cost, and makes provenance difficult to understand. Build a context compiler that creates a purpose-specific package.
The package should include task objective, structured inputs, approved source references or excerpts, identity and authorization claims appropriate for the receiver, constraints, expected output schema, deadlines, correlation identifiers, and prohibited behavior. Label user content, source evidence, prior agent inference, and system instruction separately. The receiver should not inherit another model's conclusion as fact.
Apply data classification and minimization before transport. Redact or tokenize values the receiver does not need. Enforce region and provider restrictions. Set retention and deletion expectations. If the remote agent needs to retrieve sensitive data, prefer a controlled read capability that applies its own policy over copying a large record into the task.
Treat every returned artifact as untrusted input until validated. It may contain prompt injection, malformed structured data, unsupported assertions, sensitive values, or references to resources the caller cannot access. Parse against a schema, scan or transform content as appropriate, verify provenance, and enforce action policy independently.
Memory should remain local to its purpose and owner. Cross-agent continuity belongs in durable workflow state and approved business records, not a shared vector store with ambiguous permissions. Persist only what the organization intends to retain, with correction, lineage, access, and deletion.
- Compile a minimal task package instead of forwarding transcripts, hidden prompts, or general memory.
- Separate objective, structured facts, source evidence, prior inferences, constraints, identity, and output contract.
- Apply data classification, minimization, region, provider, retention, and deletion policy per receiver.
- Validate and sanitize returned artifacts before they enter prompts, records, tools, or downstream agents.
- Keep durable continuity in owned workflow and business state with explicit access and lifecycle rules.
Task state needs one owner even when several agents participate
A multi-agent workflow can contain protocol tasks, tool calls, asynchronous jobs, human approvals, and business cases. Decide which component owns the end-to-end state. Without a parent workflow or accountable case, each agent knows its local status while nobody can answer whether the business outcome is waiting, denied, duplicated, cancelled, uncertain, or complete.
Use a durable orchestration record with stable correlation and causation. It should persist current step, task identifiers, assigned providers, inputs and artifacts, attempts, deadlines, approvals, tool outcomes, errors, compensation, cost, and final state. A protocol task can be one child of that record. Its completion advances the parent only after output validation and policy.
Define cancellation and timeout semantics. Does cancelling the parent cancel the remote task? What if the remote task already invoked a non-reversible tool? What happens when the response arrives after timeout or after a different provider completed the work? Use version and state checks to reject stale results, and design compensation for side effects that cannot simply disappear.
Avoid recursive delegation without depth, time, cost, and capability limits. A remote agent should disclose or constrain its use of sub-agents according to policy. Otherwise, one approved delegation can expand into unknown providers and data flows. Record the delegation chain and ensure the original authority does not silently widen at each hop.
Use humans as accountable tasks, not vague loops. A review should have an owner, evidence, due date, escalation, and recorded decision. If a person edits a generated artifact, preserve the distinction between generated and approved content. The process resumes from the approved state, not from the remote agent's earlier assertion.
- Choose one parent workflow or case as the authoritative end-to-end task state.
- Correlate child agents, tools, events, humans, attempts, artifacts, cost, and final business status.
- Define timeout, cancellation, late result, stale artifact, compensation, and non-reversible action behavior.
- Bound delegation depth, providers, tools, data, time, spend, and recursion, and preserve the chain.
- Represent human review with ownership, evidence, due date, escalation, authenticated decision, and audit.
Errors must say whether to stop, retry, reconcile, compensate, or ask
A generic failed status is not enough for distributed agent work. Distinguish invalid request, unsupported capability, unauthorized, forbidden by policy, missing information, conflict, stale version, rate limited, temporarily unavailable, deadline exceeded, cancelled, provider error, unsafe output, uncertain action, and permanent business denial. The parent needs a deterministic next step.
Define retry safety for each operation. A read may be safe to repeat. An analysis task may be safe but expensive. A payment, booking, notification, access grant, or record creation needs an idempotency key and destination reconciliation. Retrying a remote agent that hides its tool side effects can duplicate business actions even if the protocol task appears new.
Use bounded exponential backoff and circuit breakers for transient infrastructure errors. Do not retry authorization or policy denial. Ask for missing information through an explicit state. Route semantic conflicts to a qualified person or source owner. Stop on malformed or hostile artifacts. The model can help explain an error, but policy should determine the category and permitted response.
Design compensation at the business level. Cancelling a protocol task does not recall an email or undo a shipment. Record compensating capabilities, required approval, deadlines, and residual consequences. Some actions cannot be reversed and should require stronger confirmation or human authority before the first execution.
Test partial failure across boundaries. The remote agent can complete while its status callback fails. The artifact can arrive while the parent is down. An action can succeed while acknowledgement times out. A human can approve after the task expires. Interoperability quality is the ability to reconcile these states without guessing.
- Standardize actionable error classes while preserving provider detail for diagnosis.
- Annotate every capability with retry, idempotency, side-effect, reversibility, and reconciliation behavior.
- Use policy to choose stop, retry, circuit break, request information, escalate, compensate, or reconcile.
- Model business compensation independently of message or task cancellation.
- Exercise lost callbacks, late artifacts, duplicate deliveries, uncertain actions, expired approvals, and recovery.
Distributed traces need business causality, not a bag of vendor transcripts
Every platform will produce its own logs and agent traces. Enterprise observability must connect them into one journey with a stable business correlation identifier. Capture initiating actor, parent workflow, delegated task, provider, protocol version, source references, model and prompt version where available, tool calls, policy decisions, approvals, artifacts, final destination state, cost, and human intervention.
Use causation as well as correlation. A parent request created a task; the task produced an artifact; the artifact led to a proposal; approval authorized an action; the action changed a record. That chain lets an operator determine what to repair when an early artifact is wrong. Timestamp proximity is not enough in a busy distributed system.
Normalize a minimum event and span model while retaining links to provider-specific evidence. Do not force every platform to emit identical internal reasoning. Capture inputs and outputs at contract boundaries, versions, decisions, and state transitions. Sensitive content should be referenced, redacted, tokenized, or stored under tighter access rather than copied into a central trace by default.
Provide engineering, operations, risk, and business views. Engineers need transport, SDK, latency, and error details. Operators need pending, failed, uncertain, and compensating work. Risk teams need identity, policy, data, provider, and approval evidence. Business owners need verified outcomes, corrections, human effort, service levels, and cost.
Test an incident across vendors. Identify all workflows affected by a compromised remote provider, revoke it, stop new delegation, contain downstream actions, repair records, notify owners, and prove safe restoration. If each vendor can explain only its own segment, the enterprise still lacks interoperable operations.
- Carry stable journey, task, attempt, actor, provider, capability, and version identifiers across boundaries.
- Record causation from request through artifact, proposal, approval, action, and final state.
- Normalize contract-boundary evidence while preserving links to protected provider-specific details.
- Minimize sensitive telemetry and enforce separate access, retention, and audit for content.
- Rehearse cross-provider detection, revocation, containment, repair, notification, and restoration.
More connections expand the blast radius of one manipulated instruction
Interoperability turns local failures into supply-chain failures. A hostile document processed by one agent can be summarized into an instruction, passed to another agent, and used to invoke a tool. A compromised directory can advertise a fraudulent provider. An overbroad delegated token can let a remote service act beyond the user's authority. A vulnerable SDK can affect many clients or servers at once.
Treat content, messages, capability metadata, and returned artifacts as untrusted. Separate instruction from data structurally. Allowlist providers and tools. Validate schemas and destinations. Apply egress controls. Limit the receiver's context and the tool's authority. A protocol handshake never makes content trustworthy.
Threat-model registry poisoning, identity spoofing, downgrade, replay, task tampering, artifact substitution, indirect prompt injection, data exfiltration, excessive delegation, tool misuse, denial of wallet, malicious extensions, and observability gaps. Include human operators and configuration systems, because changing a directory entry or auth policy can be more powerful than attacking a model.
Use Bizz cybersecurity engineering to place agent protocols inside existing zero-trust, application security, supply-chain, identity, network, secrets, detection, and incident disciplines. Agents introduce new paths, but they do not invalidate proven controls. Enforce policy at resource and action boundaries where a model cannot negotiate it away.
Stage trust. A new provider may receive synthetic data and no write tools. After conformance, security, and quality evidence, it can handle a restricted read workflow. Consequential actions require stronger assurance and monitoring. Trust should be revocable by provider, capability, data class, region, and workflow without disabling the entire agent estate.
- Assume messages, metadata, resources, tool descriptions, and artifacts can carry hostile content.
- Allowlist identities, providers, endpoints, capabilities, tools, data classes, destinations, and protocol versions.
- Threat-model registry, identity, delegation, replay, downgrade, injection, exfiltration, tool abuse, cost, and SDK supply chain.
- Enforce resource authorization and action policy outside agent reasoning at every boundary.
- Grant staged, narrow, revocable trust and support capability-level containment.
Versioning and conformance turn an open protocol into a dependable product
Pin the protocol and schema versions each component supports. Define negotiation and downgrade policy. Unknown versions should fail safely or route through an adapter, not be accepted optimistically. Extensions need namespaces, owners, compatibility tests, and a path to removal. Proprietary extensions can recreate lock-in under an open envelope if core behavior depends on them.
Create conformance suites at several layers. Protocol tests validate required messages, task transitions, streaming, cancellation, and errors. Security tests validate authentication, authorization, replay, input limits, and untrusted content. Domain tests validate semantics and invariants. Operational tests validate timeout, retry, recovery, tracing, and cost.
Use contract testing between producer and consumer versions. A remote agent can change artifact fields or meaning without breaking the transport. Consumer-driven tests make those expectations visible. Maintain representative fixtures and invalid cases. Run the suite against vendor updates and self-hosted deployments before promotion.
Measure portability through a replacement exercise. Implement a second tool server or remote agent behind the same internal contract and run the evaluation. Record where proprietary features, prompts, identity, data, observability, or commercial terms prevent substitution. Interoperability claims become credible when replacement cost is known.
Plan deprecation. Publish notice, affected workflows, migration, dual-run window, owner, and cutoff. Durable tasks may outlive a protocol or agent version; decide whether they remain on the old implementation or migrate. Store enough version and state information to resume them correctly after deployment changes.
- Pin and negotiate protocol, schema, capability, and extension versions with safe downgrade policy.
- Test protocol, security, semantics, operations, and cost as separate conformance layers.
- Use producer-consumer contracts for artifact fields and meaning beyond transport validity.
- Prove portability by replacing a provider behind the internal contract and rerunning private evaluations.
- Deprecate through notice, migration, dual operation, in-flight task policy, ownership, and cutoff.
Legacy systems need bounded adapters, not direct agent access
Mainframes, ERP platforms, old databases, desktop applications, and proprietary services hold critical enterprise state. They do not need to become protocol-native. Place an anti-corruption layer around them that exposes narrow business capabilities, translates data and errors, enforces authorization, adds idempotency, and emits modern events. The agent should never receive a generic database credential or terminal session by default.
Use read models and APIs for current state where possible. Event streams can distribute approved state changes without every agent polling the source. Data virtualization can support queries but still needs semantic and access policy. Retrieval indexes are useful for unstructured reference information, not transactional truth. RPA can bridge an interface when no API exists, but it should sit behind the same typed capability and verification contract.
Bizz enterprise software development can modernize the boundary incrementally. The organization does not have to replace a stable core system before building interoperable experiences. Start with the highest-value reads and actions, add observability and reconciliation, and let applications and agents share the improved services.
Protect capacity and transaction integrity. Legacy systems may not tolerate agent fan-out or repeated exploratory calls. Cache only where freshness permits, batch approved reads, rate-limit per workflow, and require the parent to supply known identifiers. A planning loop should not discover production records through broad search.
Use the adapter as the authority boundary. Protocol servers and remote agents can change, but the adapter maintains business semantics and policy. When the legacy system is later replaced, consumers continue using the same capability while implementation and migration happen behind it. That is durable interoperability.
- Wrap legacy systems in narrow business capabilities instead of exposing database, terminal, or administrator access.
- Use APIs for actions, events for state changes, approved read models for queries, and retrieval for reference content.
- Place RPA behind a typed, observed, idempotent capability when no reliable API exists.
- Protect old systems with identifiers, rate limits, batching, caching rules, backpressure, and reconciliation.
- Keep protocol adaptation outside the domain boundary so core replacement does not break every agent.
A practical interoperable architecture has fewer intelligent hops than most diagrams
Start with an experience or event and a durable workflow owner. The parent resolves purpose, identity, policy, and current state. It invokes deterministic services for exact operations. It uses MCP where several approved AI hosts need standardized access to a tool or resource. It uses A2A where an independently operated specialist agent should receive and manage a task.
An approved registry maps capability to providers and constraints. An identity broker issues narrow delegated authority. A context compiler builds minimal task packages. A policy enforcement point gates every data and action boundary. Domain adapters protect systems of record. An event and trace fabric carries state and evidence. Human work enters as authenticated tasks rather than another chat message.
Avoid chains that add agents without distinct capability. A researcher, summarizer, planner, verifier, and formatter can be separate model calls inside one controlled service rather than five network identities with separate memory and failure. Split components when ownership, scaling, trust, model, data, or deployment genuinely differ. Every boundary should buy something worth its latency and operating cost.
Use a deterministic parent for consequence. A remote agent may return recommendations, candidate plans, or structured artifacts. The parent validates schema and evidence, applies rules, obtains approval, and invokes the authoritative action. This preserves interoperability without making an agent's self-reported completion equivalent to a business outcome.
Design for provider replacement. The internal task contract should be stable, private evaluations should run against every provider, and traces should expose differences. Keep prompts, mappings, and proprietary extensions at the adapter. Portability is not zero work; it is work concentrated at a known boundary rather than spread through every workflow.
- Durable parent: owns business state, deadlines, approval, errors, compensation, and completion.
- MCP edge: exposes approved tools and context consistently to multiple AI hosts.
- A2A edge: delegates bounded tasks to independently operated specialist agents.
- Trust plane: registry, identity, delegation, policy, data classification, admission, and revocation.
- Domain plane: typed services, records, events, semantics, idempotency, and authoritative verification.
- Evidence plane: evaluation, traces, cost, incidents, conformance, versions, and provider portability.
A proof should replace one provider and survive one broken handoff
Choose one workflow where a remote specialist adds real value. Define the parent state, approved sources, task schema, artifact schema, identity, delegated authority, deadline, budget, allowed providers, validation, human route, and final business outcome. Establish a baseline for current time, quality, manual effort, failures, and cost.
Implement the same internal contract with two providers or one provider and a controlled test double. Run normal, incomplete, conflicting, unauthorized, delayed, malformed, hostile, duplicated, cancelled, and unavailable scenarios. Test version mismatch, expired identity, revoked provider, late artifact, excessive sub-delegation, and a downstream action whose acknowledgement is lost.
Verify semantics with domain experts. Check identity mapping, units, dates, source provenance, confidence, and the difference between recommendation and decision. Schema-valid nonsense should fail. Verify security with prompt injection, data exfiltration, registry poisoning, replay, tool misuse, and provider compromise scenarios.
Use Bizz software QA services to automate protocol and domain conformance, end-to-end state, failure recovery, and provider comparison. Measure task success, artifact quality, human correction, business completion, p95 latency, provider and model cost, retries, trace completeness, and operator time.
Perform the replacement. Switch providers through configuration or a bounded adapter, rerun the suite, and document gaps. Then simulate an incident: revoke one provider while tasks are active, stop new data flow, finish or cancel safely, find affected outcomes, and restore with evidence. A demo that cannot do this has connectivity, not an interoperable operating system.
- Define one parent workflow, remote capability, task and artifact contract, authority, budget, and final outcome.
- Test normal, semantic, security, version, identity, timing, duplicate, cancellation, and provider-failure cases.
- Validate meaning and authoritative state in addition to message and schema conformance.
- Compare two providers using the same private evaluation, traces, operations, and cost model.
- Rehearse provider revocation, active-task containment, impact analysis, repair, and restoration.
A ninety-day interoperability program should create contracts before an agent marketplace
In days one through fifteen, inventory agents, tools, workflows, service identities, data sources, protocols, owners, and business outcomes. Select one cross-boundary workflow and map current integration and failure. Identify the source of truth, authority, data class, semantics, and final state. Avoid starting with a universal registry that has no admitted assets or useful workflow.
In days sixteen through thirty, define internal capability, task, artifact, error, trace, identity, and delegation contracts. Establish a lightweight registry and lifecycle states. Choose where MCP, A2A, direct API, event, and process orchestration each fit. Threat-model the boundary and define private conformance and domain evaluation cases.
In days thirty-one through fifty-five, implement one provider adapter, one domain capability, durable parent state, minimal context packaging, policy enforcement, and end-to-end tracing. Use synthetic or approved data first. Add a human review and clear uncertain-action state. Do not grant broad write access to accelerate the demo.
In days fifty-six through seventy, implement a second provider or replacement path and run protocol, semantic, security, resilience, and cost tests. Exercise version mismatch, revocation, hostile content, late responses, duplicate messages, model change, and destination uncertainty. Fix the internal contracts where providers expose hidden assumptions.
In days seventy-one through ninety, pilot with bounded users and volume. Monitor verified outcomes, corrections, delegation, data exposure, provider performance, cost, and operator work. Rehearse one cross-provider incident. Publish the accepted operating envelope, residual risks, standards roadmap, and next capability based on evidence rather than the desire to connect everything.
- Days 1-15: inventory assets and choose one valuable cross-boundary workflow with known authority and state.
- Days 16-30: define protocol-independent capability, task, artifact, error, identity, trace, and lifecycle contracts.
- Days 31-55: build one adapter and provider path with durable state, minimal context, policy, human review, and traces.
- Days 56-70: add replacement, conformance, semantic, security, failure, revocation, and cost evidence.
- Days 71-90: bounded pilot, incident exercise, operating envelope, residual risk, and standards roadmap.
Interoperability is the ability to change safely, not the absence of adapters
No enterprise will eliminate integration work. Business systems embody different concepts, permissions, timelines, and consequences. Open protocols can make common connections and task exchange cheaper, but the organization still needs domain meaning and accountability. The goal is to concentrate custom work in stable, owned boundaries where it can be tested and reused.
A mature architecture can support several agent vendors without sharing every memory or prompt. It can expose one internal capability through API and MCP. It can delegate a specialist task through A2A while a parent workflow owns the outcome. It can use an AGNTCY component where discovery or observability fits. It can remove any of those adapters without changing the meaning of approved or paid.
Procurement should ask providers for exact protocol versions, authentication profiles, extensions, conformance evidence, data flow, task semantics, observability, export, and deprecation policy. Roadmap support is not current support. Open-protocol support is not open data or easy exit. Verify replacement through a proof before a critical workflow depends on proprietary behavior.
Governance should approve capabilities, not vague agents. Register which actor can invoke which capability with which data and action scope, through which providers, under what budget and evidence. This scales more coherently than trying to approve every possible conversation between autonomous entities.
The durable advantage is optionality with operational truth. An organization can adopt a better model, agent, or protocol without losing identity, semantics, policy, state, tests, and traces. That is what allows AI capability to evolve quickly while the business remains explainable and recoverable.
- Standards reduce repeated plumbing but do not remove domain integration, policy, or accountability.
- Own semantic, identity, task, action, evidence, and lifecycle contracts independently of providers.
- Use adapters deliberately so protocol and vendor change is concentrated and testable.
- Approve narrow capabilities and data scopes rather than uncontrolled agent-to-agent conversation.
- Measure interoperability by safe evolution, substitution, recovery, and preserved business truth.
FAQ
What is AI agent interoperability?
AI agent interoperability is the ability of tools, agents, workflows, and systems from different providers to cooperate through compatible transport, capability, semantic, trust, and operating contracts. It includes discovery and communication, but also shared meaning, identity, delegation, authorization, task state, errors, observability, versioning, and recovery.
What is the difference between MCP and A2A?
MCP is primarily a standard interface between AI hosts and servers that expose tools, resources, and related capabilities. A2A is task-oriented communication between independently operated agents, with agent descriptions, messages, task state, and artifacts. They can complement each other. Neither automatically supplies enterprise business authorization, domain semantics, or final-state verification.
Is IBM's Agent Communication Protocol still separate from A2A?
No. IBM's current public material states that ACP has merged with A2A under the Linux Foundation. Older comparisons that present ACP as an independent competing protocol are outdated. Enterprises should verify current A2A specification and SDK versions and isolate protocol details behind internal contracts because the standards landscape continues to evolve.
Do open agent protocols eliminate vendor lock-in?
They can reduce integration lock-in at the layers they standardize, but they do not guarantee portable prompts, memory, identity, evaluations, data, workflow state, proprietary extensions, operations, or commercial terms. Prove portability by implementing or testing a second provider behind the same internal contract and measuring the remaining replacement work.
How should an enterprise secure agent-to-agent workflows?
Allowlist providers and capabilities, authenticate every workload, issue narrow delegated authority, enforce authorization at each resource and action, minimize context, validate returned artifacts, constrain tools and egress, protect registries and secrets, bound recursion and cost, maintain causal traces, and rehearse provider revocation, containment, authoritative-state repair, and recovery.
Example: a manufacturer coordinates maintenance specialists without sharing plant-wide authority
A durable maintenance case delegates bounded tasks across three agent providers
A manufacturer operates plants with equipment from several vendors. Its maintenance platform owns work orders, an internal agent summarizes sensor and service history, one equipment vendor offers a diagnostic agent, and a logistics provider offers a parts-availability agent. A prototype forwards the entire work-order transcript between them and lets the internal agent decide whether to create an expedited shipment. Security and operations reject the design because identity, data scope, and final action are unclear.
Bizz redesigns the workflow around the maintenance case as authoritative state. The internal application retrieves current equipment, sensor, warranty, and work-order data through typed services. A context compiler creates separate task packages. The diagnostic provider receives the machine model, approved telemetry window, fault code, and maintenance objective, but not employee notes or unrelated plant data. The logistics agent receives an approved part identifier and destination region only after a technician validates the recommendation.
The diagnostic task uses A2A through an adapter and returns a structured artifact with candidate cause, evidence references, confidence, safety limitations, and recommended inspection. The adapter validates schema and labels every statement as provider analysis, not confirmed fact. MCP exposes narrow internal read tools to the plant's approved AI host, while domain APIs retain business policy and system authority.
A technician reviews the evidence and chooses an inspection or part request. Exact approval binds part, quantity, plant, urgency, cost limit, and destination. A logistics API prepares available options, and procurement policy decides whether expedited shipping needs a manager. The ERP executes the approved order idempotently and confirms final state. No remote agent receives a purchasing credential.
The proof swaps the diagnostic provider for a second implementation, tests protocol and semantic compatibility, revokes one provider during an active task, injects hostile text into a vendor manual, duplicates a callback, delays a result beyond the case deadline, and times out the ERP after submission. Success is measured by correct case progression, technician correction, duplicate prevention, repair time, provider replacement effort, data minimization, and cost per resolved maintenance event.
- State boundary: the maintenance case, not any agent memory, owns end-to-end status and deadlines.
- Data boundary: each provider receives a distinct minimum task package for its approved purpose.
- Authority boundary: remote agents return analysis; technicians and deterministic policy authorize action.
- Protocol boundary: A2A and MCP adapters remain replaceable around organization-owned domain contracts.
- Evidence boundary: causal traces connect tasks, artifacts, approval, ERP action, final state, and provider version.