Google ADK and A2A: Controlled Collaboration Between AI Agents

Google ADK is a framework for building AI agents, while A2A is a protocol for communication between agents. The former organises an application's behaviour; the latter defines how it can collaborate with a remote agent. They answer different architectural questions and do not replace the company's business rules or operational responsibilities.

For a company, interoperability becomes useful when responsibilities are genuinely separate: one system knows the catalogue, another manages the enquiry, and a person approves the proposal. Before choosing technology, establish what is exchanged, who may request it and which outcome requires verification. More agents do not automatically make an architecture better.

This guide uses a proposed quotation-preparation example, not a client implementation. Its diagrams are original. The authentic photographs illustrate document analysis and computing infrastructure, not an ADK product or WebHat installation. No quotations are sent, fiscal documents issued or confidential data used. The example concerns design decisions rather than a measured commercial result.

ADK, A2A and MCP: which problem does each address?

A framework, a protocol and a tool are different layers

Google's documentation defines ADK around building and operating agents. A2A documentation distinguishes collaboration between agents from connecting an agent to tools and resources through MCP. These names do not identify language models. Installing any one of them does not deliver the complete application that employees will use in their daily work.

In our example, the coordinator could use ADK for its own behaviour and A2A to request information from a separate catalogue agent. That catalogue agent may use a different framework internally. For a fixed read from a company's own catalogue, a deterministic API integration may be sufficient and simpler to maintain.

The map of types of artificial intelligence helps distinguish technology, task and autonomy. Here the subject is application architecture, not an increase in model capability. A common protocol can make an exchange compatible; data correctness, access rights and acceptance of the output need their own controls, stated explicitly in the specification.

What do we actually build with Google ADK?

An agent has a bounded purpose inside the application

ADK provides mechanisms for defining an agent, its tools and its workflow. For the proposed coordinator, the requirement is to prepare an internal quotation draft. The agent does not receive a vague objective to sell at any cost. It receives a responsibility that can be described, assessed and tested against an explicit acceptance condition.

Define the accepted input, mandatory information, situations requiring clarification and output format. An enquiry without a quantity is not completed with an assumption presented as the customer's confirmed requirement. The application can retain confirmed fields, agent suggestions and outstanding questions separately, so that a reviewer can see the difference instead of interpreting one undifferentiated response.

When designing AI agents and their level of autonomy, choose separately what the system may propose and what it may execute. The framework's name does not establish commercial authority. If the process permits drafting only, exposed tools should not include automatic dispatch or unrestricted modification of the underlying product catalogue.

What does A2A add between two applications?

A common contract for an agent whose internals remain separate

With A2A, a client communicates with a remote agent without receiving direct access to its memory, tools or implementation. The exchange has common concepts for requests and outputs. This separation matters when different teams maintain the systems, or when the systems belong to organisations that apply different operational rules and access policies.

In the proposed scenario, the catalogue request contains only the necessary specifications and the requester's verifiable identity through the access mechanism. We do not transmit the entire commercial file to ask about component compatibility. Returned information should retain the reference and version used, allowing the draft to be checked later against its actual source.

Comparison with AI application orchestration tools shows why a protocol and a framework are independent choices. An internal graph can coordinate local steps; A2A defines the exchange at the remote-service boundary. That boundary does not automatically transfer every rule, historical record or permission from the originating application to the other system.

What is an Agent Card, and what does it not prove?

A capability description does not grant permission to use it

An Agent Card is an agent's structured description: identity, capabilities, access points and authentication requirements. A2A documentation describes public discovery, registries and private configuration. For an internal integration, we can choose an approved list of services rather than unrestricted discovery of any agent encountered online. Discovery policy is part of the design.

In the quotation example, a card advertising catalogue lookup does not establish that a user may view negotiated prices. The catalogue service checks the actual entitlement for the specific request. Neither a skill description nor a provider's name, by itself, measures the quality of an answer produced by the agent in a particular case.

Define who approves the partner agent, which contract version is accepted and how configuration changes are managed. If the description exposes internal addresses or sensitive capabilities, control access to that description separately. A card is not a storage location for passwords, static secrets or commercial information that should not be disclosed to those discovering the service.

