Rethinking Business Processes for the Age of AI

April 13, 2026 Holt Hackney Applications & Technology, Artificial Intelligence, Digital Transformation, Elevating Architecture, From the Editor, Software, Strategy & Planning, Uncategorized 0

By Vasily Yamaletdinov, Enterprise Architect, Raiffeisen Bank

Over recent decades, the concept of a “business process” has been the cornerstone of any organization’s operating model, defining an ordered sequence of interconnected actions aimed at achieving a specific business goal and creating value for stakeholders (both external and internal). The need to model business processes as objects of business architecture was driven by a pragmatic goal: to guarantee a repeatable result within an acceptable timeframe and of required quality, while expending minimal resources.

It is no secret that in the current paradigm, business processes are primarily oriented toward regulating human interactions, where people may use automation tools to enhance the efficiency of their tasks. The most popular notation for modeling such processes today is BPMN 2.0.

However, with the emergence of agentic AI, the picture changes significantly, requiring a rethinking of the very essence of the concept of a “business process”—from a static, predefined set of steps to a dynamic, adaptive, and intelligent AI-first system. This, in turn, necessitates the search for new approaches to modeling the architecture of such AI-native business processes.

Let us explore what new requirements arise for process modeling in the era of AI, what the limitations of classical approaches are, and what more suitable methods can be proposed.

New Requirements for Process Modeling

Classical process modeling notations are well-suited for regulated processes with a predefined scenario: approving a request, processing an order, issuing an invoice, or routing documents.
However, modern AI-native processes are often structured differently:

  • Not all steps are known in advance.
  • The route depends on context.
  • Alternative strategies are possible.
  • Decisions are made based on incomplete data.
  • AI agents participate in the process, capable of dynamically planning actions.

Consequently, modeling AI-native business processes, where AI is not merely an auxiliary tool but a key executor and orchestrator, requires a paradigm shift. Classical requirements for process management (strictness, repeatability, determinism) give way to flexibility, autonomy, and context management.

Here are the key requirements for modeling such processes:

  1. A key feature of an AI-native process is that it is partially non-deterministic, unlike fully deterministic processes with a clear sequential chain of steps. Therefore, the business process model must allow describing both well-algorithmizable sections and those operations that can be entirely entrusted to an AI agent. For the agent to work effectively, it must be provided with a clear Goal, Context, and Guardrails.
  2. A well-known problem of generative AI is the risk of errors in actions and hallucinations. Therefore, the AI process model must provide for handling such situations without complex exception-handling branches.
  3. The notation must allow switching error handling and critical decision-making to a human (Human-in-the-loop) if the AI’s confidence falls below a specified threshold.
  4. As noted, an AI-native process is an adaptive system, meaning its execution route should be determined dynamically based on context rather than rigid business rules.
  5. The model must support working with uncertainty—alternating between reasoning and actions, implementing the so-called ReAct cycle: “Reason → Act → Observation”.
  6. The model must allow recording not only the actions themselves but also the agent’s “thoughts” (why it chose a specific tool or path). This is critical for auditing.

Thus, an AI-native process model should resemble not a “rigid conveyor belt” (where a part moves from station to station) but rather a “game board with rules”. You define the game’s objective (Goal), provide players with inventory (Tools), outline the field boundaries (Guardrails), and appoint a referee (Human-in-the-loop), leaving the gameplay itself to the intelligence of the agents.

Limitations of Classical BPMN

Process architecture based on the BPMN notation has faithfully served business for over two decades. However, with the development of AI technologies, this notation increasingly fails to meet the requirements for modeling AI-native business processes:

  1. Classical BPMN is always a strict sequence of actions predefined by an algorithm, performed by specific roles using IT systems, allowing no deviations. One could say BPMN forces AI to “stay on the rails,” effectively discrediting the entire potential of LLMs.
  2. Lack of Goals.The BPMN model does not assume the description of goals, context, or constraints for business operations (steps), which hinders the application of AI agents.
  3. Poor handling of Exceptions.If an AI agent produces invalid JSON, hallucinates, or an API call fails at some step, the process breaks. To avoid this, analysts are forced to draw cumbersome “spaghetti diagrams” with hundreds of exception-handling branches.
  4. Orientation toward Rigid Rules.The entire process route is calculated in advance via gateways based on rigid business rules, not context.
  5. Intolerance of Uncertainty.BPMN is not designed to work with uncertainty; in particular, it does not support architectures similar to ReAct.
  6. Complexity of Human-in-the-loop.While classical BPMN can describe human participation, AI-native processes require more nuanced modes: human confirmation of a decision, human intervention only when AI confidence is low, etc.

AI-Native Architecture with GO-BPMN

Fortunately, there are approaches that satisfy most, if not all, requirements for modeling agentic business processes. One of the most developed among them today is Goal-Oriented BPMN (GO-BPMN).

