Layer esecutivi

Trigger vs Schedule vs Agenti Interattivi

Non ogni task dovrebbe diventare una chat. I sistemi agentici migliori scelgono prima il modello di esecuzione, poi il modello AI.

Uno degli errori piu comuni nei sistemi agentici e forzare ogni task dentro un'interfaccia conversazionale. Un approccio piu affidabile separa tre layer: trigger per il lavoro guidato da eventi, schedule per il lavoro ricorrente in background e agenti interattivi per task dinamici che richiedono chiarimenti, giudizio o iterazione.

Fatti chiave

Layer esecutivi: 3
Decisione primaria: Evento, schedule o conversazione
Spina dorsale comune: Workflow engine + contesto + monitoring
Preoccupazione operativa: Retry, idempotenza, hand-off
Failure comune: Forzare tutto dentro la chat
Usa con: Queue, worker, inbox, interfacce operative

Come dovrebbe scegliere un team il layer esecutivo corretto?

Usa i trigger quando qualcosa cambia all'esterno e il sistema deve reagire. Usa le schedulazioni quando il lavoro e prevedibile e basato sul tempo. Usa agenti interattivi quando il task richiede chiarimenti, steering, approvazioni o giudizio durante l'esecuzione.

Quando un team non dovrebbe usare un agente?

Non introdurre un LLM quando una regola deterministica, un webhook, un form flow o un job schedulato risolve gia il problema in modo pulito. Il layer agentico dovrebbe gestire ambiguita, prioritizzazione, giudizio e recupero, non sostituire automazioni semplici per moda.

Evidence

Apri la libreria esempi

Usa gli esempi di implementazione per confrontare automazioni dirette e flussi piu agentici.

Apri esempi

Dottrina

Torna alla dottrina di orchestrazione

Mantieni la scelta del layer esecutivo collegata ai principi di orchestrazione e delega.

Apri principi

Usa il modello a tre layer in modo intenzionale

Ogni layer esiste per un tipo diverso di incertezza operativa. L'architettura migliora quando i team smettono di trattare la chat come entry point universale e fanno convergere tutti e tre i layer su un workflow engine condiviso supportato da stato, contesto, tool e monitoring.

Workflow guidati da trigger

Ideali per reazioni a eventi come messaggi in ingresso, cambi CRM, pagamenti falliti, escalation supporto o file caricati.

Persisti prima l'evento in ingresso

Progetta per idempotenza e retry

Mantieni ispezionabile la traccia di successo o fallimento

Workflow schedulati

Ideali per summarisation ricorrenti, report, pulizie, follow-up e task di manutenzione.

Rendi esplicite le finestre temporali

Persisti stato del job e strategia di retry

Esponi chiaramente run mancati e job stantii

Agenti interattivi

Ideali quando il sistema ha bisogno di chiarimenti, approvazioni o steering in tempo reale da un operatore umano.

Mantieni chiari i confini di delega

Esponi blocchi e stati di attesa

Rappresenta il lavoro come sistema, non solo come transcript

Spina dorsale workflow condivisa

Tutti e tre i layer dovrebbero convergere su un workflow engine capace di chiamare database, API esterne, AI runtime e monitoring mentre legge da un context hub versionato.

Persisti stato degli eventi e output nel database

Tratta MCP come parte dell'AI runtime e del layer tool, non come tutta l'architettura

Mantieni monitoring e tracce del context hub collegati a ogni run

Continua nel ramo runtime

Questo ramo e pensato come libreria coerente. Usa le altre guide per completare il modello operativo oltre il singolo topic.

Context Hubs

Caricamento del Contesto a Livelli

Uno dei modi piu rapidi per rendere un agente lento, costoso e meno affidabile e dargli troppo contesto troppo presto. Il caricamento a livelli trasforma la scoperta del contesto in un processo guidato, invece di lasciare il runtime davanti a un dump indistinto di file.

Runtime Safety

Delega Sicura a Runtime Pesanti

I sistemi agentici moderni combinano sempre piu spesso un agente leggero con pochi tool e un runtime piu pesante che puo navigare, usare shell, leggere file o operare in modo piu autonomo. La domanda di design non e solo se il sistema puo delegare, ma quando la delega e giustificata, come viene delimitata e come puo essere revisionata dopo.

Tutto dovrebbe partire come agente interattivo?

No. Molti task sono migliori come trigger o schedule. Gli agenti interattivi sono piu utili quando l'intento e ambiguo o l'utente deve guidare il lavoro.

Un sistema puo usare tutti e tre i layer?

Si. Nei sistemi maturi, trigger, schedule e agenti interattivi condividono spesso la stessa infrastruttura sottostante.

I trigger sono meno agentici?

Non necessariamente. Spesso sono semplicemente piu appropriati. Il comportamento agentico va usato dove migliora il risultato, non come wrapper di default.

Continua nel ramo runtime

Questo ramo e pensato come libreria coerente. Usa la landing runtime per ritrovare il quadro generale e continua verso i principi quando devi riallineare il modello operativo alla dottrina.

Torna alla landing Apri principi