Building a process from scratch is one thing. Speeding up an existing process to hit specific KPIs is something else entirely.That second question is what stood out most to me about Camunda's AI Skills—the foundation ProcessOS is built on.
In real life, re-engineering almost always starts the same way: a heat map, red zones, the bottlenecks and then manual work on the diagram, step by step, until the process moves closer to the target KPIs. This is the hardest part. The more complex the process, and the more people and endpoints it has, the longer this takes.
This was tested in practice, using Camunda's open AI Skills, just like last time. This time, the test used two BPMN diagrams that already existed to check ProcessOS's ability to optimize a process for set metrics, not to build one from scratch:
- Case 1: Credit pipeline: this process has almost no AI in it. The test: will the skill add AI only where it makes sense, or try to automate everything?
- Case 2: Travel offer process: AI is already at the center, in a five-step sub-process called “AI Travel Agent.” This is the opposite test: will the skill trim the AI part where it's too much, without losing control over the decision?
For each process, a rough baseline was set: volume, time, cost, and decision quality, along with 3-4 target metrics that partly work against each other. This was done on purpose. If the metrics don't conflict, a simple fix is enough to hit them, and the test wouldn't show anything useful.
What mattered wasn't just the final “to be” diagram. It was also what the skill said along the way: does it point out trade-offs, is it honest about limits, and how does it explain each change it suggests?
Case 1. Credit pipeline: Will the skill add AI only where it's needed?
Baseline (assumed volume: 10,000 applications per month):
Target metrics, all of which had to be met at the same time:
- Cut the average processing time from about 2 hours to 20 minutes.
- Raise the share of fully automated decisions (STP) from 55% to 70%+, without pushing the default rate on the automated path above 2.5%.
- Lower the number of manual touches per application from 1.9 to 1.3, without pushing the overall default rate above 2.6%.
Pic.1- BPMN diagram: “as is”
What the skill proposed
Pic. 2- What the starting prompt looked like, with the baseline numbers. Without them, AI can't give a specific answer, and there's no way to check if a solution actually gets closer to the goal.
Before listing any solutions, the skill gave its own diagnosis:
Pic.3- The skill's own diagnosis, before proposing any fix
Next comes another example of the skill’s thinking about the whole problem, not just one solution at a time. They noticed that the STP target and the manual-touches target aren't actually independent of each other, and proved this with simple math, right in the text.
This changes the whole framing of the task. The touches target isn't a separate constraint; it comes free once the STP target is hit. All the real difficulty of the plan is in one place: how to grow the automated zone without hurting the default rate.
Pic.4-AI-skills proposals
All five proposed changes:
The skill also checked its own numbers with math, instead of just stating a result:
Pic.5-The skill checks its own numbers before calling it done
- Touches: at 70% STP, the most you'd get is 0.3 × 3 = 0.9, well under the 1.3 target. So there's no rush to split the medium-risk tier.
- Cycle time: 0.70 × ~4 min + 0.30 × T = 20 min – T ≈ 57 minutes for the remaining manual cases, down from today's 4 hours. This is the real stretch target, and it's driven by changes 4 and 5, not 1 and 2.
- Default rate: almost all the risk sits in strengthening the risk-scoring model (and, to a lesser degree, in splitting the medium-risk tier)—which is why those two are rolled out step by step, with auditing. Moving the risk check earlier, adding a timer escalation, and pre-packaging data for reviewers are all low-risk and can move faster.
The skills own advice on order: start with changes 1, 4, and 5 (low risk to the default rate), then roll out change 2 in canary/shadow mode, and only add change 3 once change 2's effect on the default rate is proven stable—so you're never trying to untangle two sources of default-rate drift at the same time.
What came out
Pic.6- BPMN diagram: “to be”.
One honest note as a process designer: if I had drawn this diagram by hand, I would probably have cleaned it up a little- removed the extra crossing arrows between the security and risk department lanes, and made the “approve (dual review)” and “approve (single review)” lines less tangled. But it's worth remembering: AI put this draft together in a few minutes, and as a starting point for a human to refine, it's more than good enough.
The skill’s own projection of the result
The skills took this all the way to working files:
- `credit_pipeline_v2.bpmn`: (lint-clean, 0 structural errors)
- `risk_scoring.dmn`: a table with a FIRST hit policy and confidence-band thresholds (credit score, fraud signal, DTI, data confidence)
- `review_routing.dmn`: a table that decides between security-only, risk-only, or both
Pic.7- DMN-risk scoring, generated by AI
Pic.8- DMN-review routing, generated by AI.
It's also worth noting: once again, the skill didn't pass off unfinished work as done. In its own words:
Pic.9- The forms weren't built and the skill said so directly
Pic.10- Three files, lint-clean by structure, with a line-by-line explanation of where each of the five proposed changes landed in the diagram.
What stood out as especially good
- Not a single AI addition without a real reason; every change is backed by a specific metric.
- The skill showed, with math, that some of the target metrics aren't independent (0.3 × 3 = 0.9), instead of treating them as three separate problems.
- Every expansion of automation came paired with a control mechanism, never on its own.
- The forms and the intentional lint warnings (`fake-join`) were clearly called out as either not yet built or done on purpose.
- It gave a recommended rollout order (what to do right away, and what to wait on until the previous step is stable), something a human architect usually has to work out separately.
Case 2. Travel offer: Will AI cut itself down, if that's the right call?
Here the task is reversed. There's no need to add AI; it's already at the center of the process, in a five-step sub-process called AI Travel Agent (Analyze Trip, Define Needs, Risk & Limit Check, Generate Offer, Predict Acceptance). The interesting question: Would the skill dare to rebuild the AI part itself, not just the steps around it?
Pic.11- BPMN diagram: “as is”
Baseline (assumed volume: 20,000 events per month):
The target metrics were set the same way -partly working against each other:
- Time to offer: reduce from 18 minutes to 5 minutes, without more compliance failures.
- Conversion: increase from 22% to 30%+, without more compliance failures.
- AI Travel Agent latency/cost: reduce from 4 min/€0.80 to under 1.5 min/€0.40, without losing quality (measured by the compliance and conversion proxy metrics).
- Share of manual escalations: reduce from 15% to 10%, without more compliance failures.
Pic.12- The prompt: diagram plus four target metrics
The main conflict: named out loud, before any solution
The skill's very first sentence wasn't about a solution. It was about the fact that some of the goals are mathematically impossible to meet without a structural change:
Pic.13- The core tension, named before any solution
Then comes the exact math: even if manual escalation drops to the 10% target, one 45-minute manual step alone adds 0.10 × 45 = 4.5 minutes—almost the whole 5-minute budget, with nothing left for the other 90% of cases. The skill's conclusion: speeding up the manual review doesn't make sense (that would defeat its purpose). The real fix is to stop tying the sending of the offer to when that review finishes.
This is the moment in the travel case where the conflict between goals was named clearly and up front, before any solution was offered, not as a side note inside an already-chosen fix, but as the frame that decides which solutions even make sense.
What the skills proposed
Pic.14- The Projected Result
The skills warned on their own that these are “reasoned estimates…not measured,” and they flagged the merged generation step and the bounded retry as the two changes that need an A/B test or a shadow-mode trial before a full rollout, because these two affect offer quality the most.
What came out
Pic.15- BPMN diagram: “to be”. The risk tier now sends every case straight into the AI Travel Agent; high-risk cases also go for confirmation, separately and without blocking, so they no longer hold up sending the offer.
Technical honesty—not just in the diagram
When asked for routing details, the skill came back with a description of the exact diagram elements (gateways, tasks, conditions) and immediately listed what still hadn't been built:
Pic.16- Gaps flagged, not hidden
What the two tests have in common
Two runs, two different diagrams, two different jobs (add AI where it earns its place/cut AI where it's excess), yet the skill's behavior turned out to be surprisingly consistent:
- Not once did it optimize blindly no “let's add/remove AI because the metric says so” without a reason.
- In both tests, the skill deliberately kept the parts that were already designed well, instead of rewriting the whole architecture just for the sake of rewriting it.
- In both tests, it was honest and clear about what was “done” versus “not done yet.”
- In both tests, the result was more than a picture; it was working files, with a clear note on what failed the lint check and why.
- One thing deserves special attention. At first, it looked like a rare exception: naming the conflict between goals up front, before any solution, by looking at the whole problem at once. But this happened in both tests, not just one. That looks like a real, repeatable ability to reason about the whole set of goals.
- To really understand what the AI did, the finished diagram alone isn't enough. In both cases, the important details of the decision only showed up in the accompanying text; the picture on its own could be misread. For governance, that's a practical lesson: the AI's written reasoning isn't a nice extra next to the diagram. It's a required part of the deliverable, and without it, a real audit isn't possible.
Honest constraints of this experiment
- The baseline numbers for both cases are made up and chosen to sound realistic and stay consistent with each other, not pulled from real production data.
- Both tests used the same set of open Camunda skills from the camunda/skills repository (camunda-bpmn, camunda-dmn, camunda-forms, camunda-ai-agents, and others), the same model (Sonnet 5), and the same architect running them, with no outside check and no large sample of runs.
- The projected metrics are the skill's own estimates, clearly marked as guesses, not a guaranteed result. Neither process was actually run in production to check the numbers against reality.
- This experiment didn't test how the skill behaves when the metrics don't conflict with each other. On simpler, more straightforward tasks, it might behave differently.
That makes this experiment an honest look at a pattern of behavior, not proof of any specific numbers—and that's how it should be read.
Takeaways
The last article showed that the skills can build a process from scratch almost as well as a person. This experiment answers a different question: how well does the same tool optimize a process that already exists, against real business metrics—especially when those metrics are stated clearly and partly conflict with each other, just like in real re-engineering work?
The answer was surprisingly consistent across both tests: whenever automation grew, it came with a control mechanism attached. Speed almost always came from removing an unneeded step, not from pushing harder on an existing one. And wherever the skills themselves weren't sure—about how accurate its forecast was, whether the DMN thresholds backed by real data , or how solid the merged AI calls were—they said so, plainly.
That doesn't mean the result can be trusted without a human checking it. It's the opposite: this kind of openness is exactly what makes a human review possible and meaningful, instead of just a formality.
How to try this yourself
ProcessOS is currently in closed beta. Access is limited and managed through Camunda—to ask about how to qualify, reach out to your Camunda partner manager.
The camunda/skills repository is open. Take your own diagram, set a rough but internally consistent baseline, and pick 3–4 target metrics. Look not just at the final diagram, but at the accompanying text too: does the skill name the trade-offs on its own? Does it flag what isn't finished? Can you tell a change made for a real reason from a change made just to make a change?
