Ever wondered how implementing Agent2Agent (A2A) in an orchestrated business process might work in the real world? Wouldn’t you like to see how you can take advantage of A2A to solve specific requirements within your automated process and how your business can benefit from that?
This is the first blog in a two-part series. First, we’ll solidify your understanding of A2A and Camunda’s implementation of the protocol. Stay tuned for the second post, where we’ll show you how A2A works in a real world example.
In this post, you’ll get a deeper understanding of:
- Why A2A is important in agentic orchestration
- A2A and Camunda’s implementation
- Implementation considerations and options
- Governance and auditability of A2A with Camunda
Why A2A is important when implementing agentic orchestration
The Agent2Agent Protocol (A2A) is an open standard designed to allow different AI agents from different companies or domains to exchange messages and perform coordinated tasks.
In A2A, agents advertise their capabilities using a structured metadata format called agent cards. Agents then communicate through signed, structured messages based on a shared schema. A2A includes provisions for trust, routing, and structured memory exchange. This design maximizes the options for composability and cross-platform collaboration between AI agents.
To get a deeper introduction to A2A, read our previous blogs: Scale Agentic Automation with A2A, MCP, and Enhanced Connectors with Camunda 8.9-alpha2 and MCP, ACP, and A2A, Oh My! The Growing World of Inter-agent Communication.
Communication between AI agents becomes essential as you incorporate multi-agent patterns into end-to-end business processes, especially when different teams own the agents, large language models, and data sources.
With Camunda, you orchestrate that A2A collaboration inside business processes modeled in BPMN. This combines dynamic agent behavior (planning loops, short-term memory, long-term memory, RAG, and tool use) with deterministic guardrails like approvals, policies, and exception handling.
The result is agentic orchestration that scales with confidence while staying observable, auditable, and resilient, even as agents coordinate across domains and systems.
Why it matters to your business
AI agents give you flexible process execution; A2A makes it reliable. By aligning agents with the BPMN, you get standardized, testable, and governable interactions. You can update agents and LLM prompts safely, maintain SLAs, and execute clean migrations of process instances when things change.
In practice, A2A integration strengthens business processes by coordinating agents. It enables you to:
- Standardize agent handoffs and accountability. In business processes, each handoff between AI agents needs a clear audit trail, including what inputs were provided, what tool calls were allowed, what outputs were produced, and what confidence or evidence was attached. A2A gives you a consistent way to structure those exchanges across multiple agents, not ad-hoc prompts and payloads stitched together.
- Enforce separation of duties. Many regulations require independent initiation and authorization steps. With multiple agents, you can implement an executor agent plus an independent verifier agent (policy, risk, compliance) before a process proceeds. This approach helps to enforce governance guardrails, including adding quality checks and routing to a human when needed.
- Make agent behavior auditable inside an end-to-end process. A2A alone does not give you compliance. Compliance comes from orchestrating agent interactions inside a governed process model with visibility and checkpoints. Camunda’s approach is to combine dynamic agent behavior with deterministic process control so you can decide where AI can act and where approvals, rules, and SLAs must apply.
- Reduce vendor and model lock-in as policies evolve. Regulated environments change fast (policy updates, model risk rules, new controls). A2A-style contracts make it easier to swap or upgrade an agent implementation while keeping the process consistent and compliant because the orchestration layer stays stable.
A2A with Camunda
When implementing A2A within Camunda, you can think of A2A as the communication fabric between agents, and Camunda as the control plane that makes those communications safe and operational. For example:
- BPMN defines the “where” and “when” of agent autonomy (including ad-hoc sub-processes for dynamic work).
- DMN and explicit approvals define “must-pass” controls for regulated decisions.
- Human-in-the-loop tasks provide escalation and signoff paths.
- The process record becomes your audit trail across agents, systems, and people.
Imagine a mortgage-lending scenario that spans dozens of endpoints, legacy systems, and even third parties. The borrower submits an application and uploads the required documents. From there, the process orchestrates risk analysis, market research, and product recommendations to identify the best mortgage option.
An example process with A2A integrations is shown below.

