Workflow a più fasi come modo per ridurre il carico cognitivo

1. Che cos’è un workflow nel contesto di ChatGPT App

Bene, se vi siete districati con l’autenticazione, vi siete meritati un premio. Passiamo a un argomento molto interessante — il workflow in ChatGPT App. In generale la parola «workflow» a molti fa venire i flashback di diagrammi BPMN e di un cupo software aziendale. Tranquilli: nel contesto di ChatGPT App ci interessa una versione molto più leggera.

Nel nostro corso per workflow intendiamo uno scenario multi‑step, in cui:

• c’è un obiettivo chiaro (ad esempio, scegliere un regalo e arrivare all’acquisto),
• ci sono passi sequenziali (intervista → generazione di opzioni → affinamento → finale),
• in ogni passo ci sono ruoli propri per GPT, il widget e gli strumenti.

Punto importante: un workflow non è «un unico metodo nel server MCP». È una composizione:

• dei ragionamenti del modello (quali domande porre, quale strumento invocare),
• delle chiamate ai tools (MCP/Agents),
• dei passi di UI nel widget,
• dello stato nel backend.

Cioè non avete un unico «super‑strumento» solve_everything, ma diversi strumenti semplici che si attivano nelle diverse fasi. E non un «mega‑widget», ma un piccolo set di schermate/stati, ciascuno per il proprio sotto‑compito.

«Triangolo di responsabilità» nel workflow

È comodo pensare al workflow come a una danza di tre partecipanti:

Questi tre ruoli insieme realizzano lo stesso scenario ma a livelli diversi: GPT decide «cosa viene dopo», il widget mostra «cosa c’è adesso», MCP si occupa di ciò che realmente accade ai dati.

2. Esempio di workflow basato su GiftGenius

Prendiamo lo scenario già noto di GiftGenius — un assistente per scegliere i regali. Si può descrivere come una semplice procedura guidata lineare.

La sequenza dei passi può essere la seguente:

1. Raccogliere le informazioni di base sul destinatario.
2. Definire il budget e le limitazioni.
3. Generare e filtrare le idee regalo.
4. Mostrare i candidati, dare la possibilità di mettere like/nascondere.
5. Passare al checkout o salvare la selezione.

Lo stesso scenario può essere rappresentato come una piccola «macchina a stati»:

stateDiagram-v2
    [*] --> Profiling
    Profiling --> ProfilingDone: profilo compilato
    ProfilingDone --> Browsing: idee generate
    Browsing --> Refining: l’utente ha affinato i filtri
    Refining --> Browsing: lista aggiornata
    Browsing --> Checkout: regalo selezionato
    Checkout --> Success: ordine completato
    Success --> [*]

Qui:

• Profiling — passo di raccolta delle risposte sul destinatario,
• Browsing/Refining — lavoro con la lista dei candidati,
• Checkout — finalizzazione dell’ordine,
• Success — conferma finale.

Notate: nel diagramma non c’è alcun pulsante, nessun fetch. Si tratta proprio di passi logici, mentre le schermate UI, i tools e le chiamate API li agganciate voi sopra di essi.

3. Perché suddividere il compito in passi

Se avete mai creato un «questionario con 25 domande in un’unica schermata», già sapete perché. Ma suddividiamo tutto in fasi.

Carico cognitivo dell’utente

L’attenzione dell’essere umano è limitata. Gli psicologi amano ricordare la legge di Miller sui 7±2 elementi nella memoria a breve termine. In UX questo si traduce in una regola molto pratica: più campi e opzioni mostrate contemporaneamente, maggiore è la probabilità che l’utente si blocchi, si stanchi o chiuda la scheda.

Un modulo con 12 campi in un’unica schermata dentro un piccolo widget inline di ChatGPT — è praticamente un rage‑quit garantito: l’utente molla tutto e chiude la scheda. L’utente è venuto per «parlare», non per sostenere un esame.

Se invece dividete il compito in passi:

• «Passo 1 di 4: raccontateci della persona»,
• «Passo 2 di 4: scegliete il budget»,
• «Passo 3 di 4: guardate le opzioni»,
• «Passo 4 di 4: confermate la scelta»,

