Agentic AI Implementation analysis and next steps.

[pieter-schutte]

Agentic AI Proposals – Analysis and Outcome

Find below my analysis and outcome of the Agentic AI proposals, based on the original discussion thread here:
#6

This is my opinion; happy to be challenged / discuss.

---

How scoring works

Scoring is based on measurements ranked:

• Green – favourable
• Amber – caution
• Red – unfavourable

Dimensions:

1. Speed to market – how quickly can we do this?
2. Auditibility – how auditable is this from a BPMN perspective?
3. Complexity – risk due to changes needed (engine, modeler, concepts).
4. User Friendliness – end user ease of use.

---

Proposals

---

Proposal 1 – Chris M: Introduce new editor and task type for agent configuration

Pattern: Opaque agent worker

Summary

• New Agent task type in BPMN.
• New Agent editor in Modeler for configuring: provider, model, prompts, tool definitions, etc.
• Optional “test agent” feature from within editor.
• Tools are configured but are not first-class BPMN activities; they are hidden inside the worker.

Conceptual clarity

This is essentially “AI Service Task 1.0”:

• BPMN shows one task: “Agent Task”.
• All agent and tool behaviour is “in the box” (worker + config).
• Tools are not auditable at BPMN level; you rely on logs from the worker.

Pros / Cons

Pro	Con
Simplest proposal so relatively quick to implement.	No traceability / audit of tool invocation.
Easy abstraction of the fast moving LLM implementation landscape.	Inflight cases will have the same tools for v1 of process as for v10.
	No BPMN tool timeouts, retries, etc.
	Dependency on MCP infrastructure.

Scoring

• Speed to market: Green
• Auditibility: Red
• Complexity: Green
• User Friendliness: Amber

---

Proposal 2 – Aurelian A: LLM dev assist will help with prompt generation

Note: I feel this one is very close to “Proposal 1 – Chris M: Introduce new editor and task type for agent configuration”. I've repeated it here for completeness. @aurelian-valeriu-apostol-db @mr-dibbs please update if you feel its missrepresented.

Pattern: Opaque agent worker, extended with MCP

Summary

• New Agent task type in BPMN.
• New Agent editor in Modeler for configuring: provider, model, prompts, tool definitions, etc.
• Optional “test agent” feature from within editor.
• Tools are configured but are not first-class BPMN activities; they are hidden inside the worker.

Conceptual clarity

This is essentially “AI Service Task 1.0”:

• BPMN shows one task: “Agent Task”.
• All agent and tool behaviour is “in the box” (worker + config).
• Tools are not auditable at BPMN level; you rely on logs from the worker.

Pros / Cons

Pro	Con
Simplest proposal so relatively quick to implement.	No traceability / audit of tool invocation.
Easy abstraction of the fast moving LLM implementation landscape.	Inflight cases will have the same tools for v1 of process as for v10.
	No BPMN tool timeouts, retries, etc.
	Dependency on MCP infrastructure.

Scoring

• Speed to market: Green
• Auditibility: Red
• Complexity: Green
• User Friendliness: Amber

---

Proposal 3 – Chris M: Agent Ad-Hoc Subprocess

Pattern: Agent with declarative tool registry (using Ad-Hoc Subprocess)

Summary

• Use an Ad-Hoc Subprocess as the structural container for an “agent & tools” implementation.
• Extend its behaviour to:
  • Hold agent configuration (provider, model, etc.).
  • Possibly list tools declaratively as new BPMN tool activities.
  • Provide Modeler and engine support, plus an element template.

Conceptual clarity

Agent with declarative tool registry, with some aspects of orchestrator:

• The ad-hoc subprocess is the “agent context”.
• Tools are BPMN tasks inside it, but the order is not strictly defined.
• The engine/agent decides which tasks to activate within the ad-hoc subprocess.

Pros / Cons

