Agentic Business Process Management: A Research Manifesto

TL;DR

This is a manifesto, not a method paper — it’s the BPM (Business Process Management) research community’s formal response to the LLM-agent wave, written the same way the field once wrote the influential 2012 Process Mining Manifesto. The core move: flip the unit of analysis from tasks (what BPMN diagrams draw) to agents (human, software, or AI) as the primary functional entities that carry out a business process. An agent only counts as part of an “Agentic BPM” (APM) system if it has some degree of process awareness — a “frame” that constrains its otherwise-free autonomy so its actions stay aligned with organizational goals. The paper names four capabilities every such agent needs — framing, explainability, conversational actionability, self-modification — argues for that specific order (framing first, self-modification last), and then spends most of its length on a structured list of 18 open research questions the authors think the field must answer before this is real. There’s no algorithm, no benchmark, no code — it’s the output of a Dagstuhl seminar of ~18 academics and industry researchers (IBM, SAP, Meta) turning whiteboard consensus into a shared vocabulary and a research agenda.

Problem & Motivation

Two worlds currently don’t talk to each other, and the gap is where the risk lives.

World 1: agentic AI. Organizations are wiring LLM-based agents into their operations — an agent that browses, negotiates, files paperwork, talks to other agents. These agents are increasingly “autonomous”: they perceive, reason, and act toward a goal rather than just answering one prompt. But autonomy without guardrails is exactly the failure mode everyone building agentic systems already knows about: an agent can violate a compliance rule, blow past a spending limit, or produce behavior nobody can audit after the fact, and because it’s LLM-driven, it’s hard to test or debug in the traditional sense.

World 2: BPM. The BPM field has forty years of practice managing “sets of activities that jointly accomplish a business goal” — process models, compliance rules, KPIs, governance. BPM and multi-agent systems (MAS) research have actually cross-pollinated since the 1990s, but almost entirely in one direction: agents were treated as resources you assign to execute a task in someone else’s process, not as first-class actors with their own goals and reasoning.

Neither world, on its own, gives you what you need. Agent-governance research (normative multi-agent systems, LLM-provider “safety” guidance) tells you how to constrain an agent in the abstract, but doesn’t connect that to how organizations actually structure work. BPM tells you how to structure work, but has no native concept of an autonomous decision-maker inside that structure. The paper’s motivating example makes this concrete: a procurement process with a buyer agent and several supplier agents (some human, some AI). Each needs to pursue its own local goals (a supplier might be geographically restricted; a buyer might have a budget ceiling) while staying coordinated toward the shared outcome — a signed, compliant contract. Today, nobody has a clean answer for what governs that.

What’s New (Core Contribution)

This is a position paper, so the novelty is conceptual scaffolding, not an algorithm. Four things it actually contributes:

• Agentic systems become agent-centric, not agent-augmented. Before: prior “AI-augmented BPM” work (the same authors’ own 2023 manifesto, [23]) treats AI as a capability layered onto an otherwise task-centric process — the process is still the star, AI just makes parts of it smarter. Now: the agent becomes the primary functional entity. The process exists because agents perceive, reason, and act toward it — not the other way around. This is a genuine reframing, not just new vocabulary, because it changes what you’d even try to model or measure first (agent goals and frames, not task sequences).

• A crisp formal definition of what counts as “agentic” BPM, with a bar to clear. Def. 2.1: an APM system is “a socio-technical system jointly realized by a collection of agents, some of which are at least partially process-aware.” That’s a deliberately low bar (you don’t need every agent to be process-aware) but it does require some concrete framing mechanism to exist — a system of pure autonomous agents with zero process awareness isn’t APM, it’s just an agentic system.

• The normative frame vs. operational frame distinction. Classic process languages (BPMN, DECLARE) specify what to do — the operational frame. The paper introduces the normative frame: deontic rules (obligations, permissions, prohibitions) that constrain how an autonomous agent may choose to act, without dictating the exact steps. If there’s no decision-maker, the two collapse into the same thing (a rule is just an extra condition on the fixed sequence). Once there’s a real decision-maker, they diverge sharply: the operational frame says “do A, then B, then C”; the normative frame says “you may not do X” and leaves the agent free to find its own way to comply. This is the conceptual hinge the entire paper depends on — it’s genuinely useful and not something BPMN or DECLARE give you natively.