allora ogni momento concreto appare gestibile. Una barra di progresso o la didascalia dei passi dà una sensazione di controllo: è chiaro cosa sta succedendo e quanto manca.

Carico cognitivo del modello

Sorpresa: il modello ha un problema simile. Una LLM non è un essere umano, ma ha anch’essa un «focus» e una finestra di contesto limitati. Se chiedete a GPT in un solo passaggio di:

• scoprire tutto sul destinatario,
• definire il budget,
• considerare i dettagli della consegna,
• selezionare 10 opzioni,
• spiegare perché proprio quelle opzioni,

su ognuno di questi sotto‑punti il modello consuma una parte dell’attenzione e dei token. Più compiti non correlati in una singola richiesta, maggiore il rischio che una parte venga svolta superficialmente o con errori.

Se invece costruite una catena di passi — in sostanza il chain-of-thought esplicitato nell’interfaccia — prima il modello risolve il compito ristretto «estrarre il profilo», poi «correggere il budget», poi «selezionare i candidati». La qualità del ragionamento (reasoning) del modello in ogni fase è sensibilmente maggiore.

Manutenibilità e debug

Quando tutto è infilato in un unico strumento e in un’unica schermata, il debug diventa una quest: «E in quale punto esatto è iniziato ad andare male?»

In un workflow multi‑step ottenete quasi automaticamente:

• punti di logging: step_started, step_completed, step_failed,
• punti chiari per misurare la conversione (quante persone sono arrivate al passo 3),
• problemi localizzati: «si blocca solo nel passo di generazione delle idee».

Tutto ciò tornerà utile nel modulo sull’analitica dei workflow, ma già ora è utile abituarsi a pensare per passi.

4. Tipi di passi nel workflow e come appaiono nell’UI

Abbiamo già discusso perché suddividere il compito in passi. Ora organizziamo i passi stessi e vediamo quali «mattoncini» tipici si incontrano più spesso in una ChatGPT App. Per non scivolare in un insieme caotico di schermate, è utile avere una «libreria» di tipi di passi. Nella vostra App quasi sempre si ripeteranno alcuni pattern.

Ecco una tabella di base:

È importante ricordare: lo stesso passo logico può manifestarsi sia nell’UI sia in un dialogo testuale puro. Ad esempio, il passo «raccolta degli interessi» può essere:

• o un modulo con tag «sport», «giochi da tavolo», «cucina»,
• o una conversazione in cui GPT chiarisce con tatto: «E di cosa si interessa?».

Spesso la variante ottimale è ibrida: GPT pone la domanda, l’utente risponde con del testo e, contemporaneamente, può cliccare sui chip nel widget.

5. Chi «guida» il workflow: GPT, widget o server?

Viene spontaneo dire: «Ovviamente il widget, siamo frontendisti, controlliamo tutto tramite lo state». Ma nel mondo delle ChatGPT App non funziona così. Il workflow è un lavoro congiunto di tutti e tre i partecipanti.

GPT come orchestratore

GPT:

• conduce il dialogo, pone domande,
• decide quando un passo si può considerare concluso,
• sceglie quando invocare un tool (ad esempio, «è il momento di generare i regali»).

Per lui il vostro workflow appare come un insieme di sotto‑compiti. Nel system‑prompt potete descrivere quali sotto‑compiti ci sono e in quale ordine di solito eseguirli, lasciando comunque al modello la libertà di adattare un po’ la sequenza.

Esempio di mini‑istruzioni dentro il system‑prompt per GiftGenius (pseudocodice, senza sintassi esatta):

1. Prima chiarisci il profilo del destinatario (età, relazione, interessi).
2. Poi chiarisci il budget.
3. Quando i dati sono sufficienti — chiama lo strumento suggest_gifts.
4. Dopo aver ottenuto i candidati — aiuta l’utente a scegliere.

L’importante: GPT non conosce (e non deve conoscere) i dettagli dei vostri componenti React. Opera con i passi in termini di obiettivi: «raccogliere il profilo», «selezionare idee».

Il widget come «volto» del passo

Il widget:

• visualizza esattamente il passo attualmente rilevante,
• mantiene lo stato UI (card selezionata, tab aperta, campi locali del modulo),
• può mostrare un indicatore di avanzamento per i passi.