Pro	Con
Matches market leader.	For true user friendliness, each tool will need to have some sort of Modeler equivalent (although it can rely on Proposal 5's pure BPMN approach).
Provides auditability.	Ad-hoc subprocess has limited support in Fluxnova (TBC).
Very user friendly.	Ad-hoc subprocess requires all invoked tools to complete before passing control back to the LLM, so long-running tools delay other evaluations.

Scoring

• Speed to market: Red
• Auditibility: Green
• Complexity: Red
• User Friendliness: Green

---

Proposal 4 – Chris M: CMMN

Pattern: Agent as orchestrator, but using CMMN instead of BPMN ad-hoc

Summary

• Similar goal to Proposal 3 (agent orchestrates tasks), but implemented via CMMN constructs instead of BPMN ad-hoc subprocess.
• Leverages Case Management Model and Notation for dynamic task selection and enablement.

Conceptual clarity

Conceptually, CMMN is designed for case/knowledge-worker scenarios:

• Tasks are enabled/disabled based on conditions, with lots of flexibility.
• That maps nicely onto an agent controlling tool execution.

However:

• CMMN adoption in the wild is low.
• Many users and toolchains have little or no CMMN experience.
• It introduces a second notation for users and engine implementers.

Pros / Cons

Pro	Con
Leverages an existing specification (CMMN) designed for dynamic, case-like behaviour.	Low adoption of CMMN in the wild.
Good conceptual fit for an agent that selectively enables/disables tasks.	Many users and toolchains have little or no CMMN experience.
	Introduces a second notation for users and engine implementers.

Scoring

• Speed to market: Red
• Auditibility: Green
• Complexity: Red
• User Friendliness: Amber

---

Proposal 5 – Steve H: Agent Follow existing Case Management pattern (Agent as orchestrator)

Pattern: Agent as orchestrator

Summary

1. Add new agent editor to Modeler. The editor will allow for agent configuration (provider, model, prompts, etc.).
2. Model tools inline using standard BPMN patterns and notations (event subprocess).

Pros / Cons

Pro	Con
Backwards compatibility.	Without dedicated tool palettes for tools X, Y and Z, the user will need to model start/end events for each tool.
Proven pattern.	Without dedicated tools, modelling might become a free for all.
Full audit.
Completed tools can immediately be sent to LLM, and execution of the whole block can be ended via standard BPMN.

Scoring

• Speed to market: Amber
• Auditibility: Green
• Complexity: Amber
• User Friendliness: Amber for new users (Green for BPMN pros)

---

Please review and provide feedback / challenge

---

Outcome

I feel we need to proceed with 3 or 5. Perhaps a combination of both (ad-hoc with event subprocess tools).

Regardless of how we render the modeler components, we will need some server-side components that provide a shared runtime foundation.

• Proposals 1, 2, 3, 5 will all need Component 1 – a server-side agent configuration and resolution component.
• Proposals 3, 5 will additionally need Components 2–5, which cover tool discovery, LLM interaction, tool execution, and feeding tool results back into the LLM.

Server-Side Components (High Level)

1. Component 1 – Agent Configuration & Resolution

• Holds the canonical agent config (provider/model, prompts, context bindings, tool-scope reference).
• Given a process definition/element/tenant at runtime, returns a resolved AgentConfig object for use by the other components.
• Certain aspect configurable by element template

2. Component 2 – Tool & Context Discovery

• Inspects the BPMN definition for a given “agent region” and produces:
  • A ToolRegistry (tool IDs, descriptions, BPMN element refs, basic IO/constraints).
  • A ContextDescriptor (which variables/data objects are exposed to the agent).

3. Component 3 – LLM Orchestration & Tool-Call Requestor

• Combines AgentConfig, ToolRegistry and runtime context to call the LLM.
• Returns a normalised response containing assistant text plus zero or more tool-call requests (tool ID + arguments).

4. Component 4 – Tool Invocation Driver

• Validates LLM tool-call requests against the ToolRegistry.
• Maps each tool-call to the correct BPMN element (ad-hoc task or event subprocess) and triggers execution in the engine.

5. Component 5 – Tool Result Feedback Loop

• Listens for BPMN tool completion events, correlates them to prior invocations, and produces structured tool results.
• Feeds tool results back to Component 3 (for further LLM steps) and, when done, completes the agent invocation task.

Next Steps

With these server-side components defined:

• We can start PoC’ing both:
  • Proposal 3 (Ad-Hoc Subprocess / declarative tool registry), and
  • Proposal 5 (Event Subprocess / existing Case Management pattern),
    using the same Component 1–5 stack as the backend.
• Modeler / UI components can then be designed to sit on top of this stack, experimenting with different visual representations (opaque agent task, ad-hoc region, event subprocess tools) without changing the underlying server-side contracts.

I am happy for NatWest to focus on Components 3–5, maybe 2.

[pieter-schutte]

A head start!

#15

[ryans58]

Excellent analysis. I vote for number 5, because I think it's the cleanest use of BPMN 2.0 constructs. Essentially, at least IMO and from the engine's perspective, each interaction from an LLM to the engine is an event.

[pieter-schutte]

@finos/fluxnova-maintainers @finos/fluxnova-contributors -- Your thoughts please.

[gliptak]

@pieter-schutte would you also add #15 to your analysis summary?

[JamieWhitMac]

@pieter-schutte thanks so much for such an in-depth analysis.

I agree that Proposals 3 and 5 are the most promising directions, and I suspect we may not need to choose between them (as I think different workflow use cases may require combinations of A-HSP and ESP usage).

As you point out, both patterns share the same underlying agent runtime requirements, so pursuing them in parallel on top of a common server‑side foundation feels right to me.

Frontend exploration (A=HSP vs ESP) can progress in parallel, without impacting backend design.

The backend contracts (on a high level, anyway) look clean. Depending on what other feedback is received, feels like we can start developing some of these components pretty immediately and your next steps look good. We may want to prototype proposal 3 or 5 to validate developer ergonomics and the modeller's mental model. Happy to discuss further.

[HarishMalavade]

I vote for proposal 3 but in my opinion it involves two steps

1. Enable Adhoc subprocess capability in Fluxnova independent of Agentic integration
2. LEverage adhoc subprocess integration with Actual Agentic AI to provide the undeterministic behavior - we dont have to do what competative product did in this case we can be little creative to make a step before which can be a AI connector generating output and providing inputs to next step in the process which can be adhoc subprocess that might keep the agentic integration independent of adhoc subprocess