Agentic Business Process Management

• Agentic Business Process Management (APM) is a paradigm that uses autonomous agents with perception, reasoning, and memory to dynamically orchestrate business processes.
• It models business processes through formal definitions of goals, objects, and agents, employing split and merge-goal dynamics for flexible workflow execution.
• APM enables rapid reconfiguration and resilience in volatile environments while presenting challenges in governance, safety, and human oversight.

Agentic Business Process Management (APM) is a paradigm for the design, execution, and continuous optimization of business processes in which autonomous agents—capable of perception, reasoning, memory, and action—interact to achieve organizational goals. Unlike traditional automation-centric BPM, which hardcodes control flow as sequences of tasks, APM orchestrates modular, goal-oriented agents whose workflows emerge dynamically through interactions governed by goals, business objects, and adaptive agent coordination (AzariJafari et al., 29 Jul 2025).

1. Motivations and Paradigm Shift

Traditional BPM approaches, particularly those using explicit control flow models (e.g., BPMN), are effective in stable environments but exhibit brittleness under dynamic conditions, such as market volatility, frequent product launches, regulatory changes, or unanticipated exceptions. Process modifications often require manual redesigns and redeployment, incurring latency and maintenance costs.

APM shifts from a procedural, design-driven paradigm to a declarative, data-driven, and autonomy-centric approach. It exploits agentic AI: systems of autonomous, process-aware agents with embedded language understanding, planning, reasoning, and (optionally) learning capabilities, enabling real-time adaptation and context awareness. Instead of specifying how each task unfolds, APM defines business goals, the objects those goals manipulate, and the agents responsible for achieving them. The overall workflow self-organizes via agent-object-goal dependencies, supporting flexible, maintainable, and resilient automation (AzariJafari et al., 29 Jul 2025, Dumas et al., 25 Jan 2026, Calvanese et al., 19 Mar 2026).

2. Formal Modeling of APM Components

Goals, Objects, and Agents

• Goals ($G$): The set $G = \{g_1, ..., g_n\}$ represents business goals. Each $g \in G$ is a tuple $g = (\text{gID}, O_g, A_g)$, with $\text{gID}$ a unique identifier, $O_g \subseteq O$ the relevant business objects, and $A_g \subseteq A$ the agents activated by $O_g$.
• Objects ($O$): $O = \{o_1, ..., o_m\}$, the set of business-relevant entities (documents, messages, data records) that define inputs/outputs between goals and agents.
• Agents ($A$): $A = \{a_1, ..., a_k\}$, each $a$ defined as $(\text{aID}, C_a, OT_a, OR_a, OF_a, g_a)$, where:
  • $\text{aID}$: unique agent identifier
  • $C_a \subseteq$ {Create, Read, Update, Delete, Archive} (CRUDA+Archive) capabilities
  • $OT_a \subseteq O$: trigger objects
  • $OR_a \subseteq O$: resource objects used in execution
  • $OF_a \subseteq O$: output objects
  • $g_a \in G$: assigned goal

An agent $a$ functionally determines the pair $$(\text{gID}_a, g_a): \text{aID} \mapsto (\text{gID}_a, g_a)$$, and its object scope is $O_a = OT_a \cup OR_a \cup OF_a$ (AzariJafari et al., 29 Jul 2025).

Split and Merge-Goals

If $|A_g| > 1$, $g$ is a split-goal (AND, OR, XOR). When multiple agents' outputs are required to fulfill $g$, it is a merge-goal:

$$O_g = \bigcup_{a \in \text{IncomingAgents}(g)} OF_a$$

This formalism enables dynamic agent collaboration and enables goals whose satisfaction may require parallelism, alternatives, or joint effort.

Precedence and Emergent Workflow

A precedence relation $pre(g_x, g_y)$ is induced when an agent in $A_{g_x}$ outputs an object that serves as a trigger for $A_{g_y}$. The resulting process is a partially ordered set of goals—workflows emerge via object and agent dependencies, circumventing rigid edge encoding and supporting dynamic adaptation (AzariJafari et al., 29 Jul 2025).

Agent-Based Process Definition

An Agent-Based Process (ABP) is defined as:

$ABP = (OS, OE, OR, G, C, A)$

with $OS$ the set of starting objects, $OE$ end objects, $OR$ resource objects, $G$ all goals, $C$ the set of all required capabilities, and $A$ the set of all agents.

3. Architectural Patterns and Execution Semantics

A canonical APM architecture comprises the following layers:

• Natural Language/Domain Interface: Allows stakeholders to express business goals and object schemas in business language or domain-specific terms.
• Agent Registry: Repository of agent definitions, each with associated capabilities, triggers, and goals.
• Object Store & Event Bus: Central store for all business objects; each update triggers event broadcasts to relevant agents.
• Orchestration Kernel: Responds to new or updated objects by activating agents according to split/merge semantics and tracking dependencies.
• Agent Internals: Each agent can incorporate reasoning modules, memory, generative models (LLMs), and reinforcement-learning or decision policies.

Process execution proceeds as agents are awakened by the availability of their triggers, operate on resource objects, execute CRUDA capabilities (possibly invoking LLMs or APIs), and emit results to the object store, which in turn may activate further agents (AzariJafari et al., 29 Jul 2025).

Pseudocode (as per (AzariJafari et al., 29 Jul 2025)):

for each new object o⁺ in EventBus: for each a ∈ A with o⁺ ∈ OT_a: spawn AgentThread(a) # respecting split semantics AgentThread(a): load OR_a from ObjectStore execute capabilities C_a produce OF_a write OF_a into ObjectStore & emit events

There is no central scheduler; the orchestration kernel and object-store dynamics determine flow, with agents coordinating as needed (e.g., in AND/OR splits or merges).

4. Process Development Lifecycle

Agentic process management follows a structured development methodology:

1. Goal Elicitation and Decomposition: Stakeholders define high-level goals $G$; decomposition yields sub-goals to requisite granularity.
2. Object Analysis: For each goal, determine all associated objects ($O_g$), classify them as start, intermediate, resource, or end.
3. Agent Definition: Assign agents to each goal, define their capabilities and triggers, and, if necessary, specify collaboration semantics for split/merge-goals.
4. Validation: Build the precedence relation via object-trigger matching, check for acyclicity, ensure no unreachable objects.
5. Deployment and Execution: Agents await trigger objects; the orchestration kernel coordinates agent activation and synchronization.
6. Dynamic Reconfiguration: Changing goals/objects or regulatory requirements are localized by updating only affected agents or objects; unaffected branches of the process remain operational.

Benefits include modularity, rapid reconfiguration, and robustness to changing requirements (AzariJafari et al., 29 Jul 2025).

5. Illustrative Example: Pizza Delivery

A representative example involves five goals and five agents:

Agent	Capabilities	OT (Trigger)	OF (Output)	Associated Goal
CheckOrder (a₁)	Read, Update	order	checkedOrder	AcquireOrder (g₁)
InformingCustomer (a₂)	Create	checkedOrder/KO	customerNotice	CustomerAlerted (g₂)
InformingKitchen (a₃)	Create	checkedOrder/OK	pizzaSchedule	KitchenAlerted (g₃)
CookPizza (a₄)	Update, Archive	pizzaSchedule	pizzaDone	CookedPizza (g₄)
Delivering (a₅)	Read, Create	pizzaDone	fulfilledOrder	PizzaDelivered (g₅)

The induced precedence: $g_1 \rightarrow g_2$ or $g_3$ (XOR-split), $g_3 \rightarrow g_4$, and $g_4 \rightarrow g_5$. This illustrates a context-sensitive, modular agentic process. No explicit merge-goals are required in this example, though the formalism admits them for more complex collaborations (AzariJafari et al., 29 Jul 2025).

6. Strengths, Limitations, and Future Research Directions

Strengths

• Modularity and Adaptability: Processes are organized around reusable agents and goals rather than rigid tasks; new capabilities or regulatory requirements can be localized and incorporated with minimal disruption.
• Goal-Centric and Declarative: Focus on business outcomes rather than pre-specified sequences enhances contextual adaptability.
• Dynamic Collaboration: Split and merge semantics encode forms of parallelism, alternatives, and coordination among agents.

Challenges and Open Issues

• Safety and Accountability: Auditing distributed autonomous agents, ensuring data protection, and preventing errors or unintended side effects are nontrivial.
• Human-in-the-Loop and Trust: Determining appropriate levels and mechanisms for human oversight and ensuring agent explainability are open problems.
• Governance and Regulation: Standards for defining agent capabilities, allowed actions, and cross-domain interactions are required for scalable adoption.

Future Work

• Enhanced Internal Planning: Incorporation of richer planning and resource-scheduling modules into agents.
• Cyclic and Transactional Processes: Extending the model to accommodate controlled cycles and long-running business transactions.
• Quantitative Performance Models: SLA-aware agent selection and integration of cost/benefit/latency metrics into orchestration.
• Formal Verification: Guarantee of deadlock freedom and correctness under AND/OR split and merge scenarios, particularly in safety-critical applications.

While implementation details such as orchestration strategies for LLM-based agents or runtime monitoring are still underdeveloped, the formal architecture and lifecycle provide actionable foundations for transitioning from task-based to agentic, goal-driven business process automation (AzariJafari et al., 29 Jul 2025).