Guida applicativaUX di guida

Tratta la correzione in corsa come un cambio di stato, non come un nuovo prompt.

Le UX restart-heavy distruggono il contesto e la fiducia costruita dall'agente fino a quel momento. Steering senza restart è un cambio di stato a livello di run, non un prompt all'inizio.

Di Michelangelo Zampogna · Pubblicata il 22 aprile 2026

Fatti chiave

Best fit: Workflow agentici multi-step con revisione umana, uso di tool o esecuzioni lunghe
Primary risk: Restart drift: lavoro valido perso quando una correzione forza il riavvio completo
Core shift: riavvia-e-riprompta -> guida in corsa con stato preservato
Success signal: Gli utenti reindirizzano esecuzioni attive senza perdere prove, approvazioni o output riutilizzabili
Doctrine mapping: P2, P7, P9, P10

Controllo durante l'esecuzione

Guidare senza riavviare e il pattern che trasforma il lavoro dell'agente da scambio fragile in chat a esecuzione operativa duratura. Invece di perdere prove, approvazioni e progresso parziale, la tua interfaccia permette alle persone di reindirizzare, restringere, mettere in pausa e correggere il lavoro mentre e in corso, mantenendo lo stato ispezionabile e i confini di rischio espliciti. Written by the AI Design Blueprint editorial team. Doctrine grounded in the 10 Blueprint Principles.

Tratta la correzione in corsa come un cambio di stato, non come un nuovo prompt.

Perché guidare senza riavviare conta oggi

Gli agenti non eseguono piu solo richieste istantanee: fanno ricerca, analisi e attivita multi-step che possono durare minuti o ore. Se ogni correzione costringe a ripartire da zero, perdi contesto, prove e fiducia, mentre P10 – Optimise for steering, not only initiating e P9 – Represent delegated work as a system, not merely as a conversation richiedono il contrario.

I flussi basati sul riavvio generano amnesia di contesto, costi duplicati e tracce di revisione piu deboli.

La guida in corsa diventa critica quando una run ha dipendenze, rami o completamento parziale; P2 – Ensure that background work remains perceptible.

Gli utenti devono capire cosa resta valido dopo la correzione, non solo inviare un prompt migliore; P7 – Establish trust through inspectability.

Perché l'approccio standard fallisce

Il pattern piu comune e una semplice correzione in chat: l'utente scrive "invece fai questo" e il sistema sovrascrive la run oppure la riavvia da capo. Questo fallisce perche l'interfaccia non ha un modello duraturo di stato, riuso e confini di approvazione, in violazione di P5 – Replace implied magic with clear mental models e P8 – Make hand-offs, approvals, and blockers explicit.

Failure mode: restart drift — la nuova run perde prove valide e produce un risultato diverso per motivi evitabili.

Failure mode: hidden branch loss — il lavoro precedente scompare e non si capisce cosa e stato riusato o scartato; P7 – Establish trust through inspectability.

Failure mode: silent risk escalation — una piccola correzione abilita nuovi tool, nuovi accessi o azioni esterne senza visibilita; P8 – Make hand-offs, approvals, and blockers explicit.

Failure mode: invisible background churn — l'agente continua a lavorare ma l'utente non capisce se e in pausa, in reindirizzamento o bloccato; P2 – Ensure that background work remains perceptible.

Come Blueprint sostituisce la correzione con riavvio

Blueprint sostituisce la correzione con riavvio con un modello di run persistente: l'utente guida un sistema attivo, non una conversazione usa e getta. La correzione diventa un checkpoint nominato, un obiettivo aggiornato o un ramo circoscritto con storia preservata, in linea con P9 – Represent delegated work as a system, not merely as a conversation e P10 – Optimise for steering, not only initiating.

Conserva il contesto accumulato come stato strutturato: obiettivi, prove, output dei tool, approvazioni, blocchi e lavoro residuo.

Mostra cosa cambia subito, cosa resta valido e cosa richiede revisione con linguaggio utile per l'utente; P6 – Expose meaningful operational state, not internal complexity.

Permetti di ispezionare il ragionamento superato senza affollare la vista di default; P4 – Apply progressive disclosure to system agency e P7 – Establish trust through inspectability.

Tratta il reindirizzamento come evento esplicito con scope prima/dopo, non come sostituzione nascosta del prompt; P5 – Replace implied magic with clear mental models.

Come implementare la guida senza riavvio

