Trusting one with a loan approval, a fraud case, or a customer’s money is not
Camunda is the platform that makes enterprise agents trustworthy by design.
From simple task agents to complex multi-agent systems, Camunda gives you the building blocks for every enterprise automation pattern.
Task agent
Acts on systems
Queries databases, calls APIs, updates records, sends communications. The LLM reasons about which tool to invoke and when. Tools are external system connections: any system Camunda can reach.
Tools are
APIs, databases, services, messaging systems
Seen in
Fraud detection, order processing, customer data management
Enterprises running these agent patterns today.
Banking · Human-in-loop agent
Agents that investigate fraud alerts end to end: querying customer data, cross-referencing transaction patterns, selecting the right response path, and escalating to human investigators when the case warrants it. Running inside a structured process with a full audit trail.
Banking · Document processing agent
Agents that read free-format customer orders — scanned letters, unstructured text — extract transaction data using OCR and on-prem AI, route to human review when confidence is low, and execute automatically when it's high. 50,000 transactions daily.
Telco · Conversational agent
Agents that guide customer case journeys — populating context from multiple systems, enriching cases with data before human agents pick them up, and escalating sensitively for vulnerability or bereavement. GenAI inside a structured orchestration layer.
Financial services · Orchestrator agent
Agents that handle trade exceptions — identifying discrepancies, querying counterparties, applying resolution logic, and escalating edge cases. Deterministic rules handle the predictable exceptions; agents handle the ones no rule anticipated.
Design
You want the agent to get senior approval before approving a loan. The obvious move is to add it to the system prompt.
“Always get senior officer approval before approving any loan.”
Under normal conditions it works. Under adversarial inputs, edge cases, or an unusual loan profile, it might not. And when it doesn’t, you have no record of what the model decided or why.
Prompts are instructions. Not guarantees.
In Camunda, you model it instead. Every tool the agent can invoke is a BPMN activity. Activities can be atomic (Query customer, Bureau lookup) or they can be a complete subflow, likeLoan decision review on the right. A subflow, once activated by the LLM, runs as a deterministic sequence of steps the agent cannot override or skip. In the example on the right, neither outcome (Issue loan offer or Send decline notice) is reachable without first going through Senior officer review.
How the full process model worksVerify
Your BPMN process is code. It should be tested like code. Camunda Process Test (CPT) runs your process against an embedded Zeebe engine (not a mock) inside your CI pipeline. Every routing path, every guardrail, every agent escalation can be asserted before a single case reaches production.
CPT generates a test coverage report showing which paths in your process were exercised and which weren’t. You can prove, to engineering, to compliance, to the business, that every branch in the model has been tested.
Test the routing logic. Test that guardrails actually block what they’re supposed to block. Test that agents escalate when expected. Test that timers fire correctly. All in the same engine your production processes run on.
Dashboard
▼ AgentLoanTest
Process: AgentProcess_LoanOrigination
Coverage: 100.0%
Run
Most agent frameworks are built for request-response patterns. An agent receives input, reasons, responds. Enterprise agents don’t work that way. They wait for external replies that take days. They coordinate with systems that go down. They handle cases that span weeks across multiple teams.
Camunda agents run on Zeebe: an event-streamed, horizontally scalable orchestration engine built for exactly this. State is persisted at every step. When an external system replies days later, the agent resumes exactly where it left off. When a tool fails, the engine retries automatically. When retry fails, it compensates, undoing completed steps cleanly rather than leaving the case in an inconsistent state.
The same engine managing a process waiting six weeks for a signature also governs an agent’s tool loop executing in under a second. One runtime. Millions of concurrent agent instances. No degradation.
Zeebe — concurrent agent instances
Agents waiting for external replies don’t consume resources. State is persisted. When the reply arrives, hours or days later, the agent resumes with full context intact. Instance B in the diagram above has been waiting three days. It will resume exactly where it stopped.
No case is left half-done. No agent run is lost. Instance D above failed and recovered automatically, visible in the diagram as a red marker followed by a retry bar.
Adding capacity means adding nodes with no re-architecting and no ceiling — millions of concurrent instances, durable state, no single point of failure.
Observe
Camunda Operate gives you a live view of every agent execution: the BPMN diagram showing exactly where the process is, the Instance History listing every step the agent took in sequence, and the Variables panel showing the agent’s context: model calls, token usage, tool definitions, and reasoning state.
End-to-end traceability isn’t a reporting feature you add later. It’s a natural by-product of running agents inside an orchestrated process. Every tool invocation, every human handoff, every routing decision is captured automatically in a single execution record you can interrogate.
When a customer calls, when a regulator asks, when something goes wrong, the answer is already there.
Process
banking-support-agent
Instance Key
225179986450
Start Date
2026-05-04 09:54:53
Status
● Active
Instance History
Variables
agent
{"state":"READY","modelCalls":2,"tokenUsage":{…}}
agentContext
{"state":"READY","toolDefinitions":[{…}]}
agentResult
{"context":{"state":"READY","metrics":{…}}
Intervene
Testing proves the designed paths work. Observation tells you what’s happening in production. Intervention is what you do when an agent encounters something outside those paths: an unexpected output, an edge case your tests didn’t cover, a case that’s gone wrong.
Camunda Operate lets you see the issue, pause the process instance, inspect the full execution record, correct variables, and resume, without redeploying anything. The process continues from exactly where it stopped, with the corrected state. Nothing is lost. Nothing has to be restarted from the beginning.
Available actions
Process
loan-support-agent
Instance Key
225179986437
Start Date
2026-05-04 02:47
Status
● Active
Instance History
GenAI is resource-intensive and can be costly. We only call GenAI when needed — through Camunda.
Buddhika Hanwella
iBPM Engineering Manager, VodafoneThree
Agents orchestrate. Camunda has been the orchestration company for over a decade.
Task agents automate tasks. Orchestrator agents coordinate them: reasoning about which agents to invoke, in what order, with what context, and what to do when something fails. This is a different kind of agent. And it’s what makes multi-agent systems coherent rather than chaotic.
An orchestrator agent manages the higher-level process and delegates to sub-agents, each running in their own scoped subprocess, with their own tools and their own inner orchestration. The orchestration layer owns the handoffs, passes context, handles failures, and maintains a single audit trail across the entire system.
Sub-agents can themselves be orchestrators, coordinating further agents below them. The pattern is recursive: the same model all the way down. You don’t need custom coordination code between agents. You don’t need a separate framework to manage the system. The orchestration layer does it.
When something fails (an agent times out, a tool returns an unexpected result, a sub-agent escalates), the orchestration layer handles it. State is preserved. The system doesn’t leave cases in an inconsistent state.
Example: loan origination
Camunda is the orchestration layer. Not a model provider. Not an agent framework. It coordinates whatever you bring, and whatever changes next year.
The AI Agent connector supports Anthropic, Amazon Bedrock, and any LLM with an OpenAI-compatible API. Swap the model without changing the process. The orchestration logic stays valid.
MCP and A2A protocols connect agents regardless of where they were built: LangChain, CrewAI, Dify, or custom. The agents you have today and the ones you'll build tomorrow.
SAP, Salesforce, ServiceNow, core banking, legacy APIs, connected once via the integration layer, available as tools to any agent in any process. One connector, many consumers.
The process logic is BPMN, an ISO open standard. It is portable across infrastructure, vendors, and whatever the AI landscape becomes next year.
Visit Camunda MarketplaceAI agent orchestration is the layer that governs when agents run, what tools they can access, what happens when they fail or produce unexpected results, and how their decisions are recorded. In Camunda, agents run as first-class participants in BPMN processes, coordinated by the orchestration layer, not by other agents.
Inner orchestration is BPMN governing what happens between an agent's reasoning and its actions. Every tool the agent can invoke is a BPMN activity inside an ad-hoc subprocess. The LLM selects which tools to use, but the orchestration layer controls whether and how each tool executes. Guardrails, human review, and compliance checks are structural requirements embedded in the process, not prompts the model may or may not follow.
Structurally: by making approval steps, compliance checks, and escalation paths part of the BPMN process rather than instructions in the system prompt. A prompt that says "always get approval before deleting" is advisory. A BPMN subprocess that requires human approval before a delete action executes is enforced: the agent cannot bypass it regardless of what it reasoned.
Using the orchestrated participation pattern: an orchestrator agent manages a higher-level process and delegates to sub-agents, each running in their own scoped subprocess. The orchestration layer owns handoffs, passes context, handles failures, and maintains a single audit trail across the entire system. Sub-agents can themselves be orchestrators. You don't need custom coordination code between agents.
Yes. The AI Agent connector supports any LLM with an OpenAI-compatible API, Anthropic, and Amazon Bedrock. MCP and A2A protocols connect agents regardless of the framework they were built in: LangChain, CrewAI, custom builds, or anything that exposes the right interface. Camunda is the orchestration layer, not an agent framework or model provider.
Talk to the team about your agent architecture, or start building today.