The practical guide to A2A agent framework integrations

The AI agent ecosystem is exploding, but development is siloed, fragmented across incompatible frameworks and orchestration models. Engineering teams are often forced to choose between systems optimized for deterministic workflow control, such as LangGraph, and frameworks designed for autonomous multi-agent collaboration, such as CrewAI.

In practice, that choice can create architectural lock-in: workflows become tightly coupled to a single framework’s abstractions, execution model, and tooling. As agent systems grow more complex, teams struggle to combine the strengths of different frameworks within a unified runtime. The result is often a collection of disconnected agent pipelines and orchestration layers rather than a cohesive, interoperable intelligent system.

The solution is an architectural shift from a framework-centric design to a protocol-centric one. The future of agentic systems isn’t about finding a single “best” framework; it’s about using open protocols like Agent2Agent (A2A) to enable specialized, best-of-breed agents to collaborate. A2A reached v1.0 in 2026 and is now governed under the Linux Foundation, so the spec is stable enough to build against.

This guide is for developers, architects, and engineering leads who want to move beyond framework comparisons. It covers the architectural patterns and practical Python code, built on the official a2a-sdk, required to design, build, and deploy robust, heterogeneous multi-agent systems.

Why agent frameworks vs protocols is the real debate

The fundamental distinction here is that frameworks define how an agent is built, while protocols define how agents communicate with each other. That separation is the key to building scalable, modular agentic systems. It moves development away from monolithic agents toward a federated network of specialized, interoperable components.

Frameworks define “how”: Building with LangGraph, CrewAI, and PydanticAI

An agent framework provides the internal scaffolding for an agent or a tightly-coupled team of agents. It offers structure, state management, and tooling for the development process. A framework is concerned with the agent’s internal logic, focusing on how it processes information and executes tasks.

Think of a framework like a car factory. Ford, Toyota, and BMW each have proprietary assembly lines, parts, and engineering philosophies. They all produce a functional car, but the internal construction is unique to that manufacturer. LangGraph builds agents as deterministic state graphs, while CrewAI builds them as autonomous, role-playing teams. The end product is an agent, but the construction is framework-specific.

Protocols define “what”: A2A for agents, MCP for tools

A protocol provides a universal language for communication between independent systems, regardless of how they were built. It defines the message format, the interaction patterns, and the expected behaviors so different components can interoperate reliably.

Two open protocols dominate the agent stack:

• Agent2Agent (A2A): An open spec, governed by the Linux Foundation, that defines how independent agents discover one another and delegate tasks. A2A is transport-pluggable, with bindings for JSON-RPC 2.0, gRPC, and HTTP+JSON/REST, plus streaming via Server-Sent Events (SSE) and webhook push notifications for long-running work.
• Model Context Protocol (MCP): The open standard originated by Anthropic for connecting AI applications to data sources, tools, and workflows. MCP uses JSON-RPC over either stdio (for local servers) or Streamable HTTP (for remote servers, replacing the older HTTP+SSE transport).

Using our car analogy, protocols are the rules of the road. They don’t care whether a car is a Ford or a BMW; they let any car from any factory navigate the same highway safely. A2A is the protocol that lets one agent ask another to do something; MCP is how an agent uses tools and data sources.

The strategic shift from monolithic agents to federated systems

Understanding this distinction enables a powerful strategic shift. Instead of being locked into one framework’s limitations, you can build a federated system that uses the best tool for each job. A LangGraph orchestrator can define a predictable, high-level workflow. For a step that requires complex research and synthesis, it can make an A2A call to a specialized CrewAI agent. For a final data-validation step, it can call a small, reliable agent built with PydanticAI. This modular approach yields systems that are more resilient, maintainable, and scalable.

Evaluating the top Python frameworks for A2A readiness

The best Python frameworks for A2A integration are the ones that can be exposed as independent services with a well-defined contract. Their suitability depends on the role they will play in a larger system, whether planner, executor, or validator.

LangGraph: The deterministic state machine