Una rappresentazione semplicissima dell’UI‑workflow in codice:

type GiftWorkflowStep =
  | "profiling"
  | "budget"
  | "candidates"
  | "checkout";

type GiftWidgetState = {
  step: GiftWorkflowStep;
  selectedGiftId?: string;
};

Dentro il widget React potete conservare questo stato o in un normale useState, oppure, se volete legarlo al ciclo di vita del widget in ChatGPT, usare useWidgetState dall’Apps SDK.

const [widgetState, setWidgetState] = useState<GiftWidgetState>({
  step: "profiling",
});

Le funzioni handler nel widget non «acquistano il regalo» direttamente, ma cambiano il passo e passano i dati necessari indietro al modello/backend.

MCP‑tools come «mani» del workflow

Il server MCP:

• conserva lo stato di business (profilo, cronologia delle scelte),
• valida i passi («non si può passare al Checkout se non c’è un regalo selezionato»),
• esegue il lavoro pesante: ricerca nel catalogo, calcolo prezzi, integrazione con ACP.

Per esempio, è logicamente più corretto che la decisione «quali regali mostrare» sia presa non nel widget, ma in un MCP‑tool suggest_gifts, in modo che il modello possa chiamarlo più volte durante gli affinamenti.

In questo modo ottenete una separazione:

• GPT — testo e sequenza,
• widget — rappresentazione visiva del passo corrente,
• MCP — dati e invarianti.

6. Come descrivere il workflow in codice: mini state‑machine

Ricordate il diagramma degli stati per GiftGenius all’inizio della lezione? Ora scriveremo la stessa logica sotto forma di semplici tipi e funzioni — una mini state‑machine in codice. Senza trasformare la vostra App in un corso teorico sugli automi finiti, un paio di tipi e funzioni semplici semplificano molto la vita.

Tipi di passi e configurazione

Iniziamo da una descrizione dichiarativa dei passi. Prendiamo il tipo già noto GiftWorkflowStep (lo ripetiamo qui per chiarezza) e definiamone la configurazione:

type GiftWorkflowStep =
  | "profiling"
  | "budget"
  | "candidates"
  | "checkout";

type StepConfig = {
  label: string;
  isFinal?: boolean;
};

export const GIFT_WORKFLOW_STEPS: Record<GiftWorkflowStep, StepConfig> = {
  profiling: { label: "Destinatario" },
  budget: { label: "Budget" },
  candidates: { label: "Opzioni" },
  checkout: { label: "Checkout", isFinal: true },
};

Ora possiamo aggiungere una semplice funzione di transizione:

export function getNextStep(
  current: GiftWorkflowStep
): GiftWorkflowStep | null {
  switch (current) {
    case "profiling":
      return "budget";
    case "budget":
      return "candidates";
    case "candidates":
      return "checkout";
    default:
      return null; // finale
  }
}

Questo vi dà già:

• un elenco centralizzato dei passi,
• regole di transizione esplicite,
• la possibilità di cambiare rapidamente ordine e logica.

Usarlo nel widget

La versione più semplice della «procedura guidata» nel vostro widget può apparire così:

function GiftWizard() {
  const [step, setStep] = useState<GiftWorkflowStep>("profiling");

  const handleStepComplete = () => {
    const next = getNextStep(step);
    if (next) setStep(next);
  };

  return (
    <div>
      <ProgressBar step={step} />
      <StepContent step={step} onComplete={handleStepComplete} />
    </div>
  );
}

Il componente StepContent sa renderizzare sottomoduli diversi a seconda del passo:

function StepContent(props: {
  step: GiftWorkflowStep;
  onComplete: () => void;
}) {
  const { step, onComplete } = props;

  if (step === "profiling") {
    return <ProfilingStep onNext={onComplete} />;
  }
  if (step === "budget") {
    return <BudgetStep onNext={onComplete} />;
  }
  if (step === "candidates") {
    return <CandidatesStep onNext={onComplete} />;
  }
  return <CheckoutStep />;
}

Notate: qui per ora non tocchiamo come GPT scelga il passo — è logica UI locale. In seguito potete sincronizzare questo step con lo stato server o con i messaggi dei tools, ma per capire la multi‑step va già bene così.