Il pattern di implementazione consiste nel salvare il lavoro separatamente dai turni di chat e nel trattare ogni intervento come un aggiornamento dello stato della run. La tua interfaccia dovrebbe supportare azioni di pausa, reindirizzamento, restringimento, riprioritizzazione e hand-off, mantenendo visibile l'attivita in background secondo P2 – Ensure that background work remains perceptible e P6 – Expose meaningful operational state, not internal complexity.

Modella i comandi di steering come eventi di primo livello: raffina lo scope, sostituisci un vincolo, marca una prova come non valida, metti in pausa l'agente o riprendi da un checkpoint.

Preserva gli artefatti attraverso la correzione: fonti recuperate, output dei tool, test e approvazioni gia ottenute; P7 – Establish trust through inspectability.

Chiedi conferma solo quando la nuova direzione cambia il rischio, genera effetti esterni o supera confini di policy; P8 – Make hand-offs, approvals, and blockers explicit.

Rappresenta la run come vista di sistema con stato, obiettivo corrente, lavoro completato, passi pendenti e rami riutilizzabili; P9 – Represent delegated work as a system, not merely as a conversation.

Brief di partenza

Task: Reindirizza la run corrente verso l'obiettivo rivisto senza riavviare
Scope: Riusa prove raccolte, output dei tool e passi gia approvati; non eliminare i rami precedenti
Escalate when: La nuova direzione cambia la policy, produce effetti esterni o richiede azioni soggette ad approvazione
Success signal: La run mostra un checkpoint di reindirizzamento etichettato, contesto preservato e prossimi passi aggiornati

Livelli di escalation e governance

Usa questi livelli per definire quali correzioni in corsa possono avvenire subito e quali richiedono un checkpoint esplicito o un approvatore, seguendo P8 – Make hand-offs, approvals, and blockers explicit e P10 – Optimise for steering, not only initiating.

Tier	Action type	Risk level	Required approval
Tier 1 — Autonomous	Steering reversibile come restringere lo scope, riordinare passi pendenti o estendere la ricerca entro confini gia approvati	Low	Pre-approvata all’avvio del task
Tier 2 — Confirmed steering	Modifiche a obiettivi, criteri di successo o priorita delle fonti che cambiano la run ma restano entro i limiti di policy	Medium	Single user confirmation
Tier 3 — Approval-gated intervention	Azioni esterne, modifiche distruttive, eccezioni di policy o eliminazione di rami e prove precedenti	High	Named approver before execution

Anti-pattern vs. pattern Blueprint

Confronta il tuo flusso di correzione con questi pattern per passare dalla sostituzione nascosta del prompt a una guida esplicita della run secondo P5 – Replace implied magic with clear mental models e P9 – Represent delegated work as a system, not merely as a conversation.

Anti-pattern: Riavviare l'intera run a ogni correzione
Pattern Blueprint: Preservare lo stato della run e applicare la correzione come aggiornamento con checkpoint e scope prima/dopo

Anti-pattern: Mostrare solo l'ultimo turno di chat come superficie di esecuzione
Pattern Blueprint: Usare una vista persistente della run con obiettivo corrente, lavoro completato, passi pendenti e blocker nominati

Anti-pattern: Sovrascrivere le prove precedenti quando l'utente cambia direzione
Pattern Blueprint: Conservare le prove, etichettare i rami superati e mostrare cosa resta riutilizzabile

Anti-pattern: Nascondere l'attivita dell'agente durante la correzione
Pattern Blueprint: Mantenere visibili gli stati di pausa, ripresa, reindirizzamento e blocco mentre il lavoro continua in background

Anti-pattern: Trattare tutti gli interventi come equivalenti
Pattern Blueprint: Separare steering reversibile e modifiche soggette ad approvazione con livelli di rischio espliciti

Prove dal mondo reale

Scenario illustrativo

Due tracce anonimizzate mostrano perche la guida in corsa richiede stato visibile e contesto preservato.

Un team di ricerca usava una board persistente per sintetizzare letteratura. L'agente aveva gia raccolto 42 fonti quando un revisore ha ristretto la domanda al solo contesto normativo UE. Il sistema ha mantenuto le prove precedenti, ha etichettato i risultati non UE come riutilizzabili ma fuori scope e ha ripreso dall'ultimo checkpoint. Il tempo di review e sceso perche non e stato necessario ripetere la ricerca.

Un team di design lavorava con task di componenti a contesto limitato per prototipare analytics. A meta sviluppo, un umano ha cambiato il criterio di successo da novita ad accessibilita. L'agente si e messo in pausa, ha mostrato quali moduli sarebbero cambiati, ha chiesto approvazione prima di eliminare un ramo e ha mantenuto i risultati di test dei componenti non toccati. Il team ha corretto la direzione nella stessa run invece di riscrivere tutto il brief.

