Skip to main content
The A2A protocol enables agent communication across system boundaries — between services, organizations, or deployment environments. It builds on internal messaging by adding authentication, authorization, and external transport.

Architecture

Three integration layers

Request flow

1

Client builds invocation request

2

Auth provider validates

The server validates the auth token, extracts the caller identity, and checks authorization rules.
3

Server runs the agent

The target agent executes locally with a Runner, using the invocation request as input.
4

Response returned

Invocation contracts

Hosting an A2A service

Expose your agents as an A2A-accessible service:

Authentication providers

AFK ships with three auth providers:
Permits all requests without authentication. Never use in production.

Google A2A adapter

For interoperability with Google’s A2A protocol, use the Google adapter:
The adapter wraps a configured Google A2A SDK client behind AFK’s AgentCommunicationProtocol.

Security considerations

Always authenticate A2A endpoints. An unauthenticated A2A server allows anyone to invoke your agents, consuming your LLM API credits.

Next steps

Task Queues

Async job processing for long-running work.

MCP Server

Expose tools via the Model Context Protocol.