An Agentic AI for a New Paradigm in Business Process Development

TL;DR

Classic business process (BP) automation pins everything to a flowchart of tasks: do step A, then B, then C. That breaks the moment reality deviates from the diagram. This paper proposes flipping the model to be declarative and goal-driven. You specify what must be true (goals, each defined by a set of business objects like a “checked order” or a “cooked pizza”), and you define agents that know how to produce those objects given some trigger inputs. An agent fires automatically when its trigger objects exist; the order of execution (precedence) is derived from the data dependencies, not drawn by hand. The contribution is a small, clean formalism — agents as 6-tuples, goals as triples, a whole process as a 6-tuple — plus split/merge semantics (AND/OR/XOR) borrowed from workflow theory and consistency checks that catch broken specs. It’s a position/method paper: the idea is well-formed and the formalism is sound, but there is no implementation, no benchmark, and no agent actually built. The value for a builder is the modeling discipline, not running code.

Problem & Motivation

The concrete pain: a traditional BP model (think BPMN, the boxes-and-arrows diagrams) is a partially ordered set of tasks. Someone draws “Receive order → Validate → Charge card → Notify kitchen → Cook → Deliver.” This works only as long as the world matches the diagram. The instant you hit an edge case the diagram didn’t anticipate — a partial refund, an out-of-stock item, two suppliers racing to fulfill — you’re back editing the flowchart or writing exception branches. The diagram encodes how to reach the outcome, so every new “how” is a code/model change.

Three things make this brittle:

1. Tasks are imperative. They say do this, then that. Imperative order doesn’t bend to context.
2. The control flow is authored by humans. Precedence (what comes before what) is drawn by hand, so it can be wrong, stale, or incomplete.
3. No autonomy. A task can’t look at the situation and pick a different-but-equivalent way to get the same result.

The authors argue that modern agentic AI (LLM-driven agents with reasoning, memory, planning) finally makes a declarative alternative practical: don’t tell the system the steps, tell it the goals, and let intelligent agents figure out the steps in context.

What’s New (Core Contribution)

This is a modeling paper, so the “novelty” is a representation and its semantics, not an algorithm. Four concrete contributions:

• Goal/Object/Agent triad as the BP primitives. Before: a BP is a partially ordered set of tasks (the how). Now: a BP is a partially ordered set of goals (the what), where each goal is defined by the set of business objects that exist when it’s met, and agents are the active entities that produce those objects. Tasks disappear as the central abstraction.

• Precedence is derived, not declared. Before: you draw the arrows (control flow) yourself. Now: the execution order is inductively derived from agents’ trigger objects. Agent A’s output object is Agent B’s trigger → therefore A precedes B. The graph builds itself from data dependencies. This is the most genuinely useful idea in the paper.

• A compact formalism with split/merge semantics. Agents are 6-tuples, goals are triples, the whole process is a 6-tuple, and goals carry AND / OR / XOR split and merge types lifted from classical workflow theory. A merge goal’s object set is literally the set union of incoming agents’ final objects ($O_{G_g} = \bigcup_i O_{F_i}$).

• Built-in consistency checks. Because the model is redundant by design (objects appear both as agent outputs and as goal definitions), you can statically verify a spec: a trigger object that belongs to no goal means an agent that can never wake up (a red flag); an object no agent ever consumes is redundant (dead data).

Be honest about what’s not new: the AND/OR/XOR split/merge vocabulary and the “BP as a partially ordered set” framing are standard workflow theory. CRUDA (CRUD + Archive) for capabilities is a light relabeling. The fresh combination is goal-as-object-set + agents-as-arcs + derived precedence, delivered as a clean tuple algebra.

How It Works (Technically)

The whole method rests on three primitives and one rule. Let me build them up, then trace a real example, then read the math.

The three primitives.

1. Object — a passive piece of business information: a document, a message, a DB record. (If it’s physical, like a cooked pizza, you keep a digital twin — here, a DB record.) Objects are the currency of the system. Everything an agent does is “consume some objects, produce some objects.”

2. Goal — a desired state of affairs, represented by the set of objects that exist when the goal is achieved. This is the conceptual pivot: a goal isn’t an action, it’s a postcondition expressed as data. “Order acquired” = “a checkedOrder object exists.”

3. Agent — the active entity. An agent is defined by: the goal it pursues, the capabilities it needs (CRUDA operations), the trigger objects that must exist for it to start, the resource objects it uses along the way, and the final objects it releases when done.

The one rule that drives everything: trigger-based activation. An agent sits dormant until all its trigger objects exist. Those objects were released either by a preceding agent or handed in at process start (the start objects). When an agent finishes, it releases its final objects — which become triggers for the next agents. There is no central scheduler drawing arrows; the workflow is an emergent consequence of objects appearing.