Domande frequenti

Domande comuni per i team che adottano la guida senza riavvio.

Per quali casi d'uso funziona meglio guidare senza riavviare?

Funziona meglio quando il lavoro dell'agente accumula contesto nel tempo: ricerca, analisi, coding, workflow con tool e operazioni multi-step. Se la run raccoglie prove, usa strumenti o aspetta approvazioni, riavviare spreca lavoro valido e peggiora la tracciabilita.

Quando invece ha senso forzare un riavvio?

Ha senso quando la run originale e compromessa da assunzioni errate, permessi sbagliati, stato corrotto o attivita di tool non sicure. Vale anche quando la nuova richiesta e di fatto un task diverso, non una correzione della stessa esecuzione.

Come si preserva il contesto senza trascinarsi dietro gli errori?

Bisogna preservare gli artefatti, non la continuita cieca. Mantieni prove, output dei tool e checkpoint, ma etichetta in modo esplicito assunzioni invalide, rami superati e approvazioni ritirate, cosi il passo successivo riusa solo cio che resta affidabile.

Cosa dovrebbe mostrare l'interfaccia nel momento della correzione?

Dovrebbe mostrare lo stato corrente della run, cosa l'utente sta cambiando, cosa resta valido e cosa verra ricalcolato. In piu, il momento della correzione deve rendere visibili livello di rischio, richieste di approvazione e stato dell'agente: in pausa, in reindirizzamento o bloccato.

Come vanno gestite le approvazioni durante i cambi in corsa?

Le approvazioni dovrebbero dipendere dal tipo di azione, non dal semplice fatto che l'utente ha scritto una correzione. Lo steering reversibile e a basso rischio puo essere pre-approvato, mentre modifiche distruttive, effetti esterni o eccezioni di policy devono richiedere approvazione esplicita prima dell'esecuzione.

Una semplice interfaccia conversazionale puo supportare questo pattern?

Si, ma la conversazione da sola non basta. La chat puo raccogliere l'istruzione, mentre una vista persistente della run, un modello di stato e la storia dei checkpoint portano la logica di steering e rendono il tutto ispezionabile.

Come misurare se lo steering sta funzionando davvero?

Misura quante run vengono reindirizzate senza riavvio completo, quanta parte del lavoro precedente viene riutilizzata dopo la correzione e quante volte i confini di approvazione vengono rispettati. Conviene anche osservare velocita di review e fiducia dell'utente dopo i cambi in corsa, non solo il tasso di avvio dei task.

Checklist per iniziare

Definisci outcome del workflow, parametri steerabili e confine oltre il quale non si riavvia. P10 – Optimise for steering, not only initiating.
Salva checkpoint per obiettivi, prove, approvazioni e output dei tool. P7 – Establish trust through inspectability.
Separa correzioni reversibili e modifiche soggette ad approvazione. P8 – Make hand-offs, approvals, and blockers explicit.
Mostra stato corrente della run, stato di pausa, stato di reindirizzamento e stato di blocco con linguaggio comprensibile. P2 – Ensure that background work remains perceptible; P6 – Expose meaningful operational state, not internal complexity.
Conserva i rami superati invece di eliminarli, cosi l'utente puo riusare lavoro precedente. P9 – Represent delegated work as a system, not merely as a conversation.
Testa tre interventi: refine, redirect e stop-with-handoff. P10 – Optimise for steering, not only initiating.
Open Blueprint to validate your architecture.

Valida l'architettura

Prossimi passi

Se il tuo agente puo solo essere avviato ma non guidato, l'interfaccia e ancora progettata per l'inizio del task, non per il controllo del lavoro. Usa Blueprint per formalizzare stato della run, checkpoint e confini di approvazione, cosi la correzione in corsa diventa sicura, visibile ed efficiente secondo P10 – Optimise for steering, not only initiating e P8 – Make hand-offs, approvals, and blockers explicit.

Mappa un workflow esistente in cui oggi gli utenti riavviano dopo una correzione.

Ridisegna quel flusso attorno a stato persistente, checkpoint espliciti e blocker visibili.

Valida se la tua run view mostra abbastanza stato operativo per l'ispezione senza esporre complessita interna; P6 – Expose meaningful operational state, not internal complexity.

Principi di riferimento

Validate in Pro

Ottimizzare per la guida, non solo per l'inizio

Leggi →Complete Foundations

Rappresentare il lavoro delegato come un sistema, non solo come una conversazione

Leggi →