7. Evolvere l’app didattica: da «mega‑modulo» a procedura guidata

Immaginiamo che, prima di questa lezione, il vostro widget GiftGenius fosse un «modulo enorme»:

• nome del destinatario,
• età,
• interessi,
• budget,
• tipo di evento,
• checkbox «serve la consegna» e altri cinque campi,
• e in basso un grande pulsante «Scegli un regalo».

Per un prototipo spesso va bene, ma non appena volete uno scenario di prodotto — è ora di spezzare in passi.

Com’era «prima»

Esempio caricaturale:

// Antipattern: un unico modulo enorme
function GiftFormAllInOne() {
  return (
    <form>
      {/* 10+ campi mescolati */}
      {/* ... */}
      <button type="submit">Scegli un regalo</button>
    </form>
  );
}

Problemi tipici:

• l’utente non capisce quali campi siano obbligatori,
• non è chiaro quanto tempo occorrerà,
• è più difficile per GPT spiegare all’utente cosa è successo e fare follow‑up.

Come fare il «dopo»: procedura guidata in tre schermate

Passo 1 — separare profilo e budget:

function ProfilingStep(props: { onNext: () => void }) {
  const [recipientType, setRecipientType] = useState("");
  const [interests, setInterests] = useState<string[]>([]);

  const handleSubmit = () => {
    // qui si può chiamare il tool per salvare il profilo
    props.onNext();
  };

  return (
    <div>
      <h3>Per chi stiamo cercando un regalo?</h3>
      {/* coppie di radio / chip per tipo e interessi */}
      <button onClick={handleSubmit}>Avanti</button>
    </div>
  );
}

Passo 2 — budget:

function BudgetStep(props: { onNext: () => void }) {
  const [budget, setBudget] = useState<number | null>(null);

  const handleSubmit = () => {
    // si può chiamare un tool di validazione del budget
    props.onNext();
  };

  return (
    <div>
      <h3>Qual è il vostro budget?</h3>
      {/* slider o input */}
      <button onClick={handleSubmit} disabled={!budget}>
        Mostra opzioni
      </button>
    </div>
  );
}

Passo 3 — lista dei candidati:

function CandidatesStep(props: { onNext: () => void }) {
  const [selectedId, setSelectedId] = useState<string | null>(null);

  // qui mostrate le card dei regali
  // e permettete di selezionarne una

  return (
    <div>
      <h3>Scegliete l'opzione adatta</h3>
      {/* card con onClick = setSelectedId */}
      <button onClick={props.onNext} disabled={!selectedId}>
        Passa al checkout
      </button>
    </div>
  );
}

Sì, il codice è un po’ più lungo, ma la logica è più semplice:

• ogni passo risolve un piccolo compito,
• il modello può commentare separatamente i passaggi tra i passi,
• potete fare logging/misurare ogni passo separatamente.

8. Antipattern: come non trasformare il workflow in un mostro

La pratica e l’osservazione di App simili mostrano diversi errori tipici da evitare.

Primo, non cercate di «disegnare tutto» con un complicato diagramma BPMN con 30 stati, 40 frecce e un poster in formato A0. Nel contesto di una ChatGPT App è più importante una scala di passi intuitiva che una notazione formale. Bastano diagrammi come quello che abbiamo disegnato per GiftGenius.

Secondo, non trasformate l’App in un unico modulo enorme, soprattutto dentro un widget inline. L’utente è già in chat; aggiungere un blocco UI denso deve ridurre, non aumentare, il carico. Se vi trovate a pensare «qui ci sono 12 campi, ma sono tutti importanti» — quasi sempre è un segnale che il compito va spezzato.

Terzo, non create passi «per bellezza». Ogni passo deve avere un obiettivo chiaro: o raccogliere dati, o restringere la scelta, o far confermare qualcosa all’utente. Una schermata vuota tipo «ancora un po’ e abbiamo finito» con un solo pulsante «avanti» raramente aiuta.

Infine, non cercate di mostrare tutte le possibilità dell’App nei primi passi. Dettagli come «filtri avanzati», «condizioni di consegna particolari» si possono aggiungere come passi extra solo per chi ne ha realmente bisogno.

9. Un semplice esercizio di progettazione del workflow

