Agents, Not Tasks: Rethinking Business Processes in the Age of AI

TL;DR for operators

Most companies trying to “add AI agents” to operations are still thinking in task boxes: receive request, validate request, route request, process request, update system, send notification. That is familiar. It is also exactly the habit this paper wants to disturb.

Azarijafari, Mich, and Missikoff propose a business process model built around goals, objects, and agents, not around fixed task sequences.¹ In their framing, a process is not primarily a diagram of who does what next. It is a set of desired business states, the information objects that represent those states, and the agents capable of producing or transforming those objects.

The useful business idea is simple but not small: before deploying autonomous agents, define the process as an information dependency system. What object starts the process? Which object proves that a goal has been achieved? Which agent can create, read, update, delete, or archive which object? Which final object triggers the next agent? Where do multiple agents need to merge their outputs? Where can the process split into alternatives?

That shift helps operators avoid one of the most common agentic-AI mistakes: replacing a brittle workflow with a more expensive brittle workflow that now also speaks in cheerful paragraphs. Excellent, the spreadsheet has become self-confident.

The paper does not prove that this model works at enterprise scale. It has no production deployment, benchmark, ablation, cost model, or reliability test. Its evidence is conceptual: definitions, a formal representation, and a running pizza-delivery example. That is a limitation, but not a fatal one. For companies still struggling to decide where agents belong in a process, the paper is useful as a design lens. Treat it as a modelling grammar, not a vendor-ready operating system.

The problem is not that workflows are old. It is that they over-specify the wrong thing

Business process modelling has always been a compromise between control and reality. The diagram says work moves neatly from one box to the next. The actual organisation says the supplier did not attach the certificate, the customer changed the order, the compliance officer is on leave, and the approval email is somewhere between Outlook, Slack, and divine intervention.

Traditional process models are good at representing task order. They are less comfortable when the next step depends on a changing context, incomplete information, or a decision that cannot be reduced to a stable branch in a diagram. That is where agentic AI becomes interesting. Not because agents magically make organisations adaptive. They do not. But because agents make it plausible to delegate parts of the interpretation, selection, and coordination work that static workflows normally avoid.

The paper’s starting point is that traditional task-based business process models are typically built from predefined task sequences and static rules. The authors argue that dynamic organisational settings need something more flexible: a process model where autonomous agents pursue goals, respond to information objects, and choose among possible actions depending on context.¹

This is where the paper’s mechanism matters. It does not merely say “use agents in workflows.” That would be the kind of advice one could obtain by shaking a conference badge at random. Instead, it proposes a different unit of analysis.

The old question is:

What tasks happen, and in what order?

The proposed question is:

What goals must be achieved, what business objects represent achievement, and which agents have the capabilities to produce those objects?

That may sound like a minor modelling preference. It is not. It changes the object of managerial attention from activity sequencing to dependency design.

The mechanism: goals are states, objects are evidence, agents are producers

The paper’s agent-based business process model begins with three basic components: goals, objects, and agents.

A goal is a desired state of affairs. It is not just a slogan such as “serve the customer better.” In the model, a goal is characterised by the business objects that show the goal has been reached. These objects can be documents, messages, database records, or digital representations of physical items.

An object is the passive entity manipulated in the process. It may start a process, trigger an agent, serve as a resource during work, or appear as an output when a goal has been achieved.

An agent is the active entity responsible for achieving a goal. It wakes up when its trigger objects are ready, uses relevant resources, applies required capabilities, and releases final objects.

The important detail is that the workflow is not primarily drawn as a task sequence. It is derived from the dependencies among objects and goals. If Agent B needs an object produced by Agent A, then the system can infer a precedence relation. The process order emerges from information dependencies rather than being manually imposed as a fixed path.

Here is the simplified mapping.

This is the paper’s most useful conceptual move. It makes business automation less about drawing boxes and more about specifying the material of coordination: information objects, capabilities, and dependencies.

For an enterprise team, this means a process redesign workshop should not begin with “Where can we insert an AI agent?” It should begin with a more boring and therefore more valuable inventory:

1. What object proves the process has started?
2. What object proves the process has ended?
3. What intermediate objects prove each business goal has been achieved?
4. Which agents can create, read, update, delete, or archive those objects?
5. Which objects trigger which agents?
6. Which objects are resources, rather than triggers or outputs?
7. Which goals require multiple agents to contribute?

That is not glamorous. It is exactly why it is useful.

The pizza example is small, but it exposes the modelling shift

The paper uses a home-delivery pizza shop as its running example. This is not a business transformation epic. No one is asked to imagine a global procurement network being rescued by a pizza. Mercifully.

The example starts with an order and ends with a fulfilled order. The process includes agents that acquire and check the order, inform the customer if the order is invalid, inform the kitchen if the order is valid, cook the pizza, and deliver it. The table in the paper specifies each agent’s competence, trigger object, final object, and goal.

The example is deliberately simple. Its purpose is not to prove performance. It functions as an implementation detail for explanation, showing how the proposed grammar represents a process.

A conventional workflow might describe this as a sequence:

Receive order → check order → notify kitchen → cook pizza → deliver pizza.

The agent-based model describes it differently:

The difference is subtle but consequential. The process does not move forward because someone drew the next arrow. It moves forward because the right object exists. A valid checked order triggers the kitchen path. An invalid checked order triggers the customer-alert path. A completed pizza triggers delivery.

This is the paper’s mechanism in miniature: business state is represented by objects; agents are activated by objects; process structure emerges from object dependencies.

In a real company, the “pizza” could be a loan application, a purchase order, a hotel booking, a warranty claim, a supplier invoice, a construction variation order, or a customer onboarding file. The point is not the domain. The point is the modelling discipline.

If the next action depends on whether the correct document, message, record, or digital artefact exists, then the process should be modelled around those artefacts. Otherwise, teams risk automating the performance of work without modelling the conditions that make the work legitimate.

The formalism is doing governance work, not academic decoration

The paper then formalises an agent as a six-part structure:

In plain language, this means each agent is defined by:

• an identifier;
• a set of capabilities;
• trigger objects required to start;
• resource objects used during work;
• final objects released after achieving its goal;
• the goal it pursues.

The authors use CRUDA capabilities: Create, Read, Update, Delete, and Archive. The addition of Archive is especially business-relevant. Many enterprise processes do not merely transform data; they must preserve records for inspection, audit, compliance, dispute resolution, or later decision-making. A process model that forgets archiving is basically a litigation support system with optimism issues.

The paper also defines a goal as:

A goal has an identifier, the objects that characterise it, and the agents triggered by those objects. If one goal triggers multiple agents, it becomes a split goal. The authors distinguish AND, OR, and XOR splits. A merge goal, conversely, is fulfilled when multiple incoming agents complete their contribution, either all of them or at least one depending on the merge condition.

Finally, an Agent-Based Business Process is defined as:

This includes start objects, end objects, resource objects, goals, capabilities, and agents.

At first glance, these tuples look like formal packaging around common-sense workflow ideas. But the formalism has a practical purpose: it enables consistency checks.

The authors explicitly note that the model is redundant, and that this redundancy helps analysis. For example:

This is where the model becomes more than a diagramming style. It becomes a way to ask whether an agentic workflow is structurally coherent before anyone ships it.

That is useful because enterprise AI failures often look technical only after the fact. Before the model hallucinates, the process usually already failed to specify what counts as a valid input, who owns the output, what record must be preserved, and which downstream action depends on which upstream artefact. The AI merely adds vocabulary.

What the paper directly shows

The paper directly contributes a conceptual and formal model for agent-based business process development. It argues for shifting from task-oriented workflows to goal-driven processes in which autonomous agents interact through business objects.

Its evidence is not empirical. There are no experiments, production case studies, user studies, benchmark comparisons, latency measurements, cost estimates, safety evaluations, or ablation tests. The pizza-delivery example is illustrative. The formal definitions are the main contribution.

So the correct reading is:

This matters because agentic AI writing is currently full of demonstrations that confuse can be described with has been validated. This paper should not be inflated into a claim that agentic BPM is solved. It is better understood as a proposed modelling language for thinking about such systems.