How do we track work without confusing progress with approval?

Task, context and output have distinct responsibilities

An A2A task can have tracked state, while a context can group related interactions. A message communicates information; an artifact represents a produced output. Identifiers help the application follow the process, but do not replace authentication, access rights or commercial approval of the received content. Tracking and authority remain separate concerns throughout the workflow.

The coordinator may receive partial information and request clarification before preparing its draft. In the business interface, display technical status separately from review status. “Output available” describes the availability of a result; “approved for dispatch” is a commercial process decision for the exact version seen by the authorised reviewer, not every subsequent variant.

The lifecycle documentation treats terminal tasks as closed; related follow-up may require a new task within the same context. The application retains the relationship between versions without rewriting history. A later correction should not appear as though it were the initial output that was accepted or checked. Preserve what changed and the relevant review boundary.

Where are authentication and authorisation enforced?

Each service checks identity and the requested operation

The A2A specification separates request authentication from authorisation of the operation. Production implementations use encrypted transport and verification of service identity. After identifying the requester, the application decides which information and actions are permitted. Protocol compatibility does not automatically grant access to all data held by the partner agent or its connected systems.

For the catalogue, design concrete permissions: reading specifications, visibility of selected prices and no ability to modify them from the proposal workflow. A task identifier guessed or received from another user must not allow access to its result. The server checks the requested object and operation, rather than relying only on restrictions in the interface.

The guide to data protection in AI applications complements the exchange analysis. For the proposed project, establish permitted fields, retention periods and who may inspect logs. Do not copy entire documents into every technical record merely because doing so would make an integration error easier to investigate later. Diagnostic usefulness and disclosure scope are different decisions.

A change in user role must also affect previously started tasks. Check reading the output, continuing work and approving the draft separately. Revocation must not be indirectly undone by an output retained in another component. This is a requirement of the proposed application, verified through a dedicated test case rather than assumed from the protocol's presence.

How do agents connect to business data and tools?

Interoperability does not repair incomplete information or unsafe operations

The catalogue agent may internally use retrieval or an integration with an existing system. The choice depends on data structure and the requirement. For controlled commercial fields, retain an authoritative source; a fluent sentence generated by a model does not automatically become the company's confirmed price or delivery commitment. The interface should preserve that distinction.

The relationship with RAG, fine-tuning and prompt engineering concerns information access and response behaviour. A2A alone does not determine which document is current or which passage supports a conclusion. In the draft, retain internal references needed for review and identify information that requires confirmation instead of presenting every output field as equally established.

The integration also needs interruption handling. If a response is delayed, the coordinator does not assume that the remote service did nothing. Define a state requiring verification and a reconciliation procedure. For external effects, design the operation key and persistent record at application level; do not infer protection against repeated actions from the presence of a retry mechanism.

How do we test collaboration between agents?

Evaluate contracts and refusals, not just one successful conversation

For each test case, fix the request, user permissions, catalogue version and expected outcome. Check whether the draft uses permitted information only and keeps missing details visible. A demonstration with a complete enquiry does not cover behaviour when an error, delay or source modification occurs. The test set must reflect the actual operating conditions chosen for the project.

One important test changes permissions before continuation. Another changes the catalogue version after drafting but before review. The process must apply the defined rule: stop, recheck or recalculate. Do not automatically accept an old output merely because the remote task had a technical success status. Acceptance concerns the current business context and the exact proposed content.

The guide to AI automation and control of repeated operations explains a problem shared by agent integrations. Measure response time, content quality, correct refusals and cases requiring intervention separately. No invented composite score replaces investigation of an unauthorised disclosure. An attractive average can coexist with a failure that needs its own explicit decision.

What should we check before selecting an ADK/A2A implementation?

Feature maturity and version belong in the technical decision

At the check on November 2, 2026, ADK documentation labels its A2A integration experimental. Selecting an implementation requires checking versions, the protocol binding and the features actually used. A quickstart example does not establish compatibility across every combination of language, SDK and partner service. Record the selected combination so that the relevant tests can be repeated.

ADK tool-confirmation documentation identifies experimental status and limitations for selected session services, including DatabaseSessionService and VertexAiSessionService. For a workflow that waits for review and must survive a process restart, check the exact chosen combination. Persistent approval cannot be inferred merely from the presence of a confirmation button in an example. Verify the required continuation behaviour directly.

