Delivering A2A Orchestration with Camunda: A Practical Example

In part one of this two-part series, we gave you the foundation on A2A, how it can be implemented in deterministic and dynamic processes, and Camunda’s implementation of these capabilities to our customers. Now let’s take a journey into a mortgage lending example that shows the implementation of this functionality, blending deterministic logic with embedded agent behavior for unpredictable paths.

Business problem

Mortgage lending requires significant integration with a wide variety of systems, departments, and operations including:

• Credit bureaus for credit history and scoring
• Property assessment applications for valuation and address verification
• Company business rules encoded in decision models
• Underwriting risk analysis performed by specialized AI agents
• Market researchers that source current interest rates

In some cases, interacting with these systems might be a simple REST call. However, in others, you may need to reach existing agents, trigger a human review, access decision tables (DMN), search knowledge bases, or query CRM systems.

The challenge isn’t any single call; it’s orchestrating all of them in a coherent, auditable, end-to-end process where every step knows what came before it and what gates must be satisfied before the process can proceed.

This is the challenge that is presented in our mortgage concierge example. In this example:

1. The mortgage applicant provides pertinent financial details and proposed property address.
2. The applicant risk is assessed to determine if this is a good candidate for a mortgage.
3. Using business rules, research is executed to find applicable mortgage rates for the individual based on the risk analysis.
4. The property value is verified for the confirmed property address.
5. The applicant (or loan officer) is presented with initial mortgage rates and a recommendation on how to proceed with the proposed property.

After assessing this business challenge and determining the desired outcome, we can begin to build the process to take advantage of built-in constructs in Camunda. The elements in our process will access existing A2A agents at our fictitious mortgage lending organization with our A2A connectors.

Process building approach

Camunda uses the BPMN standard to model the way your business actually runs. You design in Camunda Modeler, then orchestrate against real systems and data in Zeebe. Large language models can assist, but the source of truth is your services, events, and rules—not an LLM. Essentially, Camunda serves as your control plane.

How we determined the process flow

Our mortgage lending scenario required us to make a fundamental architectural decision for every step. In other words, should this be a deterministic BPMN task, or should an AI agent decide how to handle it (dynamic orchestration)?

In order to determine our process modeling approach, we evaluated each step in the process against the decision criteria provided in part 1 of our blog series:

• If the call is predictable with clear completion criteria and SLAs and we need Camunda to enforce timeouts, retries, and cost guardrails, we use A2A in a deterministic BPMN service task.
• If the agent needs discretion to choose which tools to invoke, the work is exploratory or exception-heavy, or multiple agents might be needed dynamically, we place A2A inside an AI Agent sub-process.

The result for our scenario is that we implemented both approaches in the same application, selecting each pattern based on the nature of the work and outcome required.

First pattern: Flow using deterministic process with A2A

For the borrower-facing experience, where the user completes a form and expects a clear, step-by-step evaluation, we implemented a fully deterministic BPMN process. Each step in the flow has a clear predecessor and a clear output that the next step depends on, as shown in the following BPMN model.

Based on the flow of information and how earlier details feed into later steps, the following flow was created for this pattern:

1. Mortgage applicants apply for a loan online by entering relevant financial information and the subject property address through the customer portal.
2. The property location is verified using a Google Places API integration, which auto-completes and validates the address. This ensures we proceed with confirmed information and eliminate loopbacks later in the process.
3. A Gemini 3 Pro A2A agent is provided to do risk analysis based on the applicant’s income, debts, and credit score. This is an existing agent that has been trained and evolved over time with our mortgage criteria.
4. A locally hosted A2A market research agent finds applicable mortgage rates for the individual based on the risk analysis and the property value. A locally hosted agent is used here to preserve data privacy, ensuring that the financial profile data remains within our infrastructure boundary.
5. The property value is verified against the confirmed property address using a service call to our internal property assessment system.
6. A mortgage recommendation is synthesized and presented to the applicant (or loan officer) with initial rates for the proposed property based on all the data gathered in the process.

Why deterministic A2A was the right choice for pattern one

We elected to implement this particular process using deterministic BPMN because of the heavy sequential dependencies:

• The market research agent requires output from risk analysis.
• The final recommendation requires output from both agents in addition to the property verification.

And each step has a clear contract: structured inputs, structured outputs, a defined notion of “complete.” These requirements were crucial to determining the proper pattern for using A2A in our BPMN process.

Standalone service tasks for the A2A calls in this process provide many technical advantages, including:

• Enforced SLAs: Each A2A task is configured with a response timeout (PT1M). If the agent doesn’t respond, Camunda takes care of the escalation, not the agent.
• Structured error handling: Boundary error events are attached to both the risk analysis and market research tasks. If either agent fails, the process routes to a centralized error handler that updates the user interface with a clear error state.
• Auditability: Every intermediate result through the process flow (risk assessment, market rates, property verification) is stored as a named process variable (riskAnalysisResult, marketResearchResult), creating a complete audit trail visible in Operate.
• Retry governance: With BPMN, retries are defined with a backoff (timer-based delay using a PT5S backoff), so the process controls when to retry, not the agent.