That is not a dismissal. A clean modelling language is valuable precisely because the industry is racing toward deployment with the architectural discipline of a group chat.

What Cognaptus infers for business use

The business value is not “agents will make workflows flexible.” That is too broad to be useful. The sharper inference is this:

Agentic automation should be designed around verifiable business objects before it is designed around autonomous behaviour.

This has three practical consequences.

First, companies should build an object ledger for candidate agentic workflows. Every important business state should map to a document, message, database record, digital twin, approval, or structured artefact. If the state cannot be represented, the agent cannot reliably coordinate around it.

Second, companies should define agent capability coverage. The question is not only whether an LLM can draft, summarise, classify, or reason. The question is whether the operational agent is authorised and equipped to create, read, update, delete, or archive the relevant business objects. Many “AI agent” proposals collapse here. They describe intelligence but not permission.

Third, companies should perform dependency checks before automation. If an agent depends on an object no upstream process produces, it will stall. If an object is produced but never used, the process may be generating administrative exhaust. If a final object is not linked to the actual business outcome, the process can appear complete while the business problem remains unresolved. This is how dashboards become theatre. Beautiful theatre, but still theatre.

A useful enterprise workflow review based on this paper would look like this:

This is also where the framework becomes relevant to ROI. The immediate return may not come from replacing staff. It may come from discovering that the organisation does not have a coherent process specification in the first place. Very inconvenient, very common.

The misconception: this is not an agentic BPM product

The easiest bad reading of this paper is to treat it as a blueprint for a finished agentic business process automation system. It is not.

The authors are proposing a model. They are not presenting an implementation with live agents, a runtime environment, orchestration logic, exception handling, monitoring, security controls, human approval gates, or system integration. The paper does mention governance concerns such as safety, ethics, accountability, transparency, human oversight, audit, and correction. But these appear as deployment challenges, not as solved components of the framework.

That distinction matters for buyers and operators. A process model can tell you what should be represented. It does not tell you whether GPT-based agents, workflow engines, robotic process automation tools, ERP connectors, or custom microservices will execute it safely.

In real deployment, the hardest questions arrive immediately:

• How does an agent know that a trigger object is complete, authentic, and authorised?
• Who resolves conflict when two agents update related objects?
• What happens when an agent produces a plausible but wrong final object?
• How are object versions tracked?
• What is the rollback mechanism?
• Which actions require human approval?
• How are archived records made audit-ready rather than merely saved somewhere?
• Can the model handle long-running cases, exceptions, escalations, and partial failure?
• How do agents interact with legacy systems whose data models were designed during the fax-machine emotional era?

The paper does not answer these questions. That is acceptable for a conceptual contribution. It becomes unacceptable only if readers mistake the contribution for proof of operational readiness.

Where the model is strongest: processes with visible information artefacts

The framework is strongest where business processes already revolve around identifiable information artefacts. That includes claims processing, onboarding, procurement, compliance review, scheduling, booking, invoice handling, loan documentation, permit applications, and service tickets.

In these settings, the model’s object-centred view is natural. A claim has submitted documents, validation records, decision notices, payment instructions, and archives. A procurement process has requisitions, quotations, approvals, purchase orders, delivery receipts, invoices, and payment records. A hotel events process has inquiry forms, quotations, contracts, rooming lists, payment confirmations, banquet orders, and post-event settlement records.

For these cases, an agent-based goal-driven model can help reveal whether automation has the necessary material to operate.

Take a supplier onboarding process. A task-based workflow might say:

Collect documents → verify supplier → approve supplier → create vendor account.

The agent-based version asks:

• What object starts onboarding?
• Which documents constitute a complete supplier file?
• Which agent verifies tax registration?
• Which agent checks sanctions or compliance status?
• Which final object proves approval?
• Which object triggers vendor creation?
• Which objects must be archived?
• Which merge goal combines legal, finance, and compliance outputs?

This is more precise than saying “use an AI agent to handle supplier onboarding.” It forces the organisation to state what the agent must observe, produce, and preserve.

That is the value.

Where the model is weakest: judgement-heavy work with unstable objects

The framework becomes harder to apply when the business process depends on judgement that cannot easily be represented through stable objects.