• Four ordered capabilities, with an explicit justification for the order. Framing → Explainability → Conversational Actionability → Self-Modification. The authors argue this order is not arbitrary: you frame an agent first (or its autonomy is unconstrained by definition), then you need it to explain itself (a prerequisite to trusting it enough to deploy it), then it needs to act and interact effectively (conversational actionability), and only once all of that is stable do you let it modify itself over time. Each capability comes with its own numbered research-challenge list (18 challenges total across F1–F4, X1–X5, A1–A4, M1–M5, plus 5 cross-cutting challenges C1–C5).

The four capabilities as stacked layers, in the paper's argued build order (drag to orbit). Framing is the base every other capability depends on; self-modification only sits safely on top once the other three are in place.

Be honest about what’s not new: BDI (Belief-Desire-Intention) agents, FIPA agent-communication standards, i*/Tropos goal modeling, DOLCE/GFO ontologies, and deontic logic are all decades-old imports, not invented here. The perceive-reason-act loop is textbook Russell & Norvig. What’s new is the synthesis — stitching these older ideas into one coherent vocabulary aimed squarely at the LLM-agent moment, plus the normative/operational frame split and the structured research agenda.

How It Works (Technically)

There’s no algorithm to trace, but there is a mechanism worth understanding precisely: how “framing” actually constrains an agent, and how the paper’s own conceptual architecture (its Figure 1) hangs together at two levels.

The two-level architecture. The macro level is the APM system itself — the “world” the agents live in. This is where the framing mechanism operates: it imposes process-awareness (agents’ actions are directed at collective goals) and goal-alignment (rules of engagement, hierarchies, role assignment, segregation of duties) on the population of agents. Framing is deliberately left open as an engineering choice — you could implement it via a single orchestrating agent with collective responsibility, via a central orchestration engine, or via a shared memory/blackboard that agents consult and update.

The micro level is a single APM agent, and every such agent has the same three-module shape: perceive (sense the environment, other agents, context) → reason (maintain a mental model — beliefs about the process, and an intentional model — goals, obligations, roles) → act (change the environment, message other agents). The four capabilities all live inside the reasoning module: framing is the internalization of the macro-level frame into the agent’s mental/intentional models; explainability, conversational actionability, and self-modification are additional competencies layered on top of that same reasoning core.

Architecture & data flow

flowchart LR
  subgraph Macro["Macro level — the APM system"]
    FR[Framing mechanism<br/>process-awareness + goal-alignment]
  end
  subgraph Micro["Micro level — one APM agent"]
    P[Perceive] --> R[Reason<br/>mental model + intentional model]
    R --> A[Act]
  end
  FR -->|"constrains knowledge & goals"| R
  A -->|"tool calls: messaging, services,<br/>actuators"| ENV[(Environment:<br/>objects, other agents, AI models)]
  ENV -->|"percepts"| P
  R -.->|"explain / converse / self-modify"| R

A schematic "frame gate": each proposed action is checked against the agent's normative frame (obligation / permission / prohibition, Section 3.1) before it's allowed to reach the environment. Green passes straight through, orange is held until an unmet obligation clears, red is bounced. Illustrative — built from the paper's normative-frame concept, not the paper's own figure.

Trace the supplier-onboarding example end to end. A buyer agent (AI, framed by an RFQ policy: budget ceiling, approved-vendor list) needs to onboard suppliers.