Per fissare meglio il materiale, provate su carta (o in IDE, ma senza codice) a fare quanto segue.

Prendete un compito. Può essere:

• scelta di un regalo (GiftGenius),
• prenotazione di un viaggio,
• creazione di un piano di studio per qualcosa.

Dividetelo in 3–5 passi. Per ogni passo descrivete:

• l’obiettivo: cosa deve essere noto/fatto dopo questo passo,
• il formato: cosa è più opportuno qui — solo testo da GPT, widget, o combinazione.

Per esempio, per un semplice «piano di studio TypeScript»:

1. Passo «Valutazione del livello» — dialogo (GPT fa un paio di domande) + breve modulo di auto‑valutazione.
2. Passo «Obiettivi» — discussione testuale + checkbox degli obiettivi nel widget.
3. Passo «Piano» — generazione del piano (elenco) + pulsanti «più difficile/più semplice».
4. Passo «Conferma» — breve riepilogo e pulsante «salva il piano».

Provate poi a ipotizzare quali tools potrebbero essere coinvolti in ogni passo, ma senza scendere nei dettagli: strumenti, loro attivazione/disattivazione e conservazione dello stato — sono temi delle prossime lezioni di questo modulo.

10. Errori tipici nel lavoro con workflow multi‑step

Errore n. 1: tentare di risolvere tutto con un solo passo e un solo tool.
È molto allettante creare un «grande strumento intelligente» che interroga, analizza, seleziona e conclude l’acquisto da solo. In pratica peggiora sia l’UX (una schermata pesante), sia la qualità del ragionamento del modello (reasoning) — troppe responsabilità in una sola chiamata. È più semplice, affidabile ed economico in manutenzione suddividere il compito in una catena di 3–5 passi semplici.

Errore n. 2: passi impliciti, nascosti nella testa dello sviluppatore.
A volte nel codice sembra esserci una sequenza di azioni, ma non è descritta esplicitamente da nessuna parte: non ci sono tipi di passi, non c’è configurazione, non c’è diagramma. Di conseguenza nessuno nel team sa rispondere chiaramente «cosa accade in questa App dall’inizio alla fine». Una descrizione dichiarativa minima dei passi e delle transizioni fa risparmiare ore di debug.

Errore n. 3: mescolare passi UI e logica di business.
Se la logica delle transizioni tra i passi è incastonata in profondità nei componenti React (in stile if (isValid && hasBudget && !needsShipping) nell’onClick del pulsante), diventa difficile riutilizzarla e testarla. Meglio avere una «macchina a stati» relativamente esplicita o almeno funzioni come getNextStep, e lasciare all’UI il compito di chiamarla e visualizzarne il risultato.

Errore n. 4: ignorare il ruolo di GPT come orchestratore.
Capita che lo sviluppatore cerchi di controllare completamente lo scenario dal widget: «chiedo io tutto ciò che serve, il modello selezioni soltanto». Il risultato è che ChatGPT smette di sembrare un assistente vivo e diventa un motore di calcolo sotto un modulo. È molto meglio quando GPT comunica attivamente, spinge verso il passo successivo e avvia lui stesso le chiamate ai tools — e voi lo aiutate col design dei passi e con le istruzioni.

Errore n. 5: passi senza obiettivo chiaro.
A volte nella procedura guidata compaiono passi «in più» — onestamente, solo perché così è più bello. L’utente vede «Passo 2 di 5», ma in quel passo non gli viene richiesto nulla e non accade niente. Queste schermate vuote aumentano solo la percezione di complessità. Se un passo non si può formulare come «dopo di esso sappiamo sicuramente X» o «dopo di esso l’utente ha fatto Y» — probabilmente non serve.

Errore n. 6: progresso dimenticato e assenza di senso del percorso.
La multi‑step senza supporto visivo si trasforma in una scatola nera: l’utente non capisce dove si trovi e quanto manchi. Anche un semplice indicatore testuale «Passo 2 di 4» o un elenco orizzontale dei passi nell’header del widget riduce sensibilmente l’ansia. Ignorare questo effetto è uno dei motivi per cui le persone «abbandonano» a metà dello scenario, anche se lì la complessità reale potrebbe non esserci.