Configuring the A2A connector for this scenario

The A2A client connector is used in standalone mode for each A2A agent call. Here’s what that looks like for the risk analysis step in the process:

In this case:

• The polling response retrieval is used, which indicates an immediate response state.
• The A2A Client Polling connector is used to retrieve the results.
• The response variable returned from the sent message will be stored in the riskAnalysisResult variable.

You can find some additional key configuration choices for the A2A Client connector below:

Setting	Value	Why
Connector mode	Standalone	Direct, single-turn message exchange; no AI agent orchestration layer needed
Operation	Send message	A prompt is sent with financial data and expects a structured risk assessment as a response
Message text	FEEL expression composing income, debts, credit score	Data gathered in prior process steps is serialized into the agent’s prompt
Response retrieval	Polling	The A2A agent may take several seconds to complete analysis; polling lets the process wait durably
Response timeout	PT1M	One minute maximum; if the agent hasn’t responded, escalate
History length	3	Include recent context for multi-message scenarios
Result variable	riskAnalysisResult	Named variable for downstream consumption and audit

The result from the underwriter agent is passed to the market research agent using a FEEL expression that serializes the previous output: "Find rates for this risk profile: " + string(riskAnalysisResult). This chaining pattern, where Camunda stores one agent’s output and feeds it to the next, is one of the core strengths of deterministic A2A orchestration. The process variable acts as the handoff mechanism, and every intermediate state is inspectable.

Second pattern: flow using AI Agent sub-process with A2A tools

Our same mortgage concierge example also implements a second architectural pattern for situations requiring more agent autonomy. In this flow, which we call the “compliant” flow, a customer interacts through a chat interface and the system handles open-ended questions, multi-turn conversations, and exploratory analysis.

In this pattern, A2A connectors are configured to be tools offered to an AI agent, rather than standalone mode. The process flow for this example is:

1. The broker agent using the AI Agent Sub-process connector receives the user’s message and decides which tools to invoke based on the conversation context.
2. The toolbox for this broker agent includes multiple A2A agents in addition to several other tools:
   • The underwriter A2A agent is used to determine risk analysis. This is the same agent that you saw in pattern 1.
   • The researcher A2A agent is used to obtain market rates. This is the same agent that you saw in pattern 1.
   • The country risk score DMN business rule task uses a deterministic decision model for assessing geographic risk.
   • The entity segment risk DMN business rule task uses a deterministic decision model to obtain entity classification.
   • The previous conversation search is a Vector DB connector (RAG) that retrieves relevant past interactions for additional context.
   • The Salesforce lookup is used to query Salesforce, our CRM system, for related opportunities.
     

1. The judge agent uses the AI Agent Task connector to evaluate the broker agent’s output for a level of confidence. If the confidence interval exceeds the threshold, the process auto-completes. If not, it routes to a manual mortgage process (human-in-the-loop sub-process) for subsequent review.

Why AI agent tools were the right choice for pattern two

In this process flow, we needed a dynamic approach to how inquiries were handled:

• The user’s intent can vary. A customer might ask about rates, risk, both, or something unexpected. The agent needs the option to choose which specialists to consult in order to resolve the inquiry effectively.
• Multi-turn context matters. The AI Agent connector preserves conversational state across interactions so each new turn can reuse prior inputs and decisions (for example, via process variables or external memory). As the conversation continues, the agent responds with full awareness of what happened earlier in the process, not just the latest message.
• The toolbox goes beyond A2A. The agent can combine A2A calls with other BPMN elements such as DMN evaluations, vector search, and CRM lookups in a single reasoning loop. This isn’t a fixed sequence; it’s dynamic planning.

In this pattern, the A2A Client connector is configured with connectorMode.type = "aiAgentTool" instead of "standalone". The key difference is that the operation and parameters are determined dynamically by the AI agent at runtime via toolCall.operation and toolCall.params, rather than being hard coded in BPMN.

How the A2A connector is configured in tool mode

You can find additional key configuration choices for the A2A Client connector, used in AI agent tool mode, in the following table:

Setting	Value	Why
Connector mode	AI Agent tool	The AI agent decides when and how to invoke this tool
Operation	Dynamic (toolCall.operation)	The agent chooses sendMessage or fetchAgentCard at runtime
Parameters	Dynamic (toolCall.params)	The agent composes the message based on conversation context
Response retrieval	Polling	Same async handling as standalone
Result variable	toolCallResult	Collected into the ad-hoc sub-process output collection
Gateway type	a2aClient	Marks this as an A2A-capable tool for the agent gateway

Comparing the two patterns

Now that you have read why the process goal and requirements can lead to which A2A connector pattern to select for your process, let’s take a moment to compare the patterns.