This is exactly the dataflow / blackboard pattern: agents are productions watching a shared pool of objects, firing when their inputs are present. If you’ve built a multi-agent system with a shared message bus or blackboard, you already know this shape — the paper formalizes it for BPs.

Architecture & data flow

flowchart LR
  OS["Start objects (OS)<br/>e.g. order"] --> A1["Agent a1<br/>Get & Check Order"]
  A1 -->|"checkedOrder/OK"| G1{"split goal:<br/>order valid?"}
  A1 -->|"checkedOrder/KO"| A2["Agent a2<br/>Inform Customer"]
  G1 -->|XOR| A3["Agent a3<br/>Inform Kitchen"]
  A3 -->|pizzaSchedule| A4["Agent a4<br/>Cook Pizza"]
  A4 -->|pizzaDone| A5["Agent a5<br/>Deliver"]
  A5 -->|fulfilledOrder| OE["End objects (OE)"]
  A2 -->|customerNotice| OE

The nodes you think in are goals; the arcs are agents; the labels on the arcs are the objects that flow. A “split goal” can wake more than one agent (AND = all in parallel, OR/XOR = a choice). A “merge goal” is only satisfied once several agents have all delivered (AND merge) or once any one has (OR/XOR merge).

Schematic of trigger-based activation: click a start object to "release" it, watch agents light up when *all* their trigger objects are present, and see precedence emerge from the data — no arrows were drawn by hand. (Illustrative, built from the paper's pizza example.)

Trace one real example (the pizza shop, Figure 1 + Table 1).

Start object: order. Walk it through:

1. order exists → agent a1 (Get&CheckOrder) wakes. It runs its check and releases one of two objects: checkedOrder/OK or checkedOrder/KO. This is an XOR split goal — exactly one branch.
2. If checkedOrder/KO → agent a2 (InformCustomer) wakes (its trigger is checkedOrder/KO), releases customerNotice. Process ends on that branch.
3. If checkedOrder/OK → agent a3 (InformKitchen) wakes, releases pizzaSchedule.
4. pizzaSchedule exists → agent a4 (CookPizza) wakes, releases pizzaDone. (CookedPizza is physical; its DB record is the digital twin.)
5. pizzaDone exists → agent a5 (Deliver) wakes, releases fulfilledOrder — the end object. Done.

Notice nobody specified “a3 runs after a1.” It fell out of the fact that a3’s trigger (checkedOrder/OK) is a1’s output. That’s derived precedence in action.

Demystifying the math

No calculus or RL here — it’s set theory and tuples. Translated:

• Agent $Agent = (aID, C_a, O_{T_a}, O_{R_a}, O_{F_a}, g_a)$. Plain English: an agent is a record with six fields — its id, its capability set $C_a$ (which CRUDA ops it can do), the objects it needs to start $O_{T_a}$ (Trigger), the objects it uses mid-flight $O_{R_a}$ (Resource), the objects it emits $O_{F_a}$ (Final), and the goal $g_a$ it achieves. Operationally this is the agent’s contract: “give me these inputs, I’ll give you these outputs.”

• $aID \rightarrow (gID_a, g_a)$ — an agent functionally determines a pair: the goal that triggered it and the goal it fulfills. I.e., each agent is an arc from one goal-node to another.

• $O_a = O_{T_a} \cup O_{R_a} \cup O_{F_a}$ — the agent’s total “object footprint” is just the union of what it reads, uses, and writes. Useful for impact analysis (what touches object X?).

• Goal $g = (gID, O_g, A_g)$. Plain English: a goal is its id, the object set $O_g$ that defines it (the postcondition-as-data), and $A_g$, the set of agents that goal triggers. If $A_g$ has more than one agent, it’s a split goal; the split type (AND/OR/XOR) decides whether they all fire, or a choice is made.

• Merge $O_{G_g} = \bigcup_i O_{F_i}$ — when several agents feed one goal, that goal’s object set is the union of all their outputs. This is how you say “this goal is met only once parts from multiple producers are all here.”

• Whole process $ABP = (OS, OE, OR, G, C, A)$ — start objects, end objects, all resource objects, all goals, all capabilities, all agents. The redundancy (objects appear in multiple places) is deliberate: it’s what lets you run the consistency checks below.

• Precedence $pre(g_x, g_y)$ — “$g_x$ strictly precedes $g_y$” iff some agent in $A_x$, once triggered, directly contributes to $O_y$. This relation is computed, not authored, and it both draws the diagram and enforces execution order.

The consistency checks (the practical payoff of the redundancy):

• A trigger object (other than a start object $OS$) that belongs to no goal ⇒ an agent that can never wake. Dead agent — red flag.
• An object that appears in no agent’s trigger set $O_{T_y}$ ⇒ nobody consumes it. Redundant object — dead data.

These are exactly the static analyses a compiler does (unreachable code, unused variables), applied to a business process.

The algorithm, simplified

The paper gives no executable algorithm, so here’s the one that falls out of the formalism — a tiny dataflow scheduler. This is the core idea you’d actually type:

# An ABP is goals + agents over a shared pool of objects.
# Agents fire when ALL their trigger objects exist. Precedence is emergent.

def run_abp(agents, start_objects, act):
    """
    agents: list of dicts {id, triggers:set, finals:set, goal, capabilities, act_fn-key}
    start_objects: set of object names available at t0 (OS)
    act(agent, pool) -> set  # the agent's real work (LLM call, API call, DB write); returns final objects
    """
    pool = set(start_objects)          # the blackboard of business objects
    fired = set()
    progressed = True
    while progressed:                  # keep going while any agent can still fire
        progressed = False
        for ag in agents:
            if ag["id"] in fired:
                continue
            if ag["triggers"] <= pool: # ALL triggers present -> agent wakes (AND on its inputs)
                produced = act(ag, pool)          # do the work; may pick OK vs KO branch in context
                pool |= produced                  # release final objects into the pool
                fired.add(ag["id"])
                progressed = True                 # something changed -> re-scan for newly-eligible agents
    return pool                        # end objects OE are whatever ended up in the pool

def validate_abp(agents, start_objects):
    """Static checks the formalism's redundancy enables."""
    all_finals = set().union(*(a["finals"] for a in agents)) | set(start_objects)
    all_triggers = set().union(*(a["triggers"] for a in agents))
    dead_agents = [a["id"] for a in agents
                   if not (a["triggers"] <= all_finals)]   # needs an object nobody (or no start) produces
    dead_objects = (all_finals - set(start_objects)) - all_triggers  # produced but never consumed
    return {"dead_agents": dead_agents, "redundant_objects": dead_objects}

That while progressed loop is the paper: precedence is never stored; it’s re-derived every scan from “are this agent’s triggers in the pool yet?” Swap act for real LLM/agent calls and you have a runnable, if naive, engine.

Built on Prior Work

This sits in the agentic-BPM lineage that exploded in 2024–2025. The paper’s own related-work section names the neighbors; here’s the delta.

The honest read: this paper borrows its semantics from workflow theory and its agent framing from agentic-BPM, and contributes the specific declarative encoding (goal = object set, agent = arc, precedence = derived) with static consistency checking.

Results & Evidence

There are no empirical results. This is a conference position/method paper (Ital-IA 2025, a 6-page Italian national AI conference). The “evidence” is:

• One worked example (the pizza shop) showing the notation is expressive enough to capture a real-ish process with a branch.
• A formal model that is internally coherent (the tuples, the union for merges, the precedence relation, the two consistency checks).

What this establishes: the representation is plausible and self-consistent, and the derived-precedence idea is well-defined. What it does not establish: that it’s easier to author than BPMN, that LLM agents can reliably honor these contracts, that it scales past a toy with five agents, that the “context-aware choice among equivalent actions” actually works (no mechanism is given for how an agent chooses), or any latency/cost/correctness numbers. There is no baseline, no user study, no implementation. Treat it as a design proposal you could test, not a validated technique.

How You’d Use It

For an AI services company, the value is as a client-facing modeling discipline and a spec layer above your agent orchestration, not as a product to ship as-is.

• Discovery / scoping workshops. When a client says “automate our fulfillment,” resist drawing the flowchart. Instead enumerate goals (“order validated,” “kitchen notified,” “delivered”) and the objects that prove each. This reframing surfaces the real data dependencies fast and is far more robust to the client saying “oh, but sometimes…”. It’s a sharper version of the BPMN sessions you already run.
• A planning/spec layer over LangGraph / your ARC MAS. The agent 6-tuple is a clean agent contract: triggers in, finals out, capability scoped to CRUDA. Generate your orchestration graph from these contracts so precedence is computed, not maintained by hand. When the client adds a step, you add an agent with the right trigger/final objects and the graph re-wires itself.
• A linting tool you can sell. The two consistency checks (dead agents, redundant objects) are a genuine, buildable product: feed in a process spec, get back “Agent refund-handler can never run — nothing produces its trigger disputeFiled.” That’s a tangible deliverable on top of a vague client process.
• Audit/compliance angle. Because every goal is defined by persisted objects and CRUDA includes Archive, the model naturally produces an auditable trail (“show me every object that contributed to fulfilledOrder”). That maps directly to regulated-industry clients.

Realistic framing: this is a low-cost, high-leverage thinking tool plus the seed of a small internal framework. It is not going to replace Temporal/Camunda; it’s a way to model before you wire those up.

Build Your Own (Minimal Recipe)

You can stand up an 80%-of-the-value version in a day or two.

Components, in build order:

1. Object & agent registry — a YAML/JSON file per process: list objects, then agents with triggers, finals, goal, capabilities. (Mirror the paper’s Table 1.)
2. The dataflow scheduler — the run_abp loop above. Maybe 40 lines. It already handles AND-on-inputs; add OR/XOR by letting an agent’s act emit one of several alternative final objects.
3. The validator — validate_abp above. This is the part clients will actually pay for; ship it first.
4. Agent execution — wire each agent’s act to a real worker: an LLM call for judgment (“is this order valid?”), an API/DB call for effects. This is where you reach for LangGraph or your own MAS: each ABP agent → one graph node, triggers/finals → edges.
5. Diagram generator — compute pre(g_x, g_y) from the registry and render with mermaid/Graphviz. Free, since precedence is derived.

The 1–2 genuinely hard parts:

• Making split/merge robust. “Fire when all triggers present” is easy. Real life needs timeouts (“merge AND, but supplier B never delivered”), and OR/XOR needs a decision policy — the paper hand-waves “the agent analyses the context and chooses.” That choice logic (an LLM with the right context + guardrails) is the actual engineering.
• Object identity & state. The model treats objects as set membership (“checkedOrder exists”). Production needs typed, versioned, instance-scoped objects (order #5821’s checkedOrder, not “a” checkedOrder), or two concurrent orders will trigger each other’s agents. Add an instance/correlation id to every object. This is the gap most likely to bite you.

Reach for: a graph/orchestration lib (LangGraph, or plain asyncio for the toy), Pydantic for typed objects, and your existing LLM stack for the per-agent judgment.

How to Improve It

The paper leaves obvious, testable open ground:

1. Specify the context-aware choice mechanism. The biggest hole: how does an agent pick among equivalent actions or resolve an XOR? Define it concretely — e.g., the agent is an LLM given the current object pool + a policy prompt, and you evaluate choice quality against labeled traces. This is where you could even bolt on RL (reward = downstream goal achieved at low cost) to learn the choice policy instead of prompting it.
2. Add instance/correlation semantics. Promote objects from “set membership” to typed instances with a correlation key, so multiple process instances run concurrently without cross-triggering. Untested in the paper; mandatory in production.
3. Handle failure and compensation. There’s no notion of an agent failing, retrying, or undoing (the saga pattern). Add compensating agents (e.g., a refund agent triggered by a deliveryFailed object) and timeout-driven merges.
4. Auto-generate the registry from documents. Use an LLM to read existing SOPs/BPMN and emit the goal/object/agent registry — turning the modeling discipline into a near-automatic onboarding tool. Pair with EvoFlow/FLOW [5,6] to optimize the generated agent set.
5. Formalize and prove the static checks, then build the linter. Extend beyond “dead agent / dead object” to deadlock detection (cyclic trigger dependencies), unreachable goals, and merge starvation. This is a real, sellable verification product with provable guarantees.

Glossary

• Business Process (BP) — a coordinated set of activities that turns inputs into a business outcome (e.g., order → delivered pizza).
• Declarative vs. imperative — declarative says what should be true (goals); imperative says how/in what order (tasks). This paper is declarative.
• Business object — a passive unit of business information (document, message, DB record) that agents consume and produce; the system’s currency.
• Goal — a desired state expressed as the set of objects that exist when it’s achieved (a postcondition-as-data).
• Agent — the active entity that produces objects to achieve a goal; here a 6-tuple of (id, capabilities, trigger objects, resource objects, final objects, goal).
• Trigger / start / final objects — inputs that wake an agent / objects available at process start / objects an agent emits when done.
• Precedence (pre) — a derived ordering: g_x precedes g_y if an agent of g_x produces objects that g_y needs. Computed, not drawn.
• Split goal (AND/OR/XOR) — a goal whose objects can trigger several agents: AND = all fire in parallel, OR/XOR = a choice among them.
• Merge goal (AND/OR/XOR) — a goal fed by several agents: AND = satisfied only when all finish, OR/XOR = when any one does. Its object set is the union of incoming finals.
• CRUDA — Create, Read, Update, Delete, Archive; the capability vocabulary for agents (CRUD from databases + Archive for audit/retention).
• Dataflow / blackboard pattern — execution model where workers fire when their inputs appear in a shared pool, rather than being called in a fixed order.
• ABP — Agent-Based Process; the whole-process 6-tuple (start objects, end objects, resource objects, goals, capabilities, agents).
• BPMN — Business Process Model and Notation; the standard boxes-and-arrows task-flow diagrams this paper argues against.