Some work produces clear artefacts. Other work produces provisional interpretations, negotiated commitments, political compromises, or tacit confidence. In those settings, “final object” can become a misleading label. A memo may exist, but the real goal may be stakeholder alignment. A meeting summary may be produced, but the real outcome may be trust. A strategy document may be archived, but the actual decision may still be unresolved. Shocking news: not every business state fits neatly into a database record.

This does not make the model useless. It means it should be applied with care. Teams should distinguish between:

The boundary is not whether AI is involved. The boundary is whether the business state can be represented by objects that agents can legitimately use as triggers, resources, or outputs.

The missing implementation layer is where the real risk lives

The paper’s conclusion correctly notes that agentic systems raise safety, ethics, accountability, control, transparency, oversight, audit, and correction issues. For business use, those cannot remain end-of-paper concerns. They must become design constraints attached to the model itself.

The formal framework could support this, but the paper does not yet develop it fully. A production-grade version would need additional layers.

One layer is authority. CRUDA capabilities describe what an agent can do to objects. But enterprise deployment also needs to define what the agent is authorised to do under which conditions. Reading a document, updating a record, deleting an object, and archiving a contract carry very different risk profiles.

Another layer is verification. A final object should not be accepted merely because an agent produced it. The system needs validation rules: schema checks, human review, cross-source comparison, confidence thresholds, audit trails, or exception routing.

A third layer is observability. If workflows emerge from agent interactions, operators need a way to see not just the result but the dependency path: which object triggered which agent, which resources were consulted, which capability was used, which final object was produced, and why the next agent woke up.

A fourth layer is failure handling. Static workflows are annoying, but at least they can be explicit about escalation. Agentic workflows need comparable mechanisms for stalled trigger objects, contradictory outputs, partial merges, repeated retries, and unsafe proposed actions.

In other words, the paper supplies the modelling skeleton. A deployable enterprise system still needs muscles, nerves, immune response, and probably a lawyer hovering nearby with a red pen.

How operators can use the paper tomorrow without pretending it is finished

The most practical use of the paper is as a pre-automation diagnostic. Before buying or building agentic workflow tooling, teams can translate one candidate process into the paper’s terms.

A lightweight workshop could proceed as follows.

Step 1: Select a process with clear artefacts. Choose something document-rich and operational, not a vague “improve collaboration” process.

Step 2: Define start and end objects. Do not say “customer onboarding starts when the customer signs up.” Identify the actual object: application form, email request, CRM record, signed contract, payment confirmation, or ticket.

Step 3: Decompose the process into goals. Each goal should correspond to an observable business state, not a department’s activity label.

Step 4: Map objects to goals. For every goal, specify which objects prove the state has been reached.

Step 5: Define candidate agents. For each agent, list trigger objects, resource objects, final objects, and capabilities.

Step 6: Run consistency checks. Look for unreachable agents, orphaned objects, missing capabilities, invalid precedences, and unclear merge conditions.

Step 7: Add governance gates. Mark which object changes require human approval, automated validation, audit logging, or rollback.

This is not glamorous transformation work. It is better: it is the work that prevents glamorous failure.

The business takeaway: agentic workflows need object discipline

The paper’s best idea is that business processes should be rethought as goal-driven systems where agents coordinate through business objects. That is a meaningful shift from task-based automation, especially for environments where conditions change and agents must select among possible actions.

But the practical lesson is more restrained than the usual agentic-AI pitch. Companies should not read this as proof that autonomous agents are ready to run complex enterprise processes. They should read it as a warning that autonomous agents need a stronger process model than “here is the current workflow, now sprinkle intelligence on it.”

If the workflow is built around tasks alone, the agent inherits ambiguity. If the workflow is built around goals and objects, the agent at least has a structured environment: what must exist, what can be used, what can be changed, what must be preserved, and what counts as completion.

That is the difference between automation that acts and automation that knows when it is allowed to act.

The next generation of business process design may indeed be less about tasks and more about agents. But the agents will not save the process from poor modelling. They will simply execute the confusion faster, and with better grammar.

Cognaptus: Automate the Present, Incubate the Future.