A practical look at where AI skills accelerate process orchestration and where human judgment still matters: I gave Camunda’s open AI skills two processes I had already designed by hand, then compared the architecture, trade-offs, and results.
Many people still don't trust AI agents with business processes. The common belief is that models just aren't reliable enough for this level of complexity.
I used Camunda's published open-source AI Skills with Claude to evaluate the underlying ProcessOS concept on my own process models. After running this experiment, I came to a different conclusion. In my experience, the quality of the result depends much more on how well the AI agent is designed, how clearly its objective is defined, and how well its scope is constrained than on the LLM itself.
I wanted to test this myself. I took Camunda's open-source AI skills, compatible with Claude Code, the Claude desktop app, Cursor, GitHub Copilot, and other AI agents, and two processes I had already designed by hand before this experiment:
- A logistics scenario: recovering from a delayed shipment.
- A bank offering a personalized travel package to a customer about to take a trip.
Both are built on the same principle: the agent reasons inside an ad-hoc sub-process, while everything around it stays deterministic and controlled—auditable end to end.
I gave the skill the same business scenario I'd already solved myself, without showing it my diagram, and see what comes out.
Example 1: Recovering from a delayed shipment
The first test was the simpler process from logistics.
Scenario: an agent reacts to a delivery delay, proposes a solution, a DMN table checks compliance, and a human steps in when confidence is low.
Pic.1 Example of a diagram by a human
What I did: setting up
To keep the experiment clean, I ran Claude from the command line, locally on my machine, instead of the usual chat interface. I cloned the camunda/skills repo and gave it a simple brief:
- A delay is detected
- The agent investigates
- Tracks the shipment
- Gathers context
- Looks for alternative routes
- Calculates cost
- A DMN table checks compliance (SLA, cost, carrier restrictions)
- If confidence is low, escalate to a human via Teams
- Otherwise, execute automatically
Pic.2 Claude setup from CMD
I deliberately ran this in isolation on my own machine, with no connection to client infrastructure, no c8ctl, no live cluster: test it in isolation first, before letting it near anything real.
What came out: 10 minutes, 3 files
Without c8ctl for official linting, the skill built its own check: valid XML/JSON, no duplicate IDs, all element references resolved, no overlapping visual elements, all connectors orthogonal. All done through Python scripts written on the fly.
Pic.3 Results of experiment
After 10 minutes and 5 seconds, I had three files: a BPMN process, a DMN decision table, and a form for human review.
Pic.4 BPMN diagram generated by AI
Pic.5 DMN generated by AI
Pic.6 Form generated by AI
What matched: how close did it get?
Bottom line: of 8 comparable elements, 6 matched exactly, and 2 matched with caveats. My manual version took about 20 minutes to draw, and that's with the requirements already clear in my head. The skill's 10 minutes covered the entire path: from reading the brief to validated files.
Two differences are worth digging into.
- Number of tasks inside the agent (7 vs. 4). In my version, I broke the steps into more granular units: a separate step for "check warehouse quota," a separate one for "get carrier SLA," and so on. The skill merged some of these into broader tool calls. Both approaches work: more tools mean more observability and control at each step; fewer tools mean easier maintenance and fewer LLM calls per iteration. This is an architectural trade-off that a human needs to make, someone who knows exactly what needs to be logged and reused in that specific infrastructure.
- Explicit reject path. My manual version had no separate branch for when the agent can't find a suitable alternative. The skill added one on its own—an objective improvement, since it caught an edge case I missed on my first pass. But adding the branch isn't the same as deciding where it should lead: fail the process, escalate to a human, or retry with relaxed criteria. That decision still belongs to the person who owns the process.
Example 2: Support of the travel offer from the bank
The first scenario was maybe too simple. The second example was more difficult. Not only an agent, but an agent embedded in the middle of a more complex deterministic process, with steps before and after, including a parallel human branch that merges back into the main flow.
Pic.7 BPMN designed by a human
What I did: round 2, no terminal this time
I ran the first test from the terminal. This time I wanted to try a different path—no command line, straight in the Claude desktop app: I turned on code execution in Settings, uploaded the camunda-bpmn and camunda-ai-agents skills as regular files via Customize–Skills, and wrote the brief in a normal chat.
Pic.8 Uploaded skills in Claude
Scenario: A customer is about to travel. The AI agent analyzes the trip and prepares a personalized offer while ensuring it complies with business rules.
- Travel intent is detected (flight or hotel booking).
- Customer profile and context are enriched.
- DMN validates consent, eligibility, and segmentation rules.
- AI agent analyzes the trip, predicts acceptance, and generates the best offer.
- High-risk cases are routed to a human for review.
- DMN performs a final compliance check.
- The offer is sent to the customer.
- If accepted, the travel package is activated.
Pic.9 Prompt for creating a process
What came out: 17 minutes, a complete agentic workflow
After 17 minutes, almost twice as long as the first test, but the diagram is also almost twice as complex—the skill returned a finished BPMN diagram right in the chat. I watched the whole process: the agent reading the uploaded skills, designing the process structure, writing the BPMN XML, validating it, and saving the finished file locally. Nothing happened "behind the scenes."
Pic.10 Observe while running a skill
Pic.11 Resulted BPMN by AI
What matched: how close did it get?
Bottom line: of 17 comparable elements, 15 matched exactly, one was partial, and one difference turned out to be architecturally significant.
The most interesting difference
In my version, high-risk escalation is modeled as a boundary event, a non-interrupting message event attached directly to the ad-hoc sub-process boundary.
The logic: the agent can signal "I need a human" at any point during its run, without waiting for all internal steps to finish. If risk becomes obvious as early as the "Check risk and limits" step, there's no point burning two more LLM calls on "Generate Offer" and "Predict Acceptance"—architecturally, that's a deliberate trade-off favoring faster reaction and lower token spend where an early exit is worth it.
The skill instead placed a plain exclusive gateway after the agent finishes—meaning the agent runs through all its steps first, and only then does a separate check to see whether the risk score came back high.
Both approaches work and are both architecturally sound—this isn't a mistake by the skill, just a different trade-off. A check-after-the-fact is simpler to model, simpler to test, and simpler to explain in an audit: one single decision point, instead of an agent that can "interrupt itself" at an arbitrary moment. The event-based approach pays for its speed and LLM savings with harder auditability: to understand why the process stopped, you have to look not at one shared checkpoint, but at exactly which moment inside the agent the boundary event fired.
Tellingly, the camunda-ai-agents skill itself documents the boundary-event pattern for escalation and uses it in the first, simpler test. Here, in the second scenario, it didn't reach for its own more advanced pattern. This illustrates something fairly predictable: the more complex the scenario, the more forks in the road where there's no single correct architecture, only trade-offs.
And deciding what matters more here: faster agent reaction and LLM savings, or audit simplicity and predictability for the compliance team, is a call only a human can make, someone who understands both sides of the trade-off and knows this particular business's priorities.
Which model is being used
The AI Agent—specifically its sub-process variant, which camunda-ai-agents uses inside the ad-hoc sub-process—is provider-agnostic. It supports Anthropic, Amazon Bedrock, Azure OpenAI, Google Vertex AI, OpenAI, and any OpenAI-compatible provider.
For my examples, I used Claude Sonnet 5 by Anthropic. But I understand that for the banking scenario, it's a governance question. In regulated industries, the choice of LLM provider is rarely about "which model is smarter;" it's usually about which infrastructure security has already been approved. A direct call to a public API often won't pass a compliance review if data must remain within a perimeter already certified under SOC 2 or ISO.
The AI Agent connector's provider-agnostic design solves exactly this problem: a bank can plug in whichever model is already running inside its own cloud environment, without rewriting the process.
Where the human is still needed
Both tests point to the same conclusion. A skill can't tune a process to the nuances of a specific business. Where exactly should the confidence threshold sit… 0.7, 0.85? Which carrier exceptions are real and which are theoretical? What does "needs review" actually mean for this specific bank's compliance team?
Taking a process from structurally correct to actually right for the business is still work for someone who understands both the business process and the modeling tool it's built with.
Still, across both examples, I compared 25 process design elements between my manually created processes and AI skill-generated versions. 21 matched exactly, for an 84% exact match. This is not a formal benchmark: two processes are far too small a sample for that. But as a practical test against processes I had already designed independently, the result was stronger than I expected.
A human without AI is thorough but slow. And manual work isn't immune to mistakes either; the nature of the mistakes is just different: not necessarily an architectural gap, but an oversight from holding too many details in your head at once.
AI without a human is fast and architecturally sound: in both examples, the structure came out correct for the vast majority of elements. But it doesn't know what confidence threshold this specific compliance team needs, or which carrier has been a problem for the last six months and how to prevent that going forward—those details aren't in the brief, they live in the business's head.
The real advantage is the combination: a human who can read what the AI built and knows exactly what to adjust. The skill accelerates the work. Human judgment determines whether the result is right for the business.
Ongoing in ProcessOS
Both tests are one-time generation through Claude and the open camunda-skills—this isn't ProcessOS yet. In ProcessOS, the model can be continuously tuned: adding constraints, refining context, watching the system adapt in real time. But it all runs on the same foundation. And the fact that this foundation holds up so well on its own—without the ProcessOS wrapper, without a live cluster, without the official c8ctl BPMN lint that Camunda uses to check BPMN inside its own pipelines—is a good sign for what's built on top of it.
Turning a modeling skill built up over years of manual work into something coded, reusable, and instantly reproducible is a real step forward for process orchestration as a field.
Try it yourself
ProcessOS is in closed beta. Access is selective and handled through Camunda. Reach out to your Camunda partner manager to explore the qualification path.
The camunda/skills repo is open. If you've modeled processes by hand, give the skill the same task without showing it your diagram, and see how close it gets.
Already experimenting? Please, share your results in the Camunda Community Forum. It would be interesting to see how this comparison plays out on processes other people have built.