In software development for business processes, these conditions enter architecture, testing and maintenance. Responsibilities can remain separated behind application-owned interfaces, so changing a framework does not require rewriting commercial rules. Select technology against demonstrated requirements rather than shaping every requirement around a list of products. The deliverable is the controlled function, not the dependency list.

Record the evaluated combination, used features and accepted cases in the technical specification. Check an update against the same scenarios before replacing the operating version. If a change affects an output format, adjust the contract and validator at their source; do not accumulate hidden transformations that make the final result difficult to understand or investigate later.

Which costs and responsibilities remain outside the protocol?

The checked ADK Python repository uses the Apache 2.0 licence. This identifies that project's licence, not the price of every connected model, service or integration. Separate infrastructure, model calls, storage, observability, development and human review in the budget. An open protocol does not remove these components or determine the terms of unrelated services used by the application.

Splitting a process across services adds access boundaries, network failures and versions to maintain. Its benefit should be concrete: independent responsibility, reuse or integration of systems that are already separate. If a simpler application with explicit steps meets the same requirements, additional agents should not be introduced merely to make a demonstration appear more elaborate or technologically fashionable.

Assign an operational owner to each service. Who investigates a missing result, changes the contract or removes a partner from the approved list? The project should answer these questions before launch. They distinguish a technically demonstrable exchange from a function that the business can administer consistently, including when the original developer is not available to interpret every incident.

How do we begin an interoperable-agent project?

Start with one collaboration, clear inputs and outputs, and no automatic external effects. For the quotation draft, first verify catalogue access and proposal quality. Only after validating these should additional operations and their approvals be considered, each against an identified requirement and observable outcome. Expansion then follows evidence about the process rather than the number of possible integrations.

Through business automation with AI integration, WebHat can design the workflow around existing systems and team roles. The deliverable includes component contracts, a review interface, access checks and test evidence. ADK and A2A are technical options within that architecture, not the commercial objective itself. The objective remains a function the company can use and manage.

At handover, the team should understand each displayed state and its available next action. A clarification request, an access refusal and a technical error need different messages and actions. The interface preserves this distinction, allowing the operator to address the cause instead of repeating the same request without new information or an appropriate change in the process.

Frequently asked questions about Google ADK and A2A

Are ADK and A2A the same thing?

No. ADK is a framework for building agents, while A2A is a protocol for communication between agents. An ADK-built agent can use A2A through a compatible implementation. Its partner may use a different framework, and the application may choose a simpler integration when the requirement does not call for collaboration between independently operated agents.

Does an Agent Card give the user access to every advertised skill?

No. The card describes what a service offers and how to connect. The server checks identity, permissions and the specific operation. In the example catalogue, visibility of specifications and prices may differ. A capability description replaces neither that rule nor assessment of the quality of each output produced by the agent for the requested task.

Does a completed task mean that a quotation can be sent?

Technical completion describes task status, not commercial approval. The exact draft must be checked against current sources and permissions. The process separately defines who may accept it and authorise dispatch. In this article's example, the external operation is not executed and no fiscal documents are issued. The proposed workflow ends at controlled preparation and review.

Do we also need MCP to use A2A?

There is no general requirement for every application to use both together. A2A and MCP cover different relationships: collaboration between agents and connections to tools or resources respectively. Architecture chooses the appropriate mechanism at each boundary. An existing service can also be integrated through a well-defined application interface when that meets the actual requirement more directly.

What happens if a partner agent does not respond in time?

The application follows its procedure for an unknown state, using the identifiers and checks defined in the contract. A delay does not establish that the operation never happened. For external effects, reconciliation and protection against repetition must be designed explicitly. Do not blindly launch the same action again merely to obtain a visible response from the remote service.

When is separating a process into several agents worthwhile?

When separation has a concrete role: independently administered services, reusable capabilities or collaboration between systems with genuine boundaries. Compare that architecture with a deterministic workflow and a single agent. Base the choice on requirements, tests, data controls and operational cost rather than the number of agents drawn in the diagram. Every additional boundary should have a defined purpose.