Both patterns use the same A2A agents (underwriter and researcher) and the same task type (io.camunda.agenticai:a2aclient:0), but the difference is in who controls the orchestration of the agents:

Dimension	Pattern 1: Deterministic (Wizard)	Pattern 2: AI Agent Sub-process (Compliant)
Who decides what to call	BPMN process model	AI agent at runtime
Connector mode	standalone	aiAgentTool
Message composition	FEEL expressions in BPMN	Agent composes from conversation context
Execution order	Fixed linear sequence	Dynamic, agent-driven
Available tools	A2A agents only	A2A + DMN + Vector DB + CRM + more
Error handling	BPMN boundary events	Agent retry + judge agent evaluation
Human escalation	N/A (automated end-to-end)	Judge agent confidence gate → manual review
Best for	Predictable, SLA-bound, auditable steps	Exploratory, conversational, multi-tool reasoning

The biggest takeaway is that this isn’t a one or the other choice. In practice, you often combine both patterns in the same solution. The deterministic flow handles the critical path where compliance and SLAs demand full control while the dynamic flow handles the conversational, exploratory paths where agent intelligence adds the most value.

How it all comes together

Now that you have the technical approach, let’s see how this delivers business value to the mortgage applicant with a simple walkthrough.

The user experience

To initiate the process, an applicant fills out the application form that is presented in our fictitious company portal for mortgage applications.

The applicant updates the application with the property details.

Using an integration with the Google Places API, we can automatically find and validate the property address, ensuring we proceed with confirmed, standardized address data. This seamless integration eliminates entry errors and prevents costly loopbacks later in the process.

After the application is submitted, the underwriter agent immediately begins its risk analysis. The user interface (portal) presents an animated checklist showing each evaluation step in real time: credit verification, debt-to-income calculation, loan-to-value (LTV) ratio assessment, and regulatory compliance checks.

Because Camunda tracks all activities in the process, the applicant can see real-time status updates as each agent completes its work. The UI shows progress through each step: risk analysis, market research, and property verification, giving the applicant transparency into the process.

The process concludes with recommendations presented for various mortgage options as a result of the multi-agentic orchestrated mortgage lending process.

Behind the scenes

With Camunda, there’s no black box. You get end-to-end observability of both the process and the agent logic. Operate provides a real-time view of every process instance, including:

• Which agents are active and their current state (running, completed, incident)
• The inputs and outputs of every call, including your A2A agents, stored as inspectable process variables
• Variable values as the process executes (and when completed), from initial application data through agent responses to the final recommendation
• The ability to see an error immediately (for example, an agent times out, a connector fails, or a boundary event fires), trace the root cause, and retry or resolve directly from Operate
  

When debugging or auditing, you don’t guess; you trace, inspect incidents, and replay or retry steps. The result is auditable agent behavior, faster root-cause analysis, and fewer surprises in production.

For the second pattern flow, Camunda provides the same visibility into the AI Agent sub-process. Users can see which tools the agent chose to invoke, the order of invocation, and the judge agent’s confidence evaluation, all as an inspectable process state.

A2A empowers your agentic orchestration

Using A2A in your agentic orchestration makes it easier to scale in regulated environments. As we’ve shown in this mortgage lending example, this approach provides:

• Stronger security posture: PII handling is controlled at the process level so you can decide which data flows to which agent. Approved A2A endpoints minimize attack surface, and every agent interaction is recorded for audit.
• Built-in reliability: When A2A is used in deterministic flows, standardized retries and boundary error events provide predictable recovery, turning partial agent failures into well-defined state transitions.
• Versioned, consistent behavior: Prompts, tool configurations, and service contracts are encoded in the BPMN version. When you update an agent’s capabilities or swap a model, you deploy a new BPMN version. In-flight instances continue on their original version while new instances pick up the changes.
  NOTE: You can migrate in-flight instances if that is the desired approach.
• Unified observability: Whether the A2A call happens in a deterministic service task or inside an AI Agent sub-process, every interaction flows through Camunda’s tracing and metrics. You get end-to-end SLOs, early signals on AI drift or agent latency, and a single pane of glass across all your orchestrated processes.
• Agnostic to the underlying agentic technology: These patterns illustrate situations where agents are running outside of Camunda (regardless of the technology) and you need an end-to-end control plane to orchestrate them. While Camunda can easily be leveraged to build agents across any use case, these examples show how you can also use externally built agents interacting through a first-class protocol.

The two patterns we’ve demonstrated, deterministic A2A for the critical path and AI Agent sub-process for exploratory reasoning, aren’t competing approaches. They’re complementary tools in your orchestration toolkit.

Start with the decision framework from part one of our two-part blog series, evaluate each step against your requirements for control versus autonomy, and build the process that matches your business reality.

For more information on how A2A and AI Agents can help you solve your business needs, check out our website and documentation.