Camunda released the first iteration of agentic orchestration in early 2025 and, since then, we've worked with over 130 customers to explore the potential of this technology. This led to more than 30 working prototypes aimed at production, spanning different industries, use cases, and requirements. This paper will reflect the best practices we've developed from these engagements to help build and design Agents in Camunda.
An end-to-end business process will contain two categories of orchestration. Most common are the aspects of the process that are predictable and repeatable: deterministic orchestration.
Here, you can easily describe the state transitions from one point to the next and therefore model those expected transitions in BPMN with tasks, gateways, and events. This is probably what you think about when you think about a business process. An invoice needs to be approved and there are specific steps that are required based on the context and this is intended to be predictable and repeatable (fig 1).
The second category is the unpredictable and variable: dynamic orchestration. These aspects of a process often have too high a variety of potential outcomes and/or inputs, such that modeling them can either be impossible or impractical.
In the past, this category would be solved with case management. This aims to give visibility into the execution but is often unable to add any value in automation or efficiency, because case management requires a human user to move the process forward, make decisions, and understand the context. This means that, overall, the aspect of an end-to-end process that has potential for a high return on investment for automation is often the dynamic part. So, to solve this problem in your processes, Camunda offers agentic orchestration.
Invoice dispute resolution is a good example of where agentic orchestration can help. Details of a dispute can vary greatly, and how those disputes are resolved can be unpredictable. So instead of attempting to model the steps involved, you simply model the tasks and flows that may be required and then let the LLM decide what gets triggered based on how the context of the request evolves (fig 2).
Agentic orchestration blends the dynamic use cases with deterministic ones so that you have a complete process spanning both methods of orchestration end to end. It's still part of the same process engine. When thinking about how this works in reality, it's best to imagine these two aspects of process automation within the same process (fig 3).
Agents are first-class citizens in the Camunda ecosystem; they benefit entirely from the existing feature set of Camunda's engine. They also slot into the fundamentals of what Camunda is solving: a transparent, reliable end-to-end process orchestrator. In this ecosystem, the agent is intended to be used in scenarios where traditional deterministic logic isn't able to solve the problem. It's used when a lot more flexibility and dynamic execution are needed.
Because a process agent is an extension of the process engine's responsibilities, there are specific design principles that should be adhered to in order to ensure reliable and maintainable execution. By designing the agent in BPMN, the agent itself is scoped as a subprocess—specifically an ad hoc subprocess. Within this subprocess, the process engine no longer decides what tasks are executed. This responsibility is handed over to an LLM. But importantly, the process engine is still responsible for doing the actual execution of those tasks.
It's very important to understand that each agent orchestrator built in Camunda has two participating actors working together to make the process run:
- The LLM focuses entirely on the reasoning related to how the process should proceed and gives the orders, determining which tools need to be executed to move closer to solving the goal.
- The Camunda engine (Zeebe) is responsible for the execution of those orders, running the tools and returning the results to the LLM.
This pattern is designed to ensure that both elements of the agent are doing what they're best at so that the benefits of those components can be fully realized.
Coming up next in this blog post series, I'll be exploring in detail the best practices for designing agents, how tool calls should be designed and implemented, and once all that is up and running, how to guardrail your agents.
