What „Agentic AI" really means in Camunda
Imagine one of your complex business processes. At one point, an employee has to read an unstructured email, interpret its contents, pull the right data from three different systems, and then decide what happens next. These “fuzzy” steps have traditionally been hard to automate.
This is exactly where Camunda comes in. The core idea is simple yet brilliant: AI agents handle the fuzzy, non-deterministic tasks, while the BPMN process defines the overarching workflow and provides robust guardrails.
In practice, it works like this: you model (or already have) a standard BPMN process. At the point where the magic should happen, you place an ad-hoc subprocess. Think of this subprocess as the agent’s toolbox. Inside are the tools it is allowed to use: a service task to fetch customer data, a connector to a document-analysis service, or even a user task to hand something off to a human.
With the new AI Agent Connector, you give an LLM of your choice (OpenAI, Anthropic, Google, etc.) access to this toolbox. The agent can then—based on a goal, e.g., “Resolve the customer inquiry”—autonomously plan which tools to invoke and in what order, and then pass the result back to the process.
The key building blocks for this in Camunda 8.8 are:
- AI Agent Connector: The bridge between your process and the LLM that enables tool calling from the BPMN toolbox.
- Ad-hoc-Subprozess: A newly revitalized element from the BPMN standard that elegantly defines the scope of the toolbox and determines the execution semantics of the tool calls.
Additionally available now:
- Vector DB Connector: This lets you give the agent a memory and implement RAG patterns (Retrieval-Augmented Generation) — essential for working with documents and knowledge bases.
- MCP Client Connector (Alpha): Allows tools to be discovered dynamically at runtime from external catalogs. Many software vendors now provide such MCP servers, but using them comes with particular risks and, by design, they cannot be represented explicitly in the BPMN diagram. The MCP Connector is merely a gateway into another, implicit toolbox.
- And a bit hidden: Ad-Hoc Tools Schema Resolver Connector. This connector is called internally by the AI Agent Connector to extract tool definitions from the ad-hoc subprocess. Using it in isolation can help with debugging or when you want to implement your own agent logic if the Agent Connector doesn’t support a use case. This is straightforward because everything the agent loop needs is, by default, stored in a process variable.
The brilliant part of the native connection between the agent and Camunda: While the agent iterates and completes its tasks, it runs within the protective frame of your BPMN process. SLAs, timers, escalation paths, human approvals, and the complete audit trail continue to be governed by the Camunda engine.
How is this different from low-code agent builders or pure agent frameworks?
Some of you may know tools like n8n or frameworks like LangGraph and crewAI. Where does Camunda fit?
- Compared to low-code builders (like n8n): These tools are fantastic for quickly building automations with hundreds of integrations. Camunda goes a step further and is based on the BPMN standard. This formal semantics is crucial for complex, long-running, and audit-relevant end-to-end processes in regulated industries. Under the hood, Zeebe provides an engine built for stateful orchestration with scalability, resilience, and incident handling (Operate!).
- Compared to code-first frameworks (like crewAI): Camunda focuses on the orchestration of the entire business process, where people, legacy systems, and AI agents work together. Out of the box, the Camunda engine brings DMN, timers, escalations, and user-task handling — things you’d have to build yourself with pure code solutions.
In short: Camunda provides the operational envelope within which agents can act safely and transparently — hand in hand with the surrounding business processes.
