Sintesi Tecnica: Un Process Harness per l'Elevazione di Workflow Legacy a BPM Agente-centrico

1. Definizione del Problema

I sistemi convenzionali di Business Process Management (BPM), pur fornendo rigorose garanzie strutturali, soffrono di due limitazioni fondamentali in ambienti dinamici:

1. Regime a Mondo Chiuso: Ogni deviazione dal percorso nominale deve essere anticipata e modellata esplicitamente al tempo della progettazione. Le situazioni impreviste (ad esempio, cambiamenti normativi, profili di richiedenti inediti) costringono il sistema in stati di errore o richiedono l'intervento umano, portando spesso a "soluzioni temporanee" (workarounds) che aggirano i processi formali.
2. Esecuzione dei Task Rigida: I task di servizio si affidano a script fissi incapaci di adattarsi a input non strutturati, mentre i task utente introducono vincoli di throughput. Il motore stesso manca della capacità di ragionamento aperto o di adattamento contestuale.

Sebbene i Large Language Models (LLM) offrano un ragionamento aperto, i paradigmi di integrazione attuali sono insufficienti. Il paradigma "AI-augmented" (LLM all'interno di task specifici) lascia il controllo del flusso complessivo rigido. Al contrario, il paradigma "LLM-as-Planner" (LLM che generano piani di esecuzione al di fuori del motore) manca di meccanismi per garantire la conformità strutturale, l'auditabilità o l'aderenza alle politiche di compliance. È necessario un sistema che riconcili la rigidità strutturale dell'esecuzione deterministica dei workflow con il ragionamento adattivo degli agenti governati da policy senza sostituire i motori di workflow esistenti.

2. Metodologia: Il Process Harness e il Modello TDF

Il documento introduce il Process Harness, un meccanismo che sovrappone uno strato di agenti governati da policy a un esistente motore di workflow deterministico. Questo strato intercetta determinati punti di controllo per contribuire con ragionamento, adattamento e supervisione, mentre il motore mantiene l'autorità strutturale.

Il fondamento concettuale è il modello Task–Decision–Flow (TDF), che decompone il ragionamento dell'LLM attraverso tre tipi distinti di agenti vincolati da policy:

• TaskAgent: Responsabile dell'esecuzione di task ad alta intensità di conoscenza. Sostituisce gli script codificati in modo rigido con l'esecuzione di un LLM governato da policy, ragionando entro una specifica policy di task ($C_T$) per produrre output di dominio.
• DecisionAgent: Responsabile del routing dei gateway per singolo caso. Sostituisce la valutazione statica delle condizioni con il ragionamento dell'LLM vincolato da una policy decisionale ($C_D$). Fondamentalmente, impone un passaggio deterministico di valutazione della condizione prima del ragionamento per garantire che la condizione del gateway sia esplicitamente valutata.
• FlowAgent: Responsabile dell'adattamento del flusso a runtime tramite un meccanismo di hook principato. Intercetta determinati flussi di sequenza (hook) e ragiona sotto policy di hook ($C_F$) per raccomandare interventi strutturali (es. saltare, scambiare, terminare o modificare la topologia).

Framework di Governance (FRAME):
Tutto il ragionamento degli agenti è delimitato dal FRAME ($F$), un insieme aggregato di documenti di policy leggibili dall'uomo. Ciò garantisce una "autonomia incorniciata" (framed autonomy), dove gli agenti operano entro vincoli espliciti e verificabili. Un secondo livello di governance, action_permissions ($\phi$), elenca esplicitamente quali tipi di intervento strutturale un FlowAgent è autorizzato a istruire, separando il ragionamento dell'LLM dalle capacità di esecuzione del motore.

Architettura (CUGA FLO):
Il documento presenta CUGA FLO come la prima realizzazione del modello TDF.

• Disaccoppiamento: Lo strato di ragionamento (FlowAgent e i suoi sub-agenti) è completamente disaccoppiato dallo strato di esecuzione (WorkflowEngine) tramite un Model Context Protocol (MCP) Bridge (implementato come server FastMCP).
• Interazione: Il motore di workflow guida l'esecuzione e si mette in pausa ai punti di controllo (task, gateway, hook) per invocare callback (execute_task, route_gateway, evaluate_hook). Il FlowAgent elabora queste chiamate utilizzando ControlPointFlowKnowledge (modello di processo, stato, cronologia) e restituisce raccomandazioni strutturate.
• Esecuzione: Il motore di workflow impone la conformità strutturale, applicando le raccomandazioni del FlowAgent (ad esempio, ricollegando i flussi per skip_to o remove_node) senza rieseguire i nodi già eseguiti.

3. Contributi Chiave

Il documento presenta cinque contributi specifici:

1. Paradigma Process Harness: Introduce un meccanismo per elevare i sistemi di workflow convenzionali a BPM Agente-centrico, caratterizzato da conformità strutturale, accountability di policy e adattabilità a runtime.
2. Modello Task–Decision–Flow (TDF): Una decomposizione concettuale formale del ragionamento dell'LLM in tre tipi di agenti (Task, Decision, Flow), ciascuno con ruoli e vincoli di policy distinti.
3. Istanziazione di FRAME: Formalizza l'insieme aggregato di policy ($F$) che governa i processi TDF, dimostrando come la partizione delle policy tra i tipi di agenti garantisca la separazione delle responsabilità a livello di LLM.
4. Realizzazione CUGA FLO: Presenta la prima implementazione del process harness, dotata di un meccanismo di hook per l'adattamento a runtime e di un ponte MCP che disaccoppia il ragionamento dal motore di workflow sostituibile.
5. Dimostrazione Empirica: Valida il modello utilizzando un workflow di approvazione prestiti che esercita tutti e tre i tipi di agenti e un hook di override normativo, mostrando come un hook possa sovrascrivere una decisione di un gateway basandosi su un criterio diverso (es. ID del richiedente) senza modificare la policy del gateway.

4. Risultati e Valutazione

Il documento dimostra il sistema attraverso un caso di studio su un workflow di approvazione prestiti:

• Caso Nominale: Un controllo del credito standard (TaskAgent) produce un punteggio; un DecisionAgent instrada in base a una soglia; un FlowAgent hook conferma la continuazione.
• Caso di Override Normativo: Un richiedente con punteggio elevato (ID 4321) viene indirizzato all'approvazione dal DecisionAgent in base al punteggio. Tuttavia, un hook del FlowAgent intercetta il flusso "yes", applica una policy normativa (basata sull'ID) e istruisce un intervento di skip_to verso il percorso di rifiuto.
• Risultato: Il sistema gestisce con successo la "coda lunga" di varianti rare e specifiche del contesto (override normativi) senza modificare il modello BPMN sottostante. Il DecisionAgent e il FlowAgent operano sotto policy separate, garantendo che la logica di routing e la logica di override normativo siano indipendentemente verificabili.