LangGraph excels at predictable, graph-based workflows with explicit state management. It represents agentic logic as a state graph where nodes are functions (tools or LLM calls) and edges are conditional logic that determines the next step based on current state. This structure provides a high degree of control and observability over execution.

Its A2A readiness is excellent for the role of a central router or planner. A LangGraph-based orchestrator can manage the overall state of a complex task and call other specialized A2A agents from within its graph nodes. This makes it an ideal backbone for a multi-agent system.

CrewAI: The autonomous delegated team

CrewAI’s strength is autonomous teams of agents collaborating on a high-level goal. It abstracts away fine-grained orchestration, allowing emergent task decomposition and creative problem-solving. You define roles (Researcher, Writer), provide them with tools, set a goal, and the crew manages its own internal process to reach it.

In an A2A context, a CrewAI agent is best exposed as a specialized expert system. It’s not well suited to be the top-level orchestrator because of its less deterministic nature. Instead, expose it as a single, callable agent that receives a high-level task via A2A (e.g. “Generate a market analysis report for quantum computing startups”), runs its crew internally, and returns the final result.

PydanticAI: The type-safe agent framework

PydanticAI is a full-featured agent framework from the Pydantic team, with type-safe tool calls, structured outputs, dependency injection, streaming, and Logfire integration. By defining strict Pydantic models for inputs and outputs, you get guaranteed schema adherence, which is useful when an A2A endpoint must accept or emit structured data.

This makes PydanticAI agents particularly good A2A endpoints for tasks that demand high reliability, such as data extraction from unstructured text, compliance checks, and format transformations. In an A2A system, a PydanticAI agent works well as a trustworthy validator or transformer between other, more complex agents.

OpenAI Agents SDK: The tool-using executor

OpenAI’s Agents SDK is the current Python framework for building tool-using assistants on OpenAI models (it superseded the deprecated Assistants API, which was replaced by the Responses API). It has first-class, built-in support for MCP servers, so it can talk to any MCP-compliant tool out of the box. It doesn’t implement A2A natively, but it’s straightforward to expose an Agents SDK agent as an A2A endpoint with the a2a-sdk.

A consolidated view:

None of these frameworks expose A2A endpoints by default, but you don’t have to write the bridge from scratch. The A2A project ships an official Python SDK (a2a-sdk on PyPI) plus reference samples for LangGraph, CrewAI, the OpenAI Agents SDK, and others in the a2a-samples repository. The next section walks through that pattern end-to-end.

How to build an A2A bridge between LangGraph and CrewAI

The practical Python approach to connecting different agent frameworks is to wrap each agent as an A2A server, publish an Agent Card so other agents can discover it, and call it from your orchestrator using the a2a-sdk client. This section walks through that pattern end-to-end.

Step 1: Defining the A2A contract with an Agent Card

An Agent Card is a JSON document that an A2A server publishes at /.well-known/agent-card.json. It’s the machine-readable contract that tells other agents:

• Who this agent is
• Where to reach it
• What skills it offers
• Which security schemes it accepts

Here’s a v1.0-compliant agent card for a CrewAI agent specialized in market research. The structure follows the official AgentCard/AgentSkill/AgentCapabilities/AgentInterface types defined by the a2a-sdk and the A2A spec:

{

  “name”: “Market Researcher Agent”,

  “description”: “An autonomous agent that produces a structured market analysis report for a given topic.”,

  “version”: “1.0.0”,

  “supportedInterfaces”: [

    {

      “url”: “http://127.0.0.1:9999/”,

      “protocolBinding”: “JSONRPC”,

      “protocolVersion”: “1.0”

    }

  ],

  “capabilities”: {

    “streaming”: true,

    “pushNotifications”: false,

    “extendedAgentCard”: false

  },

  “defaultInputModes”: [“text/plain”],

  “defaultOutputModes”: [“application/json”, “text/plain”],

  “skills”: [

    {

      “id”: “generate_report”,

      “name”: “Generate market analysis report”,

      “description”: “Researches a topic and returns a structured market analysis report.”,

      “tags”: [“research”, “market-analysis”],

      “examples”: [

        “Generate a market analysis report for quantum computing startups.”

      ],

      “inputModes”: [“text/plain”],

      “outputModes”: [“application/json”, “text/plain”]

    }

  ]

}

A few things to call out: 

• In A2A v1.0, the endpoint URL and protocol binding live inside supportedInterfaces[], and capabilities is a small object of boolean flags (streaming, pushNotifications, extendedAgentCard), not a list of named operations. 
• Operations are described as skills, each with id, name, description, tags, examples, and supported media types.

Step 2: Exposing the CrewAI agent with the a2a-sdk

We expose the CrewAI crew through a2a-sdk’s AgentExecutor, which is the SDK’s bridge between the protocol layer and your agent’s business logic. The SDK handles serving the Agent Card at /.well-known/agent-card.json, accepting JSON-RPC SendMessage/SendStreamingMessage calls, managing the Task lifecycle, and emitting SSE for streaming clients, none of which you have to wire up by hand.

# crewai_a2a_server.py

import uvicorn

from crewai import Agent, Task, Crew

from starlette.applications import Starlette

from a2a.server.agent_execution import AgentExecutor, RequestContext

from a2a.server.events import EventQueue

from a2a.server.request_handlers import DefaultRequestHandler

from a2a.server.routes import create_agent_card_routes, create_jsonrpc_routes

from a2a.server.tasks import InMemoryTaskStore

from a2a.types import (

    AgentCapabilities, AgentCard, AgentInterface, AgentSkill,

    TaskState, TaskStatus, TaskStatusUpdateEvent, TaskArtifactUpdateEvent,

)

from a2a.helpers import (

    new_task_from_user_message, new_text_artifact, new_text_message,

)

class MarketResearchExecutor(AgentExecutor):

    “””Wraps a CrewAI crew behind the A2A AgentExecutor interface.”””

    def _build_crew(self, topic: str) -> Crew:

        researcher = Agent(

            role=’Senior Market Analyst’,

            goal=’Generate insightful market analysis reports’,

            backstory=’An expert analyst with a knack for identifying market trends.’,

            verbose=True,

        )

        task = Task(

            description=f’Conduct a comprehensive market analysis on {topic}.’,

            expected_output=’A structured report with a summary and key findings.’,

            agent=researcher,

        )

        return Crew(agents=[researcher], tasks=[task], verbose=True)

    async def execute(self, context: RequestContext, event_queue: EventQueue) -> None:

        task = context.current_task or new_task_from_user_message(context.message)

        await event_queue.enqueue_event(task)

        await event_queue.enqueue_event(TaskStatusUpdateEvent(

            task_id=context.task_id,

            context_id=context.context_id,

            status=TaskStatus(

                state=TaskState.TASK_STATE_WORKING,

                message=new_text_message(‘Running market research crew…’),

            ),

        ))

        topic = context.get_user_input()

        crew = self._build_crew(topic)

        # kickoff() returns a CrewOutput; .raw is the string form.

        crew_output = crew.kickoff(inputs={‘topic’: topic})

        result_text = crew_output.raw

        await event_queue.enqueue_event(TaskArtifactUpdateEvent(

            task_id=context.task_id,

            context_id=context.context_id,

            artifact=new_text_artifact(name=’market_analysis’, text=result_text),

        ))

        await event_queue.enqueue_event(TaskStatusUpdateEvent(

            task_id=context.task_id,

            context_id=context.context_id,

            status=TaskStatus(state=TaskState.TASK_STATE_COMPLETED),

        ))

    async def cancel(self, context: RequestContext, event_queue: EventQueue) -> None:

        raise Exception(‘cancel not supported’)

skill = AgentSkill(

    id=’generate_report’,

    name=’Generate market analysis report’,

    description=’Researches a topic and returns a structured market analysis report.’,

    tags=[‘research’, ‘market-analysis’],

    examples=[‘Generate a market analysis report for quantum computing startups.’],

)

agent_card = AgentCard(

    name=’Market Researcher Agent’,

    description=’An autonomous agent that produces a structured market analysis report for a given topic.’,

    version=’1.0.0′,

    default_input_modes=[‘text/plain’],

    default_output_modes=[‘application/json’, ‘text/plain’],

    capabilities=AgentCapabilities(streaming=True, extended_agent_card=False),

    supported_interfaces=[

        AgentInterface(protocol_binding=’JSONRPC’, url=’http://127.0.0.1:9999′),

    ],

    skills=[skill],

)

request_handler = DefaultRequestHandler(

    agent_executor=MarketResearchExecutor(),

    task_store=InMemoryTaskStore(),

    agent_card=agent_card,

)

routes = []

routes.extend(create_agent_card_routes(agent_card))   # /.well-known/agent-card.json

routes.extend(create_jsonrpc_routes(request_handler, ‘/’))

app = Starlette(routes=routes)

if __name__ == ‘__main__’:

    uvicorn.run(app, host=’127.0.0.1′, port=9999)

Two details here are worth flagging:

• First, kickoff() on modern CrewAI (0.80+) returns a CrewOutput. Use .raw for the string form or .pydantic / .json_dict if your crew produces structured output. 
• Second, the SDK takes care of publishing the Agent Card at /.well-known/agent-card.json, so any A2A-aware client can discover this agent from its base URL alone.

Step 3: Calling the CrewAI agent from a LangGraph node

On the orchestrator side, we use the a2a-sdk client. A LangGraph node fetches the remote Agent Card via A2ACardResolver, creates a non-streaming client through ClientFactory, sends a Message, and folds the resulting Task/artifact data back into the graph state. Nothing in the orchestrator needs to know about CrewAI specifically, only the contract advertised in the Agent Card.

# langgraph_caller.py

import asyncio

from typing import TypedDict

import httpx

from a2a.client import A2ACardResolver, ClientConfig, create_client

from a2a.types import Role, SendMessageRequest

from a2a.helpers import new_text_message

class AgentState(TypedDict):

    research_topic: str

    analysis_report: dict

RESEARCHER_BASE_URL = ‘http://127.0.0.1:9999’

async def _call_research_agent_async(topic: str) -> dict:

    async with httpx.AsyncClient() as httpx_client:

        # 1. Discover the agent via its well-known card.

        resolver = A2ACardResolver(

            httpx_client=httpx_client,

            base_url=RESEARCHER_BASE_URL,

        )

        public_card = await resolver.get_agent_card()

        # 2. Build a non-streaming client from the discovered card.

        config = ClientConfig(streaming=False)

        client = await create_client(agent=public_card, client_config=config)

        # 3. Send a SendMessage request shaped per the A2A spec.

        message = new_text_message(

            f’Generate a market analysis report on {topic}’,

            role=Role.ROLE_USER,

        )

        request = SendMessageRequest(message=message)

        # 4. The SDK yields a stream of Task events; collect them.

        events = []

        async for chunk in client.send_message(request):

            events.append(chunk)

        return {‘events’: events}

def call_research_agent(state: AgentState) -> dict:

    “””LangGraph node that delegates to the CrewAI A2A agent.”””

    topic = state.get(‘research_topic’)

    if not topic:

        raise ValueError(‘Research topic not found in state.’)

    try:

        report_data = asyncio.run(_call_research_agent_async(topic))

    except Exception as e:

        return {‘analysis_report’: {‘error’: str(e)}}

    return {‘analysis_report’: report_data}

# Example wiring into a LangGraph graph:

# from langgraph.graph import StateGraph, END

# workflow = StateGraph(AgentState)

# workflow.add_node(‘researcher’, call_research_agent)

# workflow.add_edge(‘researcher’, END)

# workflow.set_entry_point(‘researcher’)

# app = workflow.compile()

# final_state = app.invoke({‘research_topic’: ‘AI in healthcare’})

This three-step process produces a decoupled, spec-accurate integration. The LangGraph orchestrator only needs to know the Agent Card; the CrewAI agent’s internal implementation can change without breaking callers. The same pattern applies to PydanticAI, the OpenAI Agents SDK, or any future framework — wrap it in an AgentExecutor, publish an Agent Card, and any A2A-aware client can call it.

Common pitfalls when implementing multi-agent A2A systems

Common mistakes can lead to high costs, unpredictable latency, and brittle integrations. They typically stem from treating agent-to-agent communication like a simple internal function call instead of a distributed network request. Let’s explore some of the most common mistakes when building A2A systems. 

Mistake 1: Ignoring the token multiplier effect

Each A2A handoff passes context from one agent to another, which often involves a new LLM call in the receiving agent. This creates a token multiplier effect: A single user request triggers a cascade of LLM calls across multiple agents, dramatically increasing both cost and latency. A chatty back-and-forth between two agents can burn through a token budget exponentially faster than a single, well-scoped call.

As a rule of thumb, use A2A for distinct capability handoffs, not iterative conversations. Delegate a complete, well-defined task to a specialized agent and wait for the final result.

Mistake 2: Lacking cross-framework observability

Debugging a distributed system is hard. When a request flows through a LangGraph planner, then to a CrewAI executor, then to a PydanticAI validator, tracing a failure becomes a nightmare without a unified view.

The fix is distributed tracing. Propagate the W3C Trace Context traceparent header on every A2A call, and feed it into an OpenTelemetry-compatible collector. That lets observability tools stitch together a single trace across all agents involved in a request.

Mistake 3: Creating circular dependencies and infinite agent loops

A poorly designed A2A architecture can easily produce infinite loops. If Agent A can call Agent B, and Agent B can call Agent A, you have a circular dependency that can spiral out of control, consuming all available resources and resulting in cascading failures and a massive LLM bill.

Prevent this by designing agent orchestration as a Directed Acyclic Graph (DAG). A dedicated planner agent (typically LangGraph) sits at the top of the hierarchy and calls downstream executor agents, but executors should not call each other or the orchestrator back. That keeps data flow predictable and one-way.

Mistake 4: Using poorly defined Agent Cards

An incomplete or ambiguous Agent Card is a primary source of integration failures. If a skill’s input or output modes are too loose, or its examples don’t cover edge cases, the calling agent will inevitably send something the receiving agent can’t parse or get back a response it can’t handle. The result is a brittle connection that breaks silently.

To mitigate this, treat each A2A agent like a public, versioned API. Pin a version field in the Agent Card, validate inputs and outputs with strict Pydantic models on both sides, and treat any change to skills or media types as a new version.

How to secure your A2A communication layer

Securing the communication between AI agents is critical for preventing unauthorized access and ensuring data integrity in production. A common mistake is to assume that because the traffic is internal, it doesn’t need the same level of security as external, user-facing traffic. That assumption is a real vulnerability.

Why you must treat internal A2A traffic like external traffic

Adopt a zero-trust posture for your agent network. No network, whether internal or external, is inherently trustworthy. Every A2A call must be individually authenticated and authorized before it’s allowed to execute. A compromised or misconfigured agent could otherwise be used as a pivot point into other agents and the data or tools they can access.

Implementing agent authentication with API keys, OAuth 2.0, or JWTs

There are several practical methods to secure A2A communication, and they mirror standard API security practices. A2A’s AgentCard declares accepted methods natively in its securitySchemes and security fields, so callers know what to present:

• API keys: Each calling agent is issued a unique, long-lived API key. The receiving agent validates it before processing a request. Simple to implement but harder to scope and revoke.
• OAuth 2.0/JWTs: A central authentication service issues short-lived, signed tokens with claims (scopes) that define exactly which actions an agent is authorized to perform on another. A2A explicitly supports OAuth 2.0 scheme declarations in the AgentCard, making this the recommended approach for production systems.

Implementing this logic in every agent’s code is repetitive and error-prone. A better approach is to offload it to an API gateway. A gateway such as Tyk can sit in front of each agent, acting as a policy enforcement point, validating API keys, verifying JWTs, and enforcing OAuth scopes on every incoming A2A request, fully abstracting security concerns from the agent’s core logic.

Preventing cascading failures with rate limiting and circuit breakers

A misbehaving or looping agent can inadvertently launch a denial-of-service attack on another agent, overwhelming it with requests and causing a system-wide failure. That’s not just a security risk, it’s a reliability risk.

An API gateway is essential for the resilience of the agent network. Traffic-management policies that matter here are:

• Rate limiting: Restrict how many requests an agent can make in a given window.
• Quotas: Cap the total number of allowed requests over a longer period.
• Circuit breakers: Automatically halt traffic to an agent that’s consistently returning errors, giving it time to recover and preventing a cascade of failures across the system.

Centralizing security and traffic control at the gateway layer lets you build a more secure, scalable, and resilient multi-agent system without complicating individual agent implementations.

Frequently asked questions

What is the main difference between A2A and MCP protocols?

A2A (Agent2Agent) is designed for agents to delegate tasks and communicate with one another, enabling collaboration within a multi-agent system. MCP (Model Context Protocol) is designed for AI applications to discover and use external tools, data sources, and workflows. In short, A2A is for agent-to-agent collaboration; MCP is for agent-to-tool interaction. The two are complementary; an agent typically uses MCP internally for its tools and A2A externally to coordinate with other agents.

Can you use LangGraph and CrewAI together in the same project?

Yes, and it’s a powerful pattern. With an A2A integration you can run a LangGraph agent as a high-level orchestrator defining a predictable workflow, then delegate specific, complex, or creative sub-tasks to a specialized CrewAI agent for autonomous execution, combining the strengths of both frameworks.

How do you manage state across different agent frameworks in an A2A system?

State should live with a primary orchestrator agent. A stateful framework like LangGraph is well-suited for this role. When the orchestrator delegates via an A2A call, it passes only the minimal context needed. The called agent runs to completion and returns a Task (with its artifacts) which the orchestrator then folds back into its main state graph.

Which framework is best for building an A2A planner agent?

LangGraph is well-suited for planner or orchestrator agents. Its explicit, graph-based structure provides the control, predictability, and state management needed to reliably coordinate multiple downstream executor agents.

Does OpenAI’s agent framework support A2A integrations?

The OpenAI Agents SDK is OpenAI’s current Python framework for building tool-using assistants (it superseded the deprecated Assistants API, which OpenAI is winding down in favor of the Responses API). The Agents SDK has built-in support for MCP servers, but it doesn’t implement A2A natively. As with LangGraph and CrewAI, you expose an Agents SDK agent as an A2A endpoint with the a2a-sdk.

How does an API gateway help with multi-agent systems?

An API gateway such as Tyk acts as a secure, centralized control plane for all A2A communication. It offloads critical cross-cutting concerns (authentication, authorization, rate limiting, observability) from individual agents. The result is simpler agent code, standardized governance, and a distributed system that’s easier to secure, scale, and operate.

Conclusion

The future of advanced AI systems is composable and heterogeneous, not monolithic. Building enterprise-grade agentic applications isn’t about finding one perfect framework that does everything, it’s about mastering the protocols and patterns that let specialized, best-of-breed agents collaborate effectively and securely.

That requires a shift in mindset. Treat individual agents as managed services, each with a clear, versioned contract defined by an Agent Card. Practical A2A integration is achieved by exposing those agents through the official a2a-sdk and coordinating them with orchestrators like LangGraph.

Production-readiness demands a robust infrastructure layer. Security, observability, and traffic management aren’t optional features. They’re foundational. An API gateway is the centralized control plane that governs a complex network of AI agents. As agents become more commoditized, the ability to architect, integrate, and secure these distributed systems will be the defining skill for the next generation of AI applications.

Ready to secure and manage your distributed agent network? See how the Tyk Gateway can enforce policies, manage traffic, and provide unified observability for your A2A endpoints. 

Want to understand the A2A protocol in more depth first? Then check out our detailed article on its architecture and technical specification.