1. Perceive: the buyer agent senses that a new sourcing need exists (a percept from the environment — e.g. an inventory system signal).
2. Reason, under its frame: its intentional model says “goal: award a compliant contract within budget.” Its mental model tracks known suppliers and their status. It decides to send Requests for Quotation (RFQs) — an operational action, well within its frame.
3. Act / interact: it dispatches RFQs to several supplier agents (human and AI).
4. Each supplier agent independently perceives the RFQ, reasons under its own frame (e.g. “I may only quote within my assigned geography” — a normative constraint, not a step in anyone’s flowchart), and acts by returning a quote.
5. The buyer agent reasons again: evaluate quotes against its normative frame (“may not exceed budget,” “must prefer approved vendors”) — this is exactly where operational and normative frames diverge. The operational frame might say “score and rank quotes”; the normative frame is the actual boundary (“you may not award to a non-compliant supplier even if it’s cheapest”).
6. It acts: awards the contract to a compliant supplier.
7. A legal agent, present in the same APM system but not process-aware (Def. 2.1 only requires some agents to be framed), separately performs contract diligence — illustrating that not every actor in the socio-technical system needs a frame for the system as a whole to count as APM.

sequenceDiagram
  participant Buyer as Buyer Agent (frame: budget + approved-vendor list)
  participant SupA as Supplier Agent A (frame: region-limited)
  participant SupB as Supplier Agent B
  participant Legal as Legal Agent (not process-aware)
  Buyer->>SupA: RFQ
  Buyer->>SupB: RFQ
  SupA-->>Buyer: Quote (within own frame)
  SupB-->>Buyer: Quote
  Buyer->>Buyer: Reason: evaluate vs. normative frame (budget, compliance)
  Buyer->>SupA: Award contract
  Buyer->>Legal: Ad hoc diligence request

“Demystifying” the definitions. The paper’s formalism is definitional, not mathematical, but it’s worth translating precisely because the wording is doing real work:

• Def. 2.1 (APM system): “a socio-technical system jointly realized by a collection of agents, some of which are at least partially process-aware.” Operationally: you don’t need to convert every agent in your org to a framed, process-aware entity to have an APM system — you need at least one concrete framing mechanism operating somewhere, applied to at least some agents.
• Def. 2.2 (APM agent): “a primary execution entity… with its autonomy framed to ensure process-aware behavior aimed at achieving process goals.” Operationally: the agent’s own utility function has been reshaped (via the frame) so that pursuing its individual goals is compatible with pursuing the org’s process goals. This is the same idea as reward shaping or constrained RL, applied at the level of “what this agent is even allowed to want.”
• Def. 2.3 (Tool): “a means accessible to an agent that augments its capacity to reason, and to perceive and act upon its environment.” Operationally: this is a broader definition than “function-calling tool” in the agentic-AI sense — it explicitly includes sensors, actuators, and AI models/techniques (simulation, mining) as tools, not just callable APIs.
• Def. 2.4 (Framing): “a primary mechanism for ensuring process-awareness and goal alignment… imposing restrictions on the autonomy of agents through their knowledge and goals.” Operationally: framing doesn’t restrict what actions exist in the world — it restricts what the agent believes it should want and believes it’s allowed to do. That’s why it lives in the reasoning module’s mental/intentional models, not as an external filter bolted onto the action module (though the pseudocode below models it as exactly that kind of gate, because that’s the simplest way to build a toy version).

The algorithm, simplified

The paper gives no executable procedure — its contribution is vocabulary and open questions, not a method. But you can write down the smallest piece of code that operationalizes Section 3.1’s obligation/permission/prohibition framing, because that’s the one mechanism concrete enough to compile into a gate function:

# The paper never gives code — this "frame gate" is what falls out of Def. 2.4
# (Framing) and the normative-vs-operational frame split (Section 3.1).
# A normative frame is a list of deontic rules an agent's proposed action must
# clear before the action module is allowed to touch the environment.

OBLIGATION, PROHIBITION = "obligation", "prohibition"