I risultati confermano che il process harness può riconciliare i requisiti imperativi (imposti dal motore) con i requisiti normativi (imposti dagli agenti incorniciati dalla policy), consentendo un adattamento in "mondo aperto" pur mantenendo l'integrità strutturale.

5. Significato e Rivendicazioni

Il documento sostiene che il Process Harness rappresenti una nuova forma di strumentazione per i sistemi di IA aziendali. La sua importanza risiede nel:

• Riconciliare la Tensione: Risolve il compromesso tra rigidità strutturale e flessibilità aperta separando la topologia del processo (fissa, imposta dal motore) dall'adattamento del processo (dinamico, governato dalla policy).
• Modernizzazione Incrementale: Permette alle organizzazioni di trasformare i sistemi di workflow esistenti in sistemi pienamente agentici in modo incrementale e reversibile, senza sostituire il motore sottostante.
• Accountability: A differenza degli approoli "LLM-as-Planner" dove le tracce di esecuzione possono essere non deterministiche o non collegate a un modello, CUGA FLO fornisce un substrato di accountability concreto. Ogni chiamata all'LLM è associata a un documento di policy governante, e ogni intervento è registrato nella conoscenza del processo legata a elementi di processo specifici, consentendo audit e diagnostica della non conformità.
• Adattamento in Mondo Aperto: Sposta la gestione delle eccezioni da un'attività di design-time in mondo chiuso (modellare ogni possibile percorso di errore) a una capacità di runtime in mondo aperto, dove l'insieme delle situazioni gestibili è definito dalla capacità di ragionamento dei documenti di policy.

Gli autori posizionano CUGA FLO come la prima realizzazione del manifesto del BPM Agente-centrico, fornendo un framework pragmatico per le organizzazioni per evolvere dal BPM aumentato da agenti al pieno BPM Agente-centrico, dove gli agenti governano il processo end-to-end.