GO-BPMN is a notation (and an execution language in the Whitestein LSPS platform) that combines classical BPMN with a goal-oriented approach to describing business processes.

In GO-BPMN, a process is not a single rigid scheme from start to finish. It consists of a graph (tree) of Goals to be achieved and Plans—small fragments of classical BPMN that describe how exactly a goal can be achieved.

The GO-BPMN notation is excellent primarily because it allows for an easy implementation of a hybrid approach, where both deterministic business operations (in the form of BPMN) and non-deterministic ones (implemented using AI) can coexist within a single business process. This is achieved by allowing plans to be executed by AI agents as well.

Let us examine the operation of GO-BPMN using the example of the “Loan Application Processing” business process. This process works with the business object Loan Application, which has attributes such as Amount, Status, and Client Data.

pic01

How it works dynamically:

  1. A new loan application for 500,000 USD is received from a client.
  2. The system (which could be an AI orchestrator agent) sees the Main Goalthat the process must achieve. To fulfill it, it activates Subgoal 1.
  3. For Subgoal 1, the system checks conditions and launches Plan A(auto-scoring), which is executed by the AI agent “Underwriter.” The agent receives Subgoal 1 and context as input: a description of how to access the Credit Bureau API and the scoring calculation methodology.
  4. Failure Scenario:The external API hangs, and Plan A fails to execute. In standard BPMN, the process would crash or follow a complex error-handling branch. In GO-BPMN, the system sees that Subgoal 1 remains unachieved and automatically launches an alternative Plan B (assigning the task to a human).
  5. When a human enters the scoring value (e.g., 80), the system understands that Subgoal 1is achieved.
  6. Next, Subgoal 2is activated (since the score > 70), which in turn is decomposed into two subgoals: Subgoal 2.1 and Subgoal 2.2.
  7. For Subgoal 2.1, Plan Cis launched, assigned to the “E-Signature Manager” AI agent. The agreement is formed and electronically signed, resulting in the activation of Subgoal 2.2.
  8. To execute Subgoal 2.2, one of three plans is selected and executed depending on the client’s context—specifically, the presence of a current account or a debit card.
  9. All subgoals, and consequently the Main Goal, are achieved; the process is complete.

The following key advantages of GO-BPMN for modeling the architecture of AI-native business processes can be identified:

  1. Result Orientation.GO-BPMN explicitly states “WHAT” needs to be achieved as a result of the process (e.g., Goal: Application Processes). For an AI agent, formulating a goal is essentially a ready-made system prompt. The agent decides which tools to use to achieve this goal, making the process truly autonomous.
  2. Handling Uncertainty.If AI fails to execute one Plan (e.g., cannot parse a document or call an API), the goal remains unachieved. The engine automatically launches an alternative Plan (Fallback)—for example, using a different LLM, trying a different prompt, or simply switching the task to a human (Human-in-the-loop)—without breaking the entire process.
  3. Dynamic Path Selection.A Plan is chosen at the “last minute” based on the current context. You describe high-level rules and goals, while a set of small BPMN diagrams and AI agents assembles into a unified process dynamically, “on the fly,” adapting to conditions and errors. An AI agent can assess the situation (e.g., “the client is irritated”) and choose a completely non-standard plan to achieve the goal “Retain the Client” (e.g., offer a discount), which would not have been activated in a standard deterministic process.
  4. Compatibility with ReAct Architecture.The structure “Goal → Condition Evaluation → Plan Selection” in GO-BPMN fully mirrors the ReAct cycle used by AI agents (LangChain, CrewAI). The agent receives a goal, analyzes available plans (including associated tools), performs an action, and checks whether the goal completion condition is met (Observation).
  5. Loose Coupling.Business operations (plans) within a process are completely independent of each other; control transfer between them occurs solely based on context (i.e. data-driven). This allows adding new business operations to the process literally “on the fly” without breaking the logic of the entire process.
  6. Separation of Goals and Implementation.The key structure in GO-BPMN is the tree of goals and the plans implementing them—a kind of business process framework well-perceived and understood by business leaders and product owners. In this case, business stakeholders operate at the level of setting goals and strategies for achieving them. Meanwhile, details of plan implementation can be discussed separately at the level of business analysts and AI engineers.

Conclusion

So, we have seen that GO-BPMN is much better suited than classical BPMN for modeling the architecture of AI-native business processes.

However, this does not mean that classical BPMN is hopelessly outdated and no longer applicable. BPMN is still preferable where we need:

  • strict standardization.
  • compatibility with existing BPMS platforms.
  • regulated and auditable processes.
  • detailed modeling of deterministic workflows.

The main advantage of GO-BPMN for AI-native business processes is that it better describes not just the execution route, but also intent, adaptation, autonomy, and the achievement of results under uncertainty. That is why, in practice, it is more often seen not as a complete replacement for BPMN, but as a more effective approach for adaptive, intelligent, and goal-oriented process modeling.