Without a comprehensive process orchestration engine, applications such as mortgage lending can stall between compliance, underwriting, and shifting criteria because of disconnected teams and systems.
Camunda gives you a durable, stateful engine for processes that run for days or weeks. It also provides event-driven coordination to keep vendor updates and borrower actions from adding complexity, while tracking every decision and handoff and connecting to existing systems and teams via A2A.
Because all implementations are different, Camunda offers a few A2A connectors to meet different needs:
- A2A Client connector. This connector interacts with A2A agents by retrieving the remote agent’s Agent Card.
- A2A Client Polling connector. This connector polls responses from asynchronous A2A tasks.
- A2A Client Webhook connector. The A2A Client webhook connector receives callbacks from remote A2A agents via HTTP webhooks.
You can use one or all of these connectors to meet your business requirements. Let’s look at when one approach might make more sense than another.
Which connector, when?
You need to review what agents you have and what your specific requirements are before you can decide which connector to use.
If you are going to invoke an external agent or service via A2A, you must use the A2A Client connector. You can model this as a deterministic BPMN service task when the call is predictable or expose it as a tool the agent can choose from inside an ad-hoc sub-process when the plan is dynamic.
Next, you will need to determine if you want to use the webhook connector or the polling connector. If the external platform pushes the status of completion back to you, you can use the webhook connector for those inbound events. When using this approach, model the receiving side as a BPMN message catch event or a receive task, correlated to the correct process instance. This allows the process to wait durably and resume reliably, which maintains event-driven process orchestration.
Use the polling connector when the external platform cannot call you back or when inbound traffic is blocked. If you poll, be sure to govern it with timer-based backoff, a maximum number of attempts, and clear escalation paths. That avoids runaway loops and unpredictable cost.
Although we will not be taking a deeper look into how to use each one of these connectors in a process, we will highlight when you might want to implement A2A in a deterministic process or a dynamic AI agent sub-process and how to make that determination.
Implementation considerations
When implementing A2A, consider:
- What A2A agents are required and available for you to use in your process
- How they work
- If they would be best addressed through a deterministic process or as part of a dynamic AI agent sub-process
When to implement A2A in a deterministic process
Use A2A directly in the deterministic BPMN flow (for example, a service task calling an A2A Client connector) when the interaction is a known, repeatable business step and you want Camunda to enforce guardrails. For example:
- You know exactly which agent to call and what “complete” means. The response is structured, and the contract is clear, so the process can validate it.
- The step carries explicit SLAs for timeouts, retries, escalation, and compensation. Putting it in the deterministic flow lets the engine enforce those policies.
- The outcome must be explainable and auditable as part of the business process. This is essential for approvals and regulated decisions, and it preserves a clean audit trail.
- You need tight control over cost and risk. Keep retry and loop decisions in the process model rather than letting the agent decide when to try again.
Use A2A as a deterministic BPMN service task when the call is predictable with clear completion and SLAs, requires auditability, and you want Camunda to enforce timeouts, retries, and cost and risk guardrails rather than the agent.
When A2A belongs inside a dynamic AI agent sub-process
However, you might want to put A2A inside an AI Agent Sub-process connector, or use it as a tool inside the A2A inside agent’s toolset within an ad-hoc sub-process, when the agent needs discretion to decide how to get to the end goal. For example:
- If you aren’t sure which agent(s) might be required to reach a goal or the agent must select specialists dynamically, as in multi-agent patterns
- The work for the A2A agent is exploratory or exception-heavy; for example, the gathering of information, reconciling information, drafting options, or coordinating across multiple systems and agents
- You want the agent to run as part of a loop; for example, using A2A and other types of agents as one of several tools that can be selected based on context and possibly multiple times, if required

In this pattern, the deterministic process still matters because it defines the entry and exit criteria, boundaries and handoff points. By adding A2A to an AI sub-process, you also benefit from the strengths of having a variety of tools to use to reach the ultimate goal including your A2A agents.
A simple decision rule you can apply
Wouldn’t it be easier if there was just a simple rule you can apply to help point you in the right direction? This might help:
- If the question is something like “Which agent should I call, and what should we do next?” or “Are multiple agents required to help determine the goal of this process?” use A2A as a tool inside the agent sub-process.
- Alternatively, if the question is “Call this agent now, then wait up to X minutes, retry Y times, and escalate if it fails,” then using A2A (and inbound handling) in deterministic BPMN is the right direction.
For more information, we encourage you to review our documentation on the A2A Client usage patterns.
In Summary
Camunda gives you the depth and flexibility to implement A2A into your orchestrated processes with operational visibility, tracking actions and measuring cycle times for all your critical processes.
With Camunda and A2A, you can maintain deterministic gates for both policy and compliance. This is imperative in business processes, especially in highly regulated industries. You can define explicit escalation paths with the appropriate timeouts, retries, and compensations. All this with a full audit trail of actions and decisions in both the deterministic process and any agents, including A2A, that were used as part of your automation.
Stay tuned for our second blog where we put this information together and use it in a mortgage lending application that combines deterministic and dynamic processes with A2A to connect to existing applications to provide a seamless and auditable experience for mortgage customers.
Start the discussion at forum.camunda.io