BLOG
Model to Execution: Why the Old Phased Model Suddenly Works Again
September 30 | Sharam Dadashnia
Business Concept. IT Concept. Implementation.
Three terms that many still recognise from their training, studies, or first major implementation projects. And three terms that were long considered a symbol of IT that moved too slowly.
Much of the criticism was justified. Thick documents piled up between the business unit and the development team. By the time the IT concept was finalised, the business had long since moved on. Implementation began with a model that was already incomplete by the time of the first release. Later, no one knew anymore whether the BPMN diagram, the wiki, or the running code actually described the process.
The problem, however, was not the separation of business logic and technology.
The problem was that the middle ground remained on paper.
With agent-based processes, this intermediate level takes on a new role. It doesn’t just describe what a process is supposed to do. It defines which steps run deterministically, which tasks an AI agent handles, which systems it is allowed to access, when a human makes a decision, and how a process remains controllable over the course of weeks.
This transforms an IT concept back into what it should have been: an executable link between business requirements and operations.
Why the phase model has fallen into disrepute
The classic model promised a clear division of labour:
- The business department describes the goal, workflow, and rules.
- IT translates this into a technical specification.
- Development and operations implement the specification and keep the system running.
In practice, the connection usually broke down at the second stage.
The business department worked with process diagrams, tables, and free-form text. Development wrote code, database scripts, and interface logic. Between these two worlds lay handoffs, clarifications, version conflicts, and often multiple tools. After the first process change, there wasn’t enough time to update all the documents.
This led to a familiar pattern: The business concept was understandable but not executable. The code was executable but virtually unreadable to business departments. And the IT concept lay somewhere in between, usually as a document with an outdated revision status.
Agile development has solved part of this problem. Teams deliver in smaller increments, coordinate more frequently, and test earlier. What it doesn’t automatically solve is the lasting connection between business process logic, integrations, authorisations, agents, and operations.
This connection is becoming more important again. After all, an AI agent can be built quickly. A productive business process involving AI agents is something else entirely.
The IT concept has more substance today than it did three years ago
A technical process concept used to describe primarily data models, interfaces, user interfaces, rules, and error handling. These topics remain. But for Agentic Process Orchestration, additional questions arise.
A modern concept must, at a minimum, answer the following:
- Which steps are strictly regulated?
For example, a required-field check, an approval threshold, or an escalation after five business days.
- Which steps require context and judgment?
Such as reviewing a complaint, classifying a technical inquiry, or verifying whether a document appears to be complete.
- Which agent is responsible for which task?
An agent responsible for document analysis has a different mandate, different data, and different permissions than an agent who prepares customer communications.
- What data is the agent allowed to see?
Not every process step requires access to all customer data, contracts, or internal knowledge sources.
- Which systems are involved?
These include ERP, CRM, document management, line-of-business applications, APIs, and event sources.
- Where should a human make a decision?
Especially for legally relevant, financial, or technically contentious decisions, a review point must be part of the workflow—with a designated role, deadline, and escalation process.
- What is logged?
A subsequent audit trail must be able to show which process went through which step and when, what data was used, and who granted approval.
This is not an add-on for AI projects. It is the technical description of the process itself.
A process model can remain the guiding structure here. At Scheer PAS, the process logic is modeled using BPMN, connected to applications and data sources via integration logic, and executed by the process engine. Agents are embedded within this workflow rather than running as isolated automations alongside it.
The standard approach: Describing requirements in natural language
Getting started today can be much more straightforward than in the past.
A business unit doesn’t have to start with a 60-page requirements specification. It can simply describe what should happen:
When a customer inquiry is received via email, the attachments and email content should be checked. Missing technical details must be identified. Complete inquiries are forwarded to production planning. If information is incomplete, the sales department should receive a draft response for approval. After three business days without a response, the process is escalated.
Even this short text already contains a great deal of process logic:
- an event that triggers the process
- documents and email content as inputs
- a completeness check
- a decision with two possible paths
- various responsibilities
- a human approval step
- a deadline
- an escalation
Language models can help generate an initial draft based on such a description: process steps, open questions, possible data objects, or a proposal for a BPMN model. The benefit does not lie in the fact that the AI “knows” the process. Rather, it forces requirements into a verifiable form early on.
However, the first draft is never a green light for implementation.
It is the beginning of the business dialogue: What exactly does “complete” mean? Which details are required? Can an agent assess technical relevance, or can it only identify missing information? Is it allowed to send a follow-up query, or only to create a draft? Which cases go directly to a human?
This clarification was also necessary in the past. It just often took place too late…after the business department and IT had already settled on different interpretations.
A BPMN model is not merely a screenshot for a language model
Here lies an important difference between a serious implementation and a nice demo.
Uploading a BPMN diagram as an image in a chat and asking whether the process can be improved can be useful for a workshop. For productive processes, it is not enough. An image carries no robust technical semantics: no version, no binding data structures, no permissions, no linked interfaces, and no runtime status.
The bidirectional mapping between the model and the implementation is crucial. This means:
- The business process model describes steps, decisions, roles, and events.
- The technical layer links these elements to APIs, data objects, user interfaces, business rules, and agents.
- Changes to the model are not only documented but can also be specifically implemented in the execution.
- Insights from ongoing operations are fed back into the modeling process.
An example: In the quotation process, an agent is added that evaluates technical attachments. In the model, it is not just an anonymous box labeled “AI.” It has a clear place in the workflow.
It is defined:
- when it is called
- what inputs it receives
- what structured result it must return
- which data sources are permitted
- what happens in case of uncertainty
- whether it may only generate a recommendation or is allowed to trigger an action
- and which subsequent process is initiated
This makes the agent’s logic part of the process system. It can be tested, monitored, versioned, and verified in the context of the entire process.
Current approaches to agent-based process execution follow the same line of thinking: a predefined workflow specifies the structure and control points, while agents handle the variable or unstructured tasks. The “Plan-then-Execute” pattern, for example, separates planning and execution to make behavior more controllable and verifiable. SAP describes this pattern for responsible agent-based AI. Research on agentic business process management also focuses on the combination of process rules, agents, and context-dependent execution. One example is the approach with separate roles for process frameworks and operational processing in a scientific study on LLM agents in business processes.
Agents do not emerge separately from the process model
In many companies, agent development begins differently: A team identifies an interesting task, connects a model with a few tools, and demonstrates its value. This can be a sensible starting point.
Problems arise when this prototype subsequently becomes “unnoticed” part of a critical end-to-end process.
In such cases, the very information that a process model makes visible is usually missing:
- In which step is the agent operating?
- What happens if its call fails?
- What data is allowed to leave the process?
- Who can override its result?
- What happens if the process waits three weeks for a customer response?
- How is the agent replaced if the model, prompt, or data source is changed?
- Which process version was in effect when the agent was preparing a decision?
Agents should therefore be derived from the process model, not built around it.
A well-modeled process makes it clear where an agent actually adds value. Not every step needs one. A credit limit, an approval threshold, or an escalation after a deadline has passed are best implemented as fixed rules. They are predictable, testable, and cost-effective.
The agent belongs where language, documents, context, or domain-specific classification are required:
Process situation | Appropriate tool |
Invoice total exceeds a defined amount | Rule or decision table |
Recognise and categorise unstructured inquiries | AI agent |
Identify missing information from emails and attachments | AI agent with structured output |
Send a reminder for customer approval after ten days | Process rule and timer |
Confirm a discount decision | Human decision within the process |
Transfer quote data to ERP and CRM | Integration and process logic |
Evaluate and justify technical exceptions | AI agent, with “human-in-the-loop” if there is a risk |
This division is not a compromise between the old and new worlds. It is the foundation for a process that remains manageable in operation.
The way back: What operations reveal through the process model
Model to Execution does not end with deployment.
When a process is running, it generates information that would never appear in a document: Where do tasks become delayed? Which exception occurs most frequently? Which agent consistently produces unreliable results? At which interface do errors occur? How many processing steps actually require human intervention?
The process engine does not simply track the status of a single agent call. It tracks the state of the entire process, even if there are five weeks between two steps.
Let’s take the quote request as an example again. After three months, it may become apparent that the document agent reliably detects missing technical details. Nevertheless, nearly one in four requests remains pending for too long because the internal feasibility check has no defined deadline. So the bottleneck isn’t the document analysis. It’s an unclear handoff between sales and production planning.
This insight leads us back to the process model. The solution could be a deadline, a clearly designated person in charge, an escalation process, or a different distribution of work. Perhaps no additional agent is even needed.
This is the crucial point: process intelligence doesn’t arise from the number of models used. It arises from the connection between the model, execution, and observable operation.
The phase model was never the problem
The business concept, IT concept, and implementation work again when they are not viewed as three separate documents.
The business concept describes the business purpose and the rules. The technical level translates this purpose into an executable process: with integrations, data, roles, agents, checkpoints, and evidence. The implementation brings it into operation. And the operation feeds insights back to the model and the business unit.
In this way, a model becomes not just a diagram for the project archive, but a foundation for execution, control, and change.
This is precisely what “Model to Execution” is all about: the path from the business intent to the running process remains connected. Agents accelerate parts of this path. The Process Engine holds it all together.
