AI Is Starting to Redesign the Business Process
Camunda's latest experiment suggests that AI is moving beyond performing workflow tasks and beginning to redesign executable processes around business outcomes.
Enterprise AI first entered the business process as an assistant.
Then it became a worker: extracting documents, classifying requests, making recommendations and invoking applications.
Now it is approaching a more consequential role.
In an experiment published on 3 September, Camunda asked AI to examine existing BPMN processes, reconcile conflicting performance targets and produce redesigned process models with supporting DMN decisions.
The experiment was small, vendor-led and based on invented rather than production data. It does not prove that an autonomous process architect is ready for deployment.
But it reveals an important direction:
AI is moving upstream from performing work inside the process to redesigning how the process itself should operate.
This Was Not Diagram Generation
Generating a plausible workflow diagram from a written description is becoming ordinary.
Redesigning an existing process is harder.
The new design must preserve what already works, identify the real constraint and improve several outcomes without silently damaging another one. Faster processing may increase risk. More automation may reduce review quality. Fewer manual escalations may create compliance failures.
Camunda tested its open AI Skills on two contrasting processes.
The first was a credit pipeline with targets for cycle time, straight-through processing, manual effort and default risk. The second was a travel-offer process in which AI already occupied an unnecessarily large five-step subprocess.
One test asked whether AI would add automation only where it created value. The other asked whether it would remove AI when the existing design used too much of it.
That second question is particularly revealing. A system optimising for “more AI” would fail it.
The AI Found the Constraint Behind the KPI
In the credit process, the requested targets included increasing straight-through processing from 55% to at least 70% and reducing manual touches from 1.9 to 1.3 per application.
The AI recognised that these targets were not independent.
If 70% of applications required no manual intervention and the remaining 30% required no more than three touches, the average would already be:
0.30 × 3 = 0.9 touches
The manual-touch target was therefore not the real problem. The difficult part was expanding automated credit decisions without increasing defaults.
That diagnosis changed the proposed implementation sequence.
Low-risk changes—moving checks earlier, preparing information for reviewers and introducing timer escalation—could be implemented first. Changes to risk scoring required shadow or canary operation. Further automation should wait until its effect on default rates became measurable.
In the travel process, the AI found a different contradiction.
Even if manual escalation fell to 10%, a 45-minute review would contribute 4.5 minutes to the average cycle time. That consumed almost the entire five-minute time-to-offer target before any other activity occurred.
The answer was not to demand impossibly fast human review. It was to remove that review from the critical path and let the appropriate confirmation proceed separately.
This is more than task automation. The AI reconsidered dependencies, critical paths, risk concentration and rollout order.
The Output Was Executable
The experiment did not end with recommendations.
For the credit process, the AI generated:
- a revised BPMN model;
- a risk-scoring DMN table;
- a review-routing DMN table;
- structural validation results;
- an explanation of where each proposed change appeared;
- explicit warnings about forms and other components that had not been built.
Once AI produces machine-readable BPMN and DMN, it participates directly in the software lifecycle of the business process.
The pattern begins to resemble AI-assisted development:
- The existing process becomes the baseline.
- Business outcomes become acceptance criteria.
- AI proposes and implements a change.
- Tools validate the resulting artifacts.
- A human reviews the model, assumptions and trade-offs.
- The process is simulated or tested before promotion.
The process model is no longer merely documentation. It becomes an engineered artifact that an AI agent can modify.
A Diagram Is Not Enough
The most important information was not always visible in the generated BPMN.
It appeared in the accompanying explanation:
- which targets conflicted;
- which calculations used assumed data;
- which changes concentrated business risk;
- which controls should accompany greater automation;
- which elements remained unfinished;
- which proposals required production testing.
A plausible diagram can conceal a weak argument.
For that reason, an AI-generated process change should include more than an updated model:
| Artifact | Purpose |
|---|---|
| BPMN and DMN | Define the proposed behaviour |
| Process diff | Show what changed |
| KPI rationale | Connect changes to intended outcomes |
| Assumption register | Identify unverified inputs |
| Risk assessment | Show where improvement may create exposure |
| Validation results | Record structural and simulation checks |
| Rollout plan | Define approval, testing and rollback |
The required explanation is not the model’s hidden chain of thought. It is an engineering record of inputs, assumptions, decisions, known gaps and expected consequences.
Without that record, meaningful review is impossible.
Governance Moves into Process Design
When an agent performs an existing task, governance asks whether the action was authorised.
When an agent changes the process, governance must also ask:
- Who selected the optimisation objective?
- Which data established the baseline?
- Which controls were immutable?
- Who approved the new process version?
- Was it tested against historical cases?
- Which metrics would stop or reverse deployment?
- Can the previous model be restored?
An optimisation agent should not be able to remove a compliance review simply because doing so improves cycle time.
Some elements must therefore be protected. Others may change only through an approval workflow. Process definitions require version control, promotion rules and ownership comparable to production software.
The deterministic workflow around the design agent may become as important as the workflow it generates.
The Evidence Is Still Limited
Camunda’s experiment should not be read as proof of autonomous process optimisation.
The baseline numbers were invented. Projected improvements were estimates generated during the same exercise. Neither redesigned process was executed in production.
Both tests used the same:
- Camunda skills;
- AI model;
- process architect;
- experimental method.
There were only two runs and no independent evaluation.
The resulting files being structurally valid proves that they can be opened and interpreted. It does not prove that credit risk, conversion or compliance outcomes will improve.
ProcessOS also remains in closed beta, while the public camunda/skills repository describes its components as a technical preview.
The correct conclusion is therefore not that AI can now replace the process architect.
It is that AI can produce process-redesign hypotheses quickly enough to change how the architect works.
A Safe Starting Pattern
The first production use should be controlled:
- Select a well-understood process with reliable event data.
- Freeze the approved model as the baseline.
- Define measurable objectives and non-negotiable controls.
- Ask AI for several alternatives rather than one answer.
- Require assumptions and expected trade-offs.
- Validate the generated BPMN and DMN.
- Replay historical cases or simulate the alternatives.
- Review changes with process and control owners.
- Deploy the selected design in shadow or limited-volume mode.
- Promote or roll back using observed outcomes.
The immediate value is not autonomous optimisation. It is faster creation of reviewable, testable alternatives.
The Market Signal
Enterprise automation has concentrated on agents that work inside processes.
Camunda’s experiment exposes the next layer: agents that work on the process.
They inspect the current model, interpret business targets, detect conflicting constraints, restructure dependencies and return executable artifacts.
The evidence remains preliminary. Human review and real operational measurement are indispensable.
But the direction is consequential.
Process modelling is beginning to merge with AI-assisted software engineering. BPMN and DMN provide the structured artifact. Business KPIs provide the objective. Simulation and production telemetry provide the feedback.
The process architect does not disappear. The role moves upward—from manually arranging every gateway to defining objectives, protecting constraints, comparing alternatives and deciding what evidence is sufficient for deployment.
AI agents first entered the workflow as workers.
They are now approaching the architect’s desk.