def frame_gate(proposed_action, mental_model, normative_frame):
    """
    normative_frame: list of (rule_type, condition_fn, action_pattern)
    mental_model: the agent's current beliefs about the process (its "memory")
    Returns (allowed: bool, rationale: str) — rationale doubles as the seed
    of an explanation (Section 3.2: explainability is the very next capability).
    """
    unmet_obligations = [
        rule for rule in normative_frame
        if rule[0] == OBLIGATION and rule[1](mental_model) and rule[2] != proposed_action
    ]
    if unmet_obligations:
        # e.g. "must log the rejection before deleting the record"
        return False, f"blocked: unmet obligation ({unmet_obligations[0][2]})"

    for rule_type, condition, pattern in normative_frame:
        if rule_type == PROHIBITION and condition(mental_model) and pattern == proposed_action:
            return False, f"blocked: prohibited under current frame ({pattern})"

    # framed autonomy = "everything not forbidden, and not blocked by an
    # unmet obligation, is allowed" — no explicit PERMISSION rule has to fire
    return True, "allowed: no unmet obligation, no prohibition matched"


def step(agent, environment, normative_frame):
    percept = environment.sense(agent)
    agent.mental_model.update(percept)                    # Perceive
    proposed = agent.reason(agent.mental_model)             # Reason toward its goal
    allowed, rationale = frame_gate(proposed, agent.mental_model, normative_frame)
    agent.log(proposed, rationale)                          # feeds explainability (3.2)
    if allowed:
        environment.apply(proposed)                          # Act
    else:
        agent.reason_again(rationale)                         # conversational actionability (3.3):
                                                                # renegotiate instead of just failing
    return allowed, rationale

That frame_gate is doing exactly what the manifesto argues framing must do: it doesn’t dictate the action (operational frame), it just narrows the space of legal actions (normative frame) while leaving the agent free to reason its own way to a compliant one.

Built on Prior Work

The manifesto explicitly positions itself in a lineage of BPM manifestos and vision papers, and separately draws on decades of agent theory. Being honest about the delta:

Results & Evidence

There is no empirical evidence in the conventional sense — no benchmark, no implementation, no user study. That’s expected for a manifesto, but it’s worth being precise about what the “evidence” actually is:

• Provenance: the content was generated at Dagstuhl Seminar #25192 (“AUTOBIZ”), where ~18 academics spanning BPM, formal methods, and multi-agent systems, plus industry researchers from IBM Research, SAP, and Meta, gave talks, split into breakout working groups per topic, and reported back to the full group for feedback.
• Refinement path: the seminar’s findings were turned into four separate peer-reviewed short papers at the PMAI (Process Management in the AI Era) workshop at ECAI 2025 [15, 16, 17, 18], and those were further revised based on workshop-participant feedback before being consolidated into this manifesto.
• What this establishes: a documented, multi-step consensus process across two research communities (BPM and MAS/AI) plus industry practitioners agrees that (a) the problem — governing autonomous agents in business processes — is real and under-addressed, and (b) this specific vocabulary (framing, explainability, conversational actionability, self-modification) is a reasonable starting decomposition, and (c) 18 specific open questions are worth funding research against.
• What this does NOT establish: whether this is the right decomposition (a different Dagstuhl group might have cut it differently), whether normative frames as described are actually elicitable and machine-checkable at real-world scale, whether any of the four capabilities can be built with current LLM technology at acceptable cost/reliability, or how practitioners without a BPM-research background would actually use these definitions day to day (the paper itself flags this as an open problem — F1).

How You’d Use It

This isn’t a system to implement — it’s a vocabulary and diagnostic checklist for auditing any agentic setup you’re about to ship or already run.

• Harness audit before you scale an agent. Before you hand a real workflow to an autonomous agent — a support agent that issues refunds, a procurement agent that requisitions vendors — run it through the four capabilities as a gap check: Does anything frame this agent beyond the system prompt? Can it explain a decision after the fact? Can you actually intervene mid-run and have that redirect its behavior? Is there a path for promoting a one-off fix into a permanent policy? Most current agent deployments fail at least two of these — that’s your punch list before you widen the blast radius.
• A governance layer in your own harness. Section 4’s cross-cutting challenges (especially C2 security/prompt-injection and C4 liability/accountability) map onto a concrete addition to your agent runtime: a governance module that answers “who’s accountable when this agent’s self-modification drifts from its original design” before it becomes an incident.
• Shared vocabulary across your team. If you work with anyone from a BPM or enterprise-process background, “framing,” “process awareness,” and “normative vs. operational constraints” communicate more precisely than generic “AI safety” language, and it’s citable, peer-reviewed terminology instead of ad hoc jargon.
• What it does not give you: a spec to build against. There’s no reference architecture, no protocol, no schema for a “frame.” If you want an actual APM system, you’re the one who has to invent the concrete framing mechanism — the paper explicitly leaves that “an engineering choice” (§2.2.1).

Build Your Own (Minimal Recipe)

Since the paper deliberately doesn’t specify a concrete framing mechanism, “building your own” means building the smallest concrete instantiation of the vocabulary — a governance layer you could wrap around an existing multi-agent system (LangGraph, CrewAI, your own MAS).

Components, in build order:

1. Frame registry. A small YAML/JSON file per agent role: obligations, permissions, prohibitions, each as a condition + action pattern. This is the normative frame from Section 3.1, made concrete.
2. The frame gate. The frame_gate function above, wired in front of every tool call / action your agent framework executes. This is the minimum viable “framing” capability (Section 3.1 / F3: operationalizing frames on real symbolic data).
3. Decision + rationale logging. Every gate decision (allowed or blocked) gets logged with the rule that fired. This is the cheapest possible version of explainability (Section 3.2) — not causal-graph-quality, but a real audit trail.
4. A conversational interface exposing the four functionalities from Section 3.3: Query (what’s the state of process instance X?), Recommend (what should happen next?), Create (draft a frame or process spec from a description), Execute (trigger an action). Even a thin CLI or Slack bot over your agent state satisfies “conversational actionability” at a basic level.
5. An adaptation log, separate from an evolution log. Record every instance-level deviation (adaptation) separately from any change to the frame registry itself (evolution). This is the cheapest way to honor Section 3.4’s adaptation/evolution distinction and sets you up to actually test the paper’s claim that repeated adaptations should eventually get “promoted” into the frame.

The 1–2 genuinely hard parts:

• Eliciting a machine-checkable frame from a natural-language policy (F2). Turning “always get manager approval for refunds over $500” into a (condition_fn, action_pattern) your gate can evaluate is not a parsing problem — it’s the same hard problem as turning legal/compliance text into enforceable code, and LLM-assisted frame generation is exactly the kind of thing the paper flags as unproven (F2).
• Explaining across agents, not just one model’s output (X2). Off-the-shelf XAI techniques explain a single model’s prediction. Explaining why the buyer agent awarded the contract to supplier B requires reconstructing a causal trace across multiple agents’ actions and frame decisions — the paper is explicit that existing XAI tooling doesn’t cover this (X2, X5).

Reach for: LangGraph or a similar orchestration graph for the perceive-reason-act loop; a small rules engine (even a Python function list, or OPA/Rego if you want something more serious) for the frame gate; structured logging (OpenTelemetry spans per agent action) for the audit trail — that’s most of the machinery.

How to Improve It

The paper is explicitly a call to action, so “improving it” means picking one of its 18 open questions and actually testing something. Five concrete, scoped ideas:

1. Prototype and stress-test a minimal frame language. Extend DECLARE (a declarative process constraint language already used in BPM) with deontic operators (obligation/permission/prohibition) and see whether an LLM agent, given that frame as context, reliably stays inside it across a few hundred trials. This directly answers F2/F3 with data instead of argument.
2. Borrow static consistency checking from adjacent formalisms. A companion agentic-BPM paper (goal/object/agent formalisms) shows you can statically detect “dead” agents and unreachable goals from a process spec. Do the analogous check for frames: can you detect an unsatisfiable frame (an obligation and a prohibition that can never both be cleared) before deployment, rather than discovering it at runtime?
3. Build the first APM benchmark, designed against contamination (C3). The paper explicitly flags that any benchmark built from public data risks LLM training contamination. Design a small multi-agent process task (e.g., a synthetic procurement scenario) with programmatically generated instances, scored on frame compliance, explanation quality, and safe self-modification — regenerable per run so it can’t be memorized.
4. Test “learning to defer” as the actual escalation mechanism (M1). The paper name-drops the ML literature on prediction with a reject option as a candidate solution for “when should the agent hand control back to a human.” Actually wire a confidence threshold into the buyer-agent example above and measure how often it correctly escalates vs. over-escalates.
5. Measure whether the adaptation→evolution feedback loop actually reduces adaptation frequency. Section 3.4 predicts that as effective ad hoc adaptations get “promoted” into the frame, the rate of needed adaptations should fall over time. That’s a falsifiable, measurable claim — instrument the adaptation log from the recipe above and check it against real usage.

Glossary

• APM (Agentic Business Process Management) — this paper’s proposed extension of BPM where autonomous agents, not tasks, are the primary functional entities executing a process.
• Agentic system — a collection of one or more goal-driven agents that sense, reason, and act to deliver software functionality; broader than APM (an agentic system doesn’t need any process awareness).
• Process awareness — the property that an agent’s internal reasoning conforms to organizational processes, constraints, and goals.
• Framing (Def. 2.4) — the mechanism that restricts an agent’s autonomy through its knowledge and goals so it stays process-aware and goal-aligned.
• Normative frame vs. operational frame — the normative frame specifies what’s allowed/forbidden/required (deontic rules); the operational frame specifies the exact steps (classic BPMN/DECLARE-style process specs). They collapse into one thing if there’s no real decision-maker.
• Goal alignment — the rules of engagement, hierarchies, and role/duty assignments that keep multiple agents’ individual goals compatible with each other and with the process.
• Mental model / intentional model — an agent’s internal beliefs about the process (mental model) and its goals as shaped by obligations, roles, and prohibitions (intentional model); together these are where “framing” actually lives inside the agent.
• Perceive-Reason-Act loop — the standard AI-agent control loop (Russell & Norvig): sense the environment, decide on an action, execute it.
• Explainability (Section 3.2) — an agent’s ability to articulate the rationale behind its decisions and actions, required for trust, accountability, bias detection, and regulatory compliance (GDPR, EU AI Act).
• Conversational actionability (Section 3.3) — the combined ability to (a) converse with humans/other agents about the process and (b) turn that conversation into real actions (Query, Recommend, Create, Execute).
• Self-modification (Section 3.4) — an agent’s capacity to adapt (short-term, instance-specific, reversible) or evolve (long-term, model-level, persistent) its behavior over time.
• Adaptation vs. evolution — adaptation is a one-off, instance-scoped fix; evolution is a permanent change to the shared process model/policy, typically informed by aggregated adaptation patterns.
• BDI (Belief-Desire-Intention) — a classic AI agent architecture where an agent’s state is represented as beliefs (what it knows), desires (what it wants), and intentions (what it’s committed to doing).
• FIPA — a standards body defining agent-communication protocols (how agents message each other in a MAS).
• DECLARE / BPMN — two classic process-specification languages: BPMN is imperative (draws exact control flow); DECLARE is declarative (specifies constraints over allowed behavior) — closer in spirit to a normative frame but not designed to express deontic notions like obligation/permission natively.
• Deontic logic — the branch of logic formalizing obligation, permission, and prohibition; the theoretical basis for normative frames.
• Learning to defer / reject option — an ML technique where a model can decline to predict and hand the decision to a human when its confidence is too low; proposed here as a mechanism for agents to escalate to human oversight.
• LLM-as-a-judge — using an LLM to evaluate or score another model’s (or agent’s) output, proposed here as a way to generate summaries/labels for human audit of self-modifications.
• Dagstuhl Seminar — an invitation-only, week-long research workshop format (Schloss Dagstuhl, Germany) where this manifesto’s content originated (#25192, “AUTOBIZ”).