Several months have passed since CamundaCon in Amsterdam, and I finally had time to process and write down what stood out most: the rise of Agentic Orchestration. Since the conference, I’ve been digging deeper, running some local setups, and now I want to share how Camunda enables this pattern using familiar concepts like BPMN, service tasks, and a dash of AI.
Understanding the Roles
In discussions about intelligent automation, three terms often come up: AI agent, agentic AI, and agentic orchestration. They are related but serve different purposes. Understanding how they fit together is essential when designing a process that involves reasoning and decision-making.
AI Agent
An AI agent is a system component that receives a task and works toward a specific goal. It does not choose the goal itself. Instead, it reacts to instructions and uses available tools to carry them out. The agent can plan its steps, call services, and decide what to do next, but it does all of this based on input from outside.
Its behavior may appear autonomous, but the drive comes entirely from the environment around it. The agent does not initiate tasks. It simply responds with flexible execution logic once a task is assigned.
Agentic AI
Agentic AI describes how an AI behaves when given the freedom to reason, adapt, and choose among available options. This includes planning steps toward a goal, interpreting results, and adjusting actions based on context. The intelligence here lies in the ability to operate with a degree of independence once the task has started.
However, the goal is always provided by the user or system. Agentic AI does not imply free will or self-direction. It refers to behavior that resembles independent problem-solving, within a defined frame.
Agentic Orchestration
Agentic orchestration is the system that surrounds the agent. It defines how the goal is created, what tools are available, when the agent can act, and what conditions must be met before it can stop. This orchestration includes everything from the initial prompt to the definition of boundaries and access.
In Camunda, this takes the form of a BPMN model that includes a system prompt, a set of available tasks inside an ad-hoc subprocess, and the structure that allows the agent to work step by step. The orchestration provides transparency, logging, and control over what the agent can and cannot do.
Camunda’s Approach
Camunda doesn’t try to hide the complexity of orchestration inside a magic box. Instead, it gives you full transparency and control while layering in the power of AI where it makes sense. The agent isn’t the process. It lives inside a process, guided and constrained by BPMN.
Here’s how it works, step by step.
1. Define the Goal
The whole process starts with a system prompt, written in natural language. This prompt acts like a mission briefing for the agent. You describe:
What the agent is
What goal it should accomplish
How it should behave (cautious, fast, thorough, etc.)
When to stop or hand off control
This prompt is crafted as part of a connector and is passed to the LLM. It sets the frame for everything the agent will do:
## Prompt
You are an order status agent, a task-oriented assistant specialized in identifying and communicating the status of customer orders. You operate within a tool-based execution environment and are strictly forbidden from asking the customer for additional information. Every incoming message is from a customer. All internal collaboration must go through the ask an expert tool.
### Instructions
For every request, first analyze all available tools. Evaluate their relevance to the task and determine the most appropriate one based on the available data.
### End Criteria
You are done if you found the order. If the tools do not present a result you need to ask an expert. Stop calling any more tools afterwards.
<add more details below>
2. Provide the Tools
Next, you define the tools the agent can use. In Camunda, these are just your regular BPMN building blocks:
Service tasks for calling APIs or microservices
Connectors for cloud services or internal systems
AI Connectors for using special agents
User tasks for human input or decision-making
You don’t need to invent a new toolkit. You just model your tools as BPMN elements. The only difference is that the agent, not the user, will decide when and how to use them.
3. Enable Dynamic Execution
Now comes the clever part: placing the tools inside an ad-hoc subprocess.
An ad-hoc subprocess is a BPMN element that doesn’t define a strict execution order. Instead, it allows its contained tasks to be triggered in any sequence, multiple times if needed, or even skipped entirely. It’s like giving the agent a toolbox and saying, “Here’s everything you can use. Pick what makes sense.”
This structure enables flexibility while still keeping all executions traceable, auditable, and visualized in the BPMN model.
4. Let the AI Agent Orchestrate
The agent ties everything together. It receives the system prompt and knows the set of tools it has access to (by inspecting the ad-hoc subprocess definition and the contained task elements). It is connected to an LLM like GPT or Claude, which helps it reason and decide.
The agent evaluates the current situation, chooses a tool and calls it. After receiving the result, it decides what to do next. This loop continues until a defined end condition is met, for example, when an order is found, a resolution is completed, or a user confirms the output.
All interactions remain inside the boundaries of the process. Nothing happens off to the side.
How the AI Connector Understands Tools
In Camunda, the AI Connector enables an AI agent to interact with various tools defined within an ad-hoc subprocess. Here’s how it processes these tools:
Identifying Tools: The connector examines all activities within the specified ad-hoc subprocess. It considers activities that have no incoming sequence flows (i.e., root nodes) and are not boundary events as potential tools.
Extracting Tool Definitions: For each identified tool, the connector performs the following:
Name and Description: It retrieves the activity’s ID as the tool’s name and uses the documentation associated with the activity as its description.
Input Parameters: The connector analyzes the input mappings of the activity, specifically looking for parameters defined using the fromAi() function. This function indicates which parameters the AI agent can provide.
JSON Schema Generation: Based on the input parameters, the connector constructs a JSON schema that defines the expected inputs for the tool. This schema includes the parameter names, types, and descriptions.
Providing Tool Definitions to the AI Agent: The connector compiles the extracted information into tool definitions and passes them to the AI agent as part of the prompt. This allows the AI agent to understand what tools are available and how to use them effectively.
This mechanism ensures that AI agents have a clear understanding of the tools they can utilize within a process, enabling dynamic and context-aware decision-making.
What Makes This Powerful?
Agentic orchestration in Camunda works best when processes are:
Non-linear, where the flow depends on decisions that can’t be predefined
Data-heavy, involving interpretation of documents, emails, or user input
Unpredictable, where new tasks may appear depending on context
Hybrid, combining automated steps with human oversight
You’re not scripting behavior step by step. You’re defining a smart playground where agents can operate safely and effectively.
Final Thoughts
Camunda doesn’t replace BPMN with AI. It lets you wrap AI inside the structure and governance of BPMN. By giving agents a clear goal, a curated set of tools, and the freedom to act within a dynamic subprocess, you get the benefits of intelligent behavior without losing visibility or control.
This isn’t a futuristic concept. It’s something you can model and deploy today, using familiar tools. And it opens the door to workflows that are more flexible, adaptive, and intelligent than ever before.
My next post will dig deeper into this, highlighting a small showcase I implemented to get ore familiar with the topic. I will give insights into AWS Bedrock and also some numbers regarding costs. Plot twist: I’m not poor yet…