What Is Agent-to-Agent Communication? Discovery, Tasks, and Results

§ 01What Is Agent-to-Agent Communication?

Agent-to-agent communication gives two agentic systems a common operating contract for work that may be dynamic, stateful, asynchronous, or owned by different teams.

The calling side needs to know more than an endpoint name. It must determine:

• who operates the remote agent;
• what the agent says it can do;
• which input and output modes it supports;
• how the caller authenticates;
• whether the requested task is allowed;
• how work is identified and tracked;
• what the remote agent needs before it can proceed;
• how progress and interruption are represented;
• where the result will appear;
• and how failure, cancellation, or expiry is handled.

The receiving side has a corresponding obligation. It must be able to reject an unsupported request, ask for missing input, work inside the granted boundary, report state honestly, and return a result that the caller can evaluate.

The table shows why a chat transcript cannot serve as the complete interface. Chat may carry instructions and updates, but the surrounding layers make the work attributable, bounded, observable, and recoverable.

The formal A2A Protocol is narrower than the category

“Agent-to-agent communication” is a general architecture category. The Agent2Agent Protocol specification defines a particular open standard for communication between independent agent systems. Its current released specification is version 1.0.0.

The standard defines data objects such as an AgentCard, Task, Message, Part, Artifact, and Extension. It also defines operations for sending messages, streaming work, retrieving or listing tasks, subscribing to updates, canceling tasks, and retrieving agent cards.

Google’s original A2A announcement introduced the same operating sequence through capability discovery, task management, progress updates, and result artifacts. The current specification is the authoritative source for implementation details.

A company can build agent-to-agent communication through internal APIs, queues, events, shared task records, or another protocol. Those systems belong to the broader category without automatically implementing A2A. Compatibility is an engineering claim that requires the expected card, transport, version, operations, states, errors, authentication behavior, and conformance tests.

The remote implementation can remain opaque

Interoperability does not require the caller to know the receiver’s model, prompts, framework, or tool sequence. It requires an observable contract at the boundary.

That contract should reveal what the caller needs to make a safe decision:

• declared capabilities and versions;
• supported input and output modes;
• authentication requirements;
• current task state;
• requested clarification or authorization;
• result artifacts;
• evidence and provenance;
• errors and terminal outcome;
• and enough operational events to investigate a defect.

Implementation confidentiality and operational accountability can coexist. The receiver may withhold proprietary implementation details while still exposing a testable result and a complete boundary record.

§ 02How Is Agent-to-Agent Communication Different From Tool Calls, APIs, MCP, and Orchestration?

The same network request can hide several different operating relationships. Classifying the relationship before choosing the protocol prevents a simple function from being treated like an independent worker - or a remote worker from receiving the broad authority of its caller.

This comparison is about operational semantics, not marketing labels. A vendor may call a remote service an “agent” even when the integration behaves like a single tool. Conversely, a remote service may use a conventional API transport while still managing a negotiated, long-running task.

The communication contract does not choose the control structure. The AI agent orchestration pattern comparison maps sequential, routing, parallel, manager, peer, and evaluator designs to dependency, latency, review, and failure-containment needs.

One orchestrator calling tools is not peer communication

OpenAI’s practical guide to building agents separates a manager pattern from a decentralized handoff pattern. In the manager pattern, a central agent invokes specialists as tools and keeps control of workflow execution and the user interaction. In the decentralized pattern, execution can transfer between agents.

The manager pattern may be the better design. It produces one control owner, a simpler user experience, and easier synthesis. It does not need to be renamed peer-to-peer communication.

The operational comparison of agent handoffs versus agents as tools makes that ownership test explicit across context, authority, user interaction, recovery, and closure.

A remote participant begins to behave more like an independent agent when it can:

• advertise a changing set of capabilities;
• interpret an outcome rather than execute one fixed operation;
• accept, reject, or clarify the work;
• maintain task state beyond one request;
• choose its own execution method;
• return one or more result artifacts;
• and operate under an identity and policy domain distinct from the caller.

No single item proves “agentness.” Together, they indicate that the boundary needs task semantics rather than only function semantics.

MCP and A2A solve different primary problems

The official Model Context Protocol architecture describes an MCP host connecting to servers that expose tools, resources, and prompts. MCP standardizes the exchange of context and callable primitives between an AI application and those servers.

The A2A project describes A2A as communication between independent agents that discover one another, delegate tasks, and share results. The protocols are complementary. An agent can use MCP to reach a database, repository, or application and use A2A to collaborate with a remote specialist that has its own tools and task lifecycle.

A useful rule is:

• use a tool interface when the caller knows the operation and owns the workflow;
• use an agent interface when the caller knows the desired outcome but the receiver must manage meaningful parts of the work;
• use both when a remote agent needs its own tools to complete the accepted task.

§ 03What Information Do AI Agents Exchange?

An agent interaction should carry the smallest complete task contract. Sending less creates ambiguity. Sending the caller’s entire context, memory, or credentials creates unnecessary exposure.

These are logical field groups. A protocol may represent them across a card, message, task, policy service, artifact store, and audit log rather than one oversized payload.

Minimize context by reference

The receiver rarely needs the complete conversation that led to a task. It needs the facts and constraints required to perform its part correctly.

A good packet can include:

• a concise objective;
• approved source or artifact IDs;
• exact versions;
• relevant decisions already made;
• unresolved questions;
• prohibited data and actions;
• output schema;
• deadline and budget;
• and acceptance tests.

Large source files can remain in controlled storage. The task can pass authorized references instead of copying the files into multiple agent histories. This improves version control and makes access revocation possible.

Separate descriptive content from executable authority

Text inside a task may say, “Update the customer record.” That sentence is a request, not permission.

Authority should be enforced by independent controls such as:

• the receiver’s own identity;
• a task-scoped authorization grant;
• destination-system policy;
• data classification;
• action limits;
• approval requirements;
• and time or spend ceilings.

The receiver should not gain an action merely because the caller described it in natural language. Content explains the requested work; policy determines what execution is allowed.

§ 04How Do Agents Discover Each Other?

Discovery answers “Who claims to provide this capability?” Selection answers “Which eligible agent should receive this task?” The first question can be open and dynamic. The second should be policy-bound.

The formal A2A standard uses an Agent Card: a JSON document that describes the remote server’s identity, interfaces, capabilities, skills, supported media types, and authentication requirements. Cards can be found at a well-known URI, through a registry, or through direct configuration.

The card narrows discovery, but it does not establish trust by itself. A description such as “expert financial analyst” is provider-supplied content. The caller still needs identity verification, allowlist or procurement status, policy eligibility, and test evidence for the requested task.

Apply eligibility before ranking

A safe router first removes receivers that cannot perform the work within policy. It can then rank the remaining candidates by quality, latency, capacity, cost, or another business preference.

Eligibility gates should cover:

• verified identity and endpoint;
• permitted provider or owner;
• compatible protocol and capability version;
• required data classification;
• minimum tool and source access;
• output-mode compatibility;
• current capacity and deadline fit;
• task risk tier;
• geographic or contractual restrictions;
• and recent evaluation evidence.

Ranking an ineligible agent is a design error. A fast receiver without permission or a high-scoring receiver with an incompatible output mode cannot become safe through a weighted score.

Revalidate changing capabilities

Agent capabilities can change after a model, tool, prompt, policy, data source, or provider update. Cache discovery records for efficiency, but attach expiry and version rules.

Re-run eligibility when:

• the card or agent version changes;
• the task has a higher risk tier;
• the receiver requests an unlisted capability;
• a prior evaluation expires;
• an incident changes trust status;
• or the required output schema changes.

Discovery is therefore part registry, part policy decision, and part evidence review.

§ 05How Does an Agent Task Move From Request to Completion?

State makes asynchronous work observable. Without it, the caller sees only silence followed by a response - or silence followed by a timeout - and cannot distinguish queue delay, missing input, active work, authorization failure, or lost delivery.

The A2A specification defines task states including submitted, working, input required, authorization required, completed, failed, canceled, and rejected. An internal system may use different names, but it needs equivalent distinctions.

“Delivered” is a useful business state even when a wire protocol moves directly from working to completed. The receiver can complete its task while the caller still needs to inspect and accept the result for a wider business process.

Acceptance may sit above protocol acknowledgement

Protocol acknowledgement means the remote endpoint received a request. It does not necessarily mean the receiver accepted the exact scope, authority, deadline, price, or quality rule.

Consequential workflows can add a business acceptance event:

• accept with the agreed contract version;
• reject with a typed reason;
• or clarification required with specific missing fields.

Work should not begin under an ambiguous contract. If the receiver’s understanding changes, issue a new contract version and preserve the prior one.

State transitions need ordered, idempotent events

Each transition should include:

• task ID;
• event ID;
• prior and new state;
• contract version;
• agent identity;
• timestamp;
• reason or status code;
• artifact references, if any;
• and an idempotency or deduplication key for retryable operations.

The receiver must reject impossible transitions, such as moving a failed task back to working without a new attempt. The caller must tolerate duplicated delivery events without repeating an external action.

§ 06Why Are Messages and Artifacts Different?

Messages coordinate the work. Artifacts carry durable results.

The A2A specification uses messages to initiate tasks, request clarification, provide additional input, and report status. It recommends returning task outputs as artifacts and warns that transient messages may not be preserved or replayed after a disconnection.

If the valuable output exists only in a status sentence, downstream systems cannot reliably retrieve, version, verify, or reuse it. A named artifact provides a stable boundary.

A result artifact needs more than a file

A durable artifact record should include:

• unique artifact ID;
• task and context IDs;
• type and media type;
• schema version;
• producer identity and version;
• creation time;
• content or controlled retrieval reference;
• checksum or integrity value where appropriate;
• source and evidence references;
• sensitivity and retention class;
• quality or test results;
• known limitations;
• and supersession history.

For a research report, the artifact may be a document plus a structured source ledger. For code work, it may be a patch, test report, and commit reference. For a dashboard, it may include both the rendered view and the underlying data snapshot.

Treat partial artifacts explicitly

Long tasks may produce useful intermediate results. Mark them as partial, provisional, or superseded rather than allowing the caller to mistake them for final output.

The contract should say:

• whether partial delivery is allowed;
• which fields can be incomplete;
• whether downstream use is prohibited;
• when a newer version replaces an older one;
• and who can promote a provisional artifact to accepted status.

This avoids a common failure in which an early draft silently becomes the business record.

§ 07Which Relationship Should the Agents Use?

Communication does not define ownership on its own. The task must name the relationship.

The AI agent task delegation protocol is appropriate when the sender keeps the parent outcome and expects a bounded contribution back. The complete AI agent handoff protocol applies when ownership of a defined scope must move.

Do not let ownership change silently

Ambiguous language creates duplicate action and abandoned work:

• “Take care of this” may sound like a handoff to the receiver and a delegation to the sender.
• “Review and fix” combines an independent evaluation with production authority.
• “Handle the customer” does not say who owns the user interaction or final closure.

Use explicit relationship fields and verbs:

• consult: return advice; requester decides;
• delegate: produce a child artifact; delegator integrates;
• review: return pass, fail, or revision required;
• handoff: accept ownership and interaction;
• escalate: decide the named exception;
• notify: acknowledge information; no work ownership created.

The transport can stay the same while the semantics change. That is why ownership belongs in the task contract.

§ 08How Should Identity, Authentication, and Authority Work?

Identity, authentication, authorization, and trust answer different questions.

Successful authentication does not make an artifact correct. A trusted provider can return a stale result. An accurate result does not prove the receiver had permission to access the underlying data.

Recalculate authority at every agent boundary

The receiver’s effective authority should be the intersection of:

• the initiating principal’s allowed purpose;
• the sender’s right to delegate;
• the receiver’s own role permission;
• the task-scoped grant;
• destination-system policy;
• required approval state;
• and remaining time, spend, and action limits.

The sender’s credentials should not be copied into the task. If the receiver needs access, provide a narrow reference, delegated token, or brokered operation that expires with the task.

Authorization applies to reads as well as writes

Agent systems often focus on risky actions while under-protecting retrieval. Yet task lists, artifact histories, agent cards, and status messages can expose customer names, objectives, system structure, or internal incidents.

Check authorization before:

• listing or retrieving tasks;
• reading artifacts or message history;
• subscribing to updates;
• requesting an extended capability card;
• canceling work;
• answering an input request;
• changing delivery destinations;
• or delegating the task again.

The A2A specification requires servers to scope task operations to the authenticated caller’s authorization boundary. An internal protocol should do the same even if it uses a different object model.

§ 09How Do Agents Handle Long-Running and Interrupted Work?

Remote agent work may take seconds, hours, or longer. The communication layer should not force every task into one blocking request.

The choice affects delivery, not ownership. A pushed notification still needs a task ID, authorized retrieval path, deduplication, and a terminal state.

Design for disconnection

After a client reconnects, it should be able to:

• authenticate again;
• retrieve the current task state;
• determine which events or artifact versions it missed;
• resume a supported subscription;
• avoid replaying accepted instructions;
• and fetch the final result independently of a prior stream.

Do not assume every progress message will be replayed. Put critical information in durable task fields, input requests, authorization requests, and artifacts.

Cancellation is a request, not proof of reversal

A cancellation request may arrive after an external action or after the task has already completed. The receiver should return the resulting state and report irreversible side effects.

Define:

• which states are cancelable;
• how quickly the receiver must stop;
• whether child work is canceled recursively;
• what happens to partial artifacts;
• which reservations or temporary grants are released;
• and how the caller verifies that writes did not continue.

For consequential operations, design compensation separately. Canceling “book travel” may stop future work without reversing a purchase that already occurred.

§ 10What Can Go Wrong in Agent-to-Agent Communication?

Adding an agent boundary creates new failure paths in discovery, identity, content, state, authority, delivery, and closure. More participants also create more routes through which one bad result can spread.

The official A2A samples repository warns that external Agent Cards, messages, artifacts, and task statuses should all be handled as untrusted input. A malicious capability description can become an injection path if it is inserted into a model’s instructions without validation.

Validate at every boundary

The caller should validate:

• endpoint and agent identity;
• protocol and contract version;
• payload schema and size;
• allowed media types;
• source and artifact references;
• task and tenant correlation;
• requested action against policy;
• returned artifact integrity;
• evidence and domain quality;
• and terminal state against the acceptance rule.

The receiver should perform equivalent checks on incoming tasks. Authentication on the network connection is not a substitute for validating the content.

Contain downstream effects

An unverified result should not automatically:

• enter durable shared memory;
• update a system of record;
• trigger another external action;
• change permissions;
• become training or retrieval data;
• or be sent to a customer.

The broader multi-agent failure containment model adds chain depth, retry budgets, kill paths, independent checks, and contamination controls. Communication is reliable only when a defective exchange remains bounded.

§ 11How Do You Evaluate Agent-to-Agent Communication?

Evaluate the boundary, not only the intelligence of each participant. Two strong agents can still fail because discovery, authority, state, or artifacts do not line up.

No universal threshold fits every workflow. A research artifact and a payment action have different consequence, latency, and evidence requirements.

Use a small but adversarial test pack

An illustrative 24-case pack can cover:

• 4 normal tasks across supported input and output modes;
• 3 unsupported or misadvertised capability requests;
• 3 missing-input and clarification cases;
• 3 permission or tenant-boundary failures;
• 2 protocol or schema-version mismatches;
• 2 duplicated request or event cases;
• 2 stream or webhook disconnections;
• 2 timeout and cancellation cases;
• 2 malicious card, message, or artifact inputs;
• and 1 false-completion attempt.

Run the cases after changes to the model, prompts, tools, protocol library, agent card, authorization service, artifact store, or routing policy.

Score the result and the communication record separately

A correct artifact with a broken audit chain is not production-ready. A flawless sequence of states with a wrong result is not useful.

Use two scorecards:

1. Outcome quality: correctness, completeness, evidence, format, safety, and business acceptance.
2. Boundary quality: route eligibility, authority, contract version, state integrity, artifact retrieval, latency, recovery, and closure.

This separation reveals whether a defect belongs to the agent’s capability or the system connecting the agents.

§ 12What Does a Complete Agent-to-Agent Exchange Look Like?

Consider a coding agent that needs current market evidence and a finished PDF for a product decision. It can modify the repository, but it lacks the capabilities needed to research the market and produce the document.

The exchange has a conversational moment at step 4, but the conversation is not the architecture. Identity, eligibility, a versioned contract, state, artifacts, validation, and two-level closure make the result dependable.

Example task packet

yaml task_id: research_pdf_1842 context_id: product_decision_77 relationship: delegation sender: coding_agent_v5 receiver: research_document_agent_v3 requested_outcome: artifact_type: market_evidence_pdf_v2 topic: commercial battery recycling software scope: geography: United States evidence_cutoff: 2026-07-27 exclusions: - no vendor contact - no account creation inputs: approved_source_policy: source_policy_12 authority: web_research: allowed external_messages: denied purchases: denied limits: due_at: 2026-07-27T22:00:00Z max_cost_usd: 18 acceptance: required_artifacts: - pdf - structured_source_ledger checks: - every material claim maps to a source - geography and cutoff are stated - contradictions are preserved

The packet is illustrative. Its value comes from making outcome, scope, authority, limits, artifacts, and acceptance observable - not from the YAML syntax.

Closure remains with the correct owner

When the receiver finishes the PDF, it can complete its delegated task. The coding agent or parent decision owner must still decide whether the evidence is acceptable and how it affects the wider product work.

If the receiver were expected to take over the product decision, interact with the user, and close the parent outcome, the relationship would need to be a handoff with explicit ownership transfer.

§ 13When Should You Use Agent-to-Agent Communication?

Use an agent boundary when the receiver needs meaningful independence to interpret a task and the resulting flexibility justifies the additional coordination and trust surface.

Agent-to-agent communication is usually unnecessary for:

• simple data lookup;
• one deterministic calculation;
• a stable CRUD operation;
• a local specialist that the manager already invokes as a tool;
• a workflow that cannot state an acceptance rule;
• or a task that requires copying unrestricted credentials and context.

Choose the narrowest sufficient interface

Flexibility has a cost. A remote agent may interpret scope differently, ask for input, take longer than expected, or return a result that requires domain review. A deterministic API reduces that variance. The agent-to-agent versus API automation comparison shows when negotiated task semantics earn that overhead and when a named operation should remain an ordinary API call.

Begin with the narrowest interface that can produce the required outcome:

1. Use a function or API if the operation is known and stable.
2. Use a tool interface if an agent should choose when to invoke that operation.
3. Use delegation if a remote worker must own a bounded contribution.
4. Use a handoff if control of a defined scope must move.
5. Use peer collaboration only when ownership can be divided and reconciled explicitly.

The sophistication of the architecture should follow a measured need, not the number of agents available.

§ 14How Does CellCog Fit Agent-to-Agent Work?

CellCog publicly describes an external execution surface through which other agents can request research, media, document, application, dashboard, and coding work and receive finished artifacts.

The current CellCog Agent-to-Agent platform lists OpenClaw, Claude Code, Cursor, Codex, Hermes, Linear, and custom Open Plugins-compatible agents as entry points. The page describes API, SDK, plugin, integration, and skills-based access through one CellCog API key.

The public workflow is:

1. obtain a CellCog API key;
2. call CellCog from a supported external agent or custom integration;
3. submit a task in the appropriate mode;
4. track the task through the supported integration behavior;
5. and receive the finished artifact or files.

CellCog’s public interface description does not establish formal A2A Protocol 1.0 compliance or prove the quality, security, latency, or suitability of a particular task.

Match the integration to the calling environment

CellCog provides dedicated surfaces for several agent environments. For example, CellCog for Codex is positioned around requesting research, media, and documents from a coding workflow through the Open Plugins standard, and CellCog for Claude Code is positioned as a plugin for generating research, media, and documents without leaving the coding environment.

The useful evaluation question is not whether the integration has an agent label. It is whether the live interface provides the contract your workload needs:

• supported tasks and artifact types;
• authentication and key handling;
• request and result schema;
• task state and notification behavior;
• timeout and cancellation behavior;
• data handling and retention;
• evidence and artifact retrieval;
• failure and retry semantics;
• and current rate, cost, and usage limits.

Run the same boundary test used for every provider

Before placing CellCog or another remote execution platform into a consequential workflow:

• select one bounded task;
• remove sensitive data that is not required;
• define the expected artifact and evidence;
• prohibit external writes unless essential;
• set time and spend limits;
• run normal, missing-input, duplicate, timeout, and malicious-input cases;
• inspect the live state and artifact record;
• and decide which human or parent agent accepts the result.

Product capability can widen after the boundary proves reliable. The first test should make failure easy to observe and contain.

§ 15What Should an Implementation Checklist Include?

Start with one remote relationship, one task type, and one result schema. The first live boundary should be easier to inspect than the single-agent workflow it replaces.

Before enabling the connection

• Name the remote role: tool, worker, or peer.
• Verify agent, provider, endpoint, tenant, and owner identity.
• Record supported protocol, agent, card, and schema versions.
• Define the task relationship and control owner.
• Set hard eligibility gates before routing preferences.
• Minimize inputs and pass large objects by authorized reference.
• Define output artifacts and acceptance tests.
• Calculate task authority independently of the sender’s credentials.
• Set time, spend, action, retry, and delegation limits.
• Define input-required and authorization-required behavior.
• Select polling, streaming, push, or queue delivery.
• Add idempotency, ordered events, and duplicate suppression.
• Make terminal artifacts retrievable after disconnection.
• Validate all external card, message, state, and artifact content.
• Define cancellation, partial-result, expiry, and escalation behavior.
• Keep unaccepted results out of shared memory and systems of record.
• Assign receiver, integration, security, and business owners.

Before increasing scope

• Run the 24-case boundary pack or an equivalent risk-based suite.
• Measure route eligibility, clarification, acceptance, false completion, and recovery.
• Review authorization denials and near misses.
• Re-test after agent, model, tool, policy, or schema changes.
• Confirm logs are useful without containing secrets or unnecessary personal data.
• Verify that a disconnected caller can recover current state and artifacts.
• Confirm repeated events cannot duplicate external actions.
• Compare accepted-outcome quality and cost against the simpler architecture.

If the interface cannot answer who owns the work, what the receiver may do, what state the task is in, and where the accepted result lives, it is not ready for wider autonomy.

§ 16Classify the Remote System Before Connecting It

The central architecture decision is simple to state: decide whether the remote system is a tool, a worker, or a peer.

A tool performs a declared operation while the caller controls the workflow. A worker accepts a bounded contribution while the delegator keeps the parent outcome. A peer receives or shares ownership under an explicit task contract.

Once that role is clear, the rest of the interface becomes easier to design:

• discovery identifies eligible capability;
• identity attributes every boundary event;
• the relationship assigns ownership;
• the task states the desired outcome;
• authority limits execution;
• messages coordinate change;
• artifacts carry durable results;
• state supports recovery;
• and acceptance closes the correct scope.

Agent-to-agent communication becomes useful when it replaces ambiguity with that structure. If the work can be expressed as a deterministic operation, keep the narrower interface. If another agent must interpret, negotiate, execute, and return an independently verifiable result, give the interaction a real task contract before giving it more authority.