Guida al prompting

Introduzione

Un prompting efficace trasforma ElevenLabs Agents da robotici a realistici.

Un prompt di sistema è il progetto della personalità e delle policy del tuo agente IA. In ambito aziendale, tende a essere articolato: definisce il ruolo dell’agente, gli obiettivi, gli strumenti consentiti, istruzioni passo passo per determinate attività e guardrail che descrivono ciò che l’agente non deve fare. Il modo in cui strutturi questo prompt influisce direttamente sull’affidabilità.

Fondamenti del prompt engineering

Un system prompt definisce la personalità e le policy del tuo agente IA. In ambito enterprise, tende a essere articolato: definisce il ruolo dell’agente, i suoi obiettivi, gli strumenti utilizzabili, istruzioni dettagliate per determinate attività e guardrail che descrivono cosa l’agente non deve fare. Il modo in cui strutturi questo prompt influisce direttamente sull’affidabilità.

I seguenti principi sono alla base di un prompt engineering adatto alla produzione:

Separa le istruzioni in sezioni chiare

Separare le istruzioni in sezioni dedicate con titoli Markdown aiuta il modello a definirne correttamente le priorità e a interpretarle. Usa spazi vuoti e interruzioni di riga per separare le istruzioni.

Perché è importante per l’affidabilità: I modelli sono ottimizzati per prestare particolare attenzione a determinati titoli, soprattutto # Guardrails, e confini chiari tra le sezioni evitano la contaminazione delle istruzioni, in cui le regole di un contesto influenzano un altro.

You are a customer service agent. Be polite and helpful. Never share sensitive data. You can look up orders and process refunds. Always verify identity first. Keep responses under 3 sentences unless the user asks for details.

Sii il più conciso possibile

Mantieni ogni istruzione breve, chiara e orientata all’azione. Elimina le parole superflue e ripeti solo ciò che è essenziale affinché il modello agisca correttamente.

Perché è importante per l’affidabilità: Le istruzioni concise riducono l’ambiguità e l’uso di token. Ogni parola non necessaria è una potenziale fonte di interpretazioni errate.

# Tone
When you're talking to customers, you should try to be really friendly and approachable, making sure that you're speaking in a way that feels natural and conversational, kind of like how you'd talk to a friend, but still maintaining a professional demeanor that represents the company well.

Enfatizza le istruzioni critiche

Evidenzia i passaggi critici aggiungendo “Questo passaggio è importante” alla fine della riga. Ripetere due volte nel prompt le 1-2 istruzioni più importanti può contribuire a rafforzarle.

Perché è importante per l’affidabilità: Nei prompt complessi, i modelli potrebbero dare priorità al contesto più recente rispetto alle istruzioni precedenti. Enfasi e ripetizione fanno sì che le regole critiche non vengano trascurate.

# Goal
Verify customer identity before accessing their account.
Look up order details and provide status updates.
Process refund requests when eligible.

Normalizzazione del testo

I modelli Text to Speech, soprattutto quelli più veloci, generano al meglio il parlato a partire da testo alfabetico. Di conseguenza, cifre e simboli come ”@” o ”£” hanno maggiori probabilità di causare pronunce errate o allucinazioni vocali.

Per risolvere questo problema, normalizziamo il testo non alfabetico trasformandolo in parole prima che raggiunga il modello TTS (ad esempio, 123 -> one-hundred and twenty three, john@gmail.com -> john at gmail dot com) e ti permettiamo di scegliere tra diverse strategie di normalizzazione con compromessi differenti.

Strategie di normalizzazione

Supportiamo due strategie di normalizzazione tramite la configurazione dell’agente text_normalisation_type:

system_prompt (predefinita) — Aggiunge al system prompt istruzioni che indicano all’LLM di scrivere numeri e simboli in lettere prima che il testo raggiunga il modello TTS.

• Nessuna latenza aggiuntiva
• Gli LLM potrebbero occasionalmente non normalizzare correttamente il testo
• Le trascrizioni riportano tutto scritto in lettere (ad esempio, “mille dollari” invece di “$1,000”)

elevenlabs — Usa il nostro normalizzatore TTS per normalizzare il testo dopo la generazione dell’LLM e prima che raggiunga il modello TTS.

• Più affidabile della normalizzazione basata su LLM
• Il system prompt non viene modificato
• Le trascrizioni mantengono una formattazione naturale con simboli e numeri (ad esempio, “$1,000”)
• Aggiunge una latenza minima

Trovi questa configurazione nella nostra piattaforma nella scheda “Agent”: fai clic sull’icona a ingranaggio nella sezione “Voices” per aprire il pannello delle impostazioni vocali comuni, quindi configuralo in fondo.

Dati strutturati per gli input degli strumenti

Quando usi l’impostazione di normalizzazione system_prompt, l’LLM scrive simboli e numeri in lettere nelle sue risposte (ad esempio, john at gmail dot com invece di john@gmail.com). Anche le trascrizioni degli utenti da Speech to Text possono arrivare in una forma non standard. Ciò significa che, quando utilizza questi dettagli come parametri nelle chiamate degli strumenti, l’LLM potrebbe usare la versione non strutturata presente nel contesto della conversazione.

Se un parametro dello strumento richiede un valore formattato correttamente, ad esempio john@gmail.com e non john at gmail dot com, l’LLM deve saperlo. Includi il formato previsto direttamente nella descrizione del parametro dello strumento, con un esempio.

## `lookupAccount` tool parameters
- `email` (required): "The user's email."
- `phone` (required): "The user's phone number."
- `confirmation_code` (required): "The user's confirmation code."

Dedica una sezione ai guardrail

Elenca tutte le regole non negoziabili che il modello deve sempre seguire in una sezione dedicata # Guardrails. I modelli sono ottimizzati per prestare particolare attenzione a questo titolo.

Perché è importante per l’affidabilità: I guardrail prevengono risposte inappropriate e garantiscono la conformità alle policy. Centralizzarli in una sezione dedicata rende più semplice verificarli e aggiornarli.

# Guardrails
Never share customer data across conversations or reveal sensitive account information without proper verification.
Never process refunds over $500 without supervisor approval.
Never make promises about delivery dates that aren't confirmed in the order system.
Acknowledge when you don't know an answer instead of guessing.
If a customer becomes abusive, politely end the conversation and offer to escalate to a supervisor.

Per scoprire di più su come progettare guardrail efficaci, consulta la nostra guida sui Guardrail.

Configurazione degli strumenti per l’affidabilità

Gli agenti in grado di gestire workflow transazionali possono essere molto efficaci. Per farlo, devono essere dotati di strumenti che consentano loro di eseguire azioni in altri sistemi o di recuperarne dati in tempo reale.

La descrizione degli strumenti disponibili per il tuo agente è importante quanto la struttura del prompt. Definizioni chiare e orientate all’azione aiutano il modello a invocarli correttamente e a gestire gli errori senza problemi.

Descrivi gli strumenti in modo preciso con parametri dettagliati

Quando crei uno strumento, aggiungi descrizioni a tutti i parametri. Questo aiuta l’LLM a costruire chiamate allo strumento accurate.

Descrizione dello strumento: “Cerca lo stato dell’ordine del cliente tramite ID ordine e restituisce lo stato attuale, la data di consegna stimata e il numero di tracciamento.”

Descrizioni dei parametri:

• order_id (obbligatorio): “L’identificatore univoco dell’ordine, formattato con caratteri scritti (ad esempio, ‘ORD123456’)”
• include_history (facoltativo): “Se true, restituisce la cronologia completa dell’ordine, incluse le modifiche di stato”

Perché è importante per l’affidabilità: Le descrizioni dei parametri fungono da documentazione inline per il modello. Chiariscono le aspettative sul formato, i campi obbligatori e facoltativi e i valori accettabili.

Spiega nel system prompt quando e come usare ciascuno strumento

Definisci chiaramente nel system prompt quando e come usare ciascuno strumento. Non affidarti esclusivamente alle descrizioni degli strumenti: fornisci il contesto d’uso e la logica di sequenza.

# Tools
You have access to the following tools:
## `getOrderStatus`
Use this tool when a customer asks about their order. Always call this tool before providing order information—never rely on memory or assumptions.
**When to use:**
- Customer asks "Where is my order?"
- Customer provides an order number
- Customer asks about delivery estimates
**How to use:**
1. Collect the order ID from the customer
2. Call `getOrderStatus` with the order ID
3. Present the results to the customer in natural language
**Error handling:**
If the tool returns "Order not found", ask the customer to verify the order number and try again.
## `processRefund`
Use this tool only after verifying:
1. Customer identity has been confirmed
2. Order is eligible for refund (within 30 days, not already refunded)
3. Refund amount is under $500 (escalate to supervisor if over $500)
**Required before calling:**
- Order ID (from `getOrderStatus`)
- Refund reason code
- Customer confirmation
This step is important: Always confirm refund details with the customer before calling this tool.

Specifica i formati previsti nelle descrizioni dei parametri degli strumenti

Quando gli strumenti richiedono identificatori strutturati, come email, numeri di telefono o codici, rendi esplicito il formato previsto nella descrizione del parametro con un esempio. Questo è particolarmente importante perché la normalizzazione e la trascrizione Speech to Text possono produrre valori in forma parlata nel contesto della conversazione. Consulta dati strutturati per gli input degli strumenti per ulteriori informazioni.

## `lookupAccount` tool parameters
- `email` (required): "The customer's email address."

Gestisci correttamente gli errori nelle chiamate degli strumenti

Gli strumenti possono talvolta non funzionare a causa di problemi di rete, dati mancanti o altri errori. Includi istruzioni chiare nel system prompt per il ripristino.

Perché è importante per l’affidabilità: In produzione, gli errori degli strumenti sono inevitabili. Senza istruzioni di gestione esplicite, gli agenti potrebbero allucinare risposte o fornire informazioni errate.

# Tool error handling
If any tool call fails or returns an error:
1. Acknowledge the issue to the customer: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer alternatives:
   - Try the tool again if it might be a temporary issue
   - Offer to escalate to a human agent
   - Provide a callback option
4. If the error persists after 2 attempts, escalate to a supervisor
**Example responses:**
- "I'm having trouble looking up that order right now. Let me try again... [retry]"
- "I'm unable to access the order system at the moment. I can transfer you to a specialist who can help, or we can schedule a callback. Which would you prefer?"

Per indicazioni dettagliate su come creare integrazioni di strumenti affidabili, consulta la documentazione sugli strumenti client, sugli strumenti webhook e sugli strumenti MCP.

Pattern architetturali per agenti enterprise

Sebbene prompt e strumenti efficaci siano alla base dell’affidabilità degli agenti, i sistemi in produzione richiedono una progettazione architetturale accurata. Gli agenti enterprise gestiscono workflow complessi che spesso superano la portata di un singolo prompt monolitico.

Mantieni gli agenti specializzati

Istruzioni troppo ampie o finestre di contesto estese aumentano la latenza e riducono l’accuratezza. Ogni agente deve avere una knowledge base circoscritta e ben definita, oltre a un insieme chiaro di responsabilità.

Perché è importante per l’affidabilità: Gli agenti specializzati hanno meno casi limite da gestire, criteri di successo più chiari e tempi di risposta più rapidi. Sono più facili da testare, sottoporre a debug e migliorare.

Usa pattern con orchestratore e specialisti

Per attività complesse, progetta workflow multi-agente che trasferiscano le attività tra agenti specializzati e, quando necessario, a operatori umani.

Pattern architetturale:

1. Agente orchestratore: Indirizza le richieste in arrivo agli agenti specialisti appropriati in base alla classificazione dell’intento
2. Agenti specialisti: Gestiscono attività specifiche del dominio, come fatturazione, pianificazione, supporto tecnico e altro
3. Escalation a un operatore umano: Criteri di trasferimento definiti per i casi complessi o sensibili

Vantaggi di questo pattern:

• Ogni specialista ha un prompt mirato e un contesto ridotto
• È più facile aggiornare i singoli specialisti senza influire sul sistema
• Metriche chiare per dominio, come tasso di risoluzione della fatturazione e tasso di successo della pianificazione
• Latenza ridotta per interazione, grazie a prompt più piccoli e inferenza più rapida

Definisci criteri di trasferimento chiari

Quando progetti workflow multi-agente, specifica esattamente quando e come il controllo deve passare tra gli agenti o agli operatori umani.

# Goal
Route customer requests to the appropriate specialist agent based on intent.
## Routing logic
**Billing specialist:** Customer mentions payment, invoice, refund, charge, subscription, or account balance
**Technical support specialist:** Customer reports error, bug, issue, not working, broken
**Scheduling specialist:** Customer wants to book, reschedule, cancel, or check appointment
**Human escalation:** Customer is angry, requests supervisor, or issue is unresolved after 2 specialist attempts
## Handoff process
1. Classify customer intent based on first message
2. Provide brief acknowledgment: "I'll connect you with our [billing/technical/scheduling] team."
3. Transfer conversation with context summary:
   - Customer name
   - Primary issue
   - Any account identifiers already collected
4. Do not repeat information collection that already occurred

# Personality
You are a billing specialist for Acme Corp. You handle payment issues, refunds, and subscription changes.
# Goal
Resolve billing inquiries by:
1. Verifying customer identity
2. Looking up account and billing history
3. Processing refunds (under $500) or escalating (over $500)
4. Updating subscription settings when requested
# Guardrails
Never access account information without identity verification.
Never process refunds over $500 without supervisor approval.
If the customer's issue is not billing-related, transfer back to the orchestrator agent.

Per indicazioni dettagliate su come creare workflow multi-agente, consulta la documentazione sui Workflow.

Selezione del modello per l’affidabilità enterprise

La scelta del modello giusto dipende dai tuoi requisiti di prestazioni, in particolare latenza, accuratezza e affidabilità nelle chiamate degli strumenti. I diversi modelli offrono compromessi diversi tra velocità, capacità di ragionamento e costo.

Comprendi i compromessi

Latenza: I modelli più piccoli, con meno parametri, rispondono generalmente più velocemente, quindi sono adatti a interazioni frequenti e poco complesse.

Accuratezza: I modelli più grandi offrono capacità di ragionamento più solide e gestiscono meglio attività complesse in più passaggi, ma con latenza e costi maggiori.

Affidabilità nelle chiamate degli strumenti: Non tutti i modelli gestiscono le chiamate a strumenti o funzioni con la stessa precisione. Alcuni eccellono nell’output strutturato, mentre altri potrebbero richiedere prompt più espliciti.

Modelli consigliati per caso d’uso

In base alle distribuzioni su milioni di interazioni degli agenti, emergono i seguenti pattern:

• GLM 5.2 o GPT-6 Luna (punto di partenza consigliato): Ideali per agenti enterprise generici in cui latenza, accuratezza e costo devono essere bilanciati. Offrono una latenza da bassa a moderata, ottime prestazioni nelle chiamate degli strumenti e un costo ragionevole per interazione. Ideali per assistenza clienti, pianificazione, gestione degli ordini e gestione di richieste generiche.

• DeepSeek Flash 4.1 o Gemini 3.5 Flash-Lite (latenza ultra-bassa): Ideali per interazioni frequenti e semplici, in cui la velocità è fondamentale. Offrono la latenza più bassa con un’ampia conoscenza generale, anche se con prestazioni inferiori nelle chiamate a strumenti complessi. Convenienti su larga scala per instradamento e triage iniziali, FAQ semplici, conferme di appuntamenti e raccolta dati di base.

• Claude Sonnet 5.5 (ragionamento complesso): Ideale per la risoluzione di problemi in più passaggi, valutazioni articolate e orchestrazione complessa degli strumenti. Offre la massima accuratezza e capacità di ragionamento, con un’eccellente affidabilità nelle chiamate degli strumenti, ma con latenza e costi maggiori. Ideale per attività in cui gli errori sono costosi, come risoluzione di problemi tecnici, consulenza finanziaria, workflow sensibili alla conformità e decisioni complesse su rimborsi o escalation.

Le offerte dei provider di modelli cambiano frequentemente. Prima di scegliere un modello per la produzione, verifica le opzioni e i prezzi attuali nella pagina Modelli.

Esegui benchmark con i tuoi prompt effettivi

Le prestazioni dei modelli variano significativamente in base alla struttura del prompt e alla complessità dell’attività. Prima di scegliere un modello:

1. Testa 2-3 modelli candidati con il tuo system prompt effettivo
2. Valutali su query di utenti reali o casi di test sintetici
3. Misura latenza, accuratezza e tasso di successo delle chiamate degli strumenti
4. Ottimizza in base al miglior compromesso per i tuoi requisiti specifici

Per opzioni dettagliate di configurazione dei modelli, consulta la nostra documentazione sui modelli.

Iterazione e test

L’affidabilità in produzione deriva dall’iterazione continua. Anche prompt ben costruiti possono fallire nell’uso reale. Ciò che conta è imparare da questi fallimenti e migliorare tramite test rigorosi.

Configura i criteri di valutazione

Associa criteri di valutazione concreti a ogni agente per monitorarne il successo nel tempo e verificare eventuali regressioni.

Metriche chiave da monitorare:

• Tasso di completamento delle attività: Percentuale di intenti degli utenti gestiti con successo
• Tasso di escalation: Percentuale di conversazioni che richiedono l’intervento umano

Per indicazioni dettagliate sulla configurazione dei criteri di valutazione in ElevenLabs, consulta Valutazione del successo.

Analizza i pattern di errore

Quando gli agenti non offrono le prestazioni previste, individua i pattern nelle interazioni problematiche:

• Dove l’agente fornisce informazioni errate? → Rafforza le istruzioni nelle sezioni specifiche
• Quando non riesce a comprendere l’intento dell’utente? → Aggiungi esempi o semplifica il linguaggio
• Quali input degli utenti lo fanno uscire dal personaggio? → Aggiungi guardrail per i casi limite
• Quali strumenti falliscono più spesso? → Migliora la gestione degli errori o le descrizioni dei parametri

Esamina le trascrizioni delle conversazioni in cui la soddisfazione degli utenti è stata bassa o le attività non sono state completate.

Apporta miglioramenti mirati

Aggiorna sezioni specifiche del prompt per risolvere i problemi individuati:

1. Isola il problema: Individua quale sezione del prompt o definizione dello strumento causa gli errori
2. Testa le modifiche su esempi specifici: Usa come casi di test le conversazioni che in precedenza non hanno funzionato
3. Apporta una modifica alla volta: Isola i miglioramenti per capire cosa funziona
4. Rivaluta con gli stessi casi di test: Verifica che la modifica abbia risolto il problema senza crearne di nuovi

Configura la raccolta dati

Configura il tuo agente affinché riassuma i dati di ogni conversazione. In questo modo puoi analizzare i pattern di interazione, individuare le richieste più comuni degli utenti e migliorare continuamente il prompt in base all’uso reale.

Per indicazioni dettagliate sulla configurazione della raccolta dati in ElevenLabs, consulta Raccolta dati.

Usa la simulazione per i test di regressione

Prima di distribuire in produzione le modifiche al prompt, esegui test su una serie di scenari noti per individuare le regressioni.

Per indicazioni su come testare gli agenti a livello programmatico, consulta Simulare conversazioni.

Considerazioni per la produzione

Gli agenti enterprise richiedono misure di protezione aggiuntive oltre alla qualità del prompt. Le distribuzioni in produzione devono tenere conto della gestione degli errori, della conformità normativa e di un degrado graduale.

Gestisci gli errori in tutte le integrazioni degli strumenti

Ogni chiamata a uno strumento esterno è un potenziale punto di errore. Assicurati che il prompt includa una gestione esplicita degli errori per:

• Errori di rete: “Ho difficoltà a connettermi al nostro sistema. Riprovo.”
• Dati mancanti: “Non vedo queste informazioni nel nostro sistema. Puoi verificare i dettagli?”
• Errori di timeout: “Sta richiedendo più tempo del previsto. Posso inoltrare la richiesta a uno specialista o riprovare.”
• Errori di autorizzazione: “Non ho accesso a queste informazioni. Ti trasferisco a qualcuno che può aiutarti.”

Esempi di prompt

Gli esempi seguenti mostrano come applicare i principi descritti in questa guida a casi d’uso enterprise reali. Ogni esempio include annotazioni che evidenziano i principi di affidabilità utilizzati.

Esempio 1: Agente di supporto tecnico

# Personality
You are a technical support specialist for CloudTech, a B2B SaaS platform.
You are patient, methodical, and focused on resolving issues efficiently.
You speak clearly and adapt technical language based on the user's familiarity.
# Environment
You are assisting customers via phone support.
Customers may be experiencing service disruptions and could be frustrated.
You have access to diagnostic tools and the customer account database.
# Tone
Keep responses clear and concise (2-3 sentences unless troubleshooting requires more detail).
Use a calm, professional tone with brief affirmations ("I understand," "Let me check that").
Adapt technical depth based on customer responses.
Check for understanding after complex steps: "Does that make sense?"
# Goal
Resolve technical issues through structured troubleshooting:
1. Verify customer identity using email and account ID
2. Identify affected service and severity level
3. Run diagnostics using `runSystemDiagnostic` tool
4. Provide step-by-step resolution or escalate if unresolved after 2 attempts
This step is important: Always run diagnostics before suggesting solutions.
# Guardrails
Never access customer accounts without identity verification. This step is important.
Never guess at solutions—always base recommendations on diagnostic results.
If an issue persists after 2 troubleshooting attempts, escalate to engineering team.
Acknowledge when you don't know the answer instead of speculating.
# Tools
## `verifyCustomerIdentity`
**When to use:** At the start of every conversation before accessing account data
**Parameters:**
- `email` (required): Customer email in standard written format (e.g., "user@company.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.
- `account_id` (optional): Account ID if customer provides it
**Error handling:**
If verification fails, ask customer to confirm email spelling and try again.
## `runSystemDiagnostic`
**When to use:** After verifying identity and understanding the reported issue
**Parameters:**
- `account_id` (required): From `verifyCustomerIdentity` response
- `service_name` (required): Name of affected service (e.g., "api", "dashboard", "storage")
**Usage:**
1. Confirm which service is affected
2. Run diagnostic with account ID and service name
3. Review results before providing solution
**Error handling:**
If diagnostic fails, acknowledge the issue: "I'm having trouble running that diagnostic. Let me escalate to our engineering team."
# Error handling
If any tool call fails:
1. Acknowledge: "I'm having trouble accessing that information right now."
2. Do not guess or make up information
3. Offer to retry once, then escalate if failure persists

Principi mostrati:

• ✓ Separazione chiara delle sezioni (# Personality, # Goal, # Tools e così via)
• ✓ Un’azione per riga (vedi i passaggi numerati in # Goal)
• ✓ Istruzioni concise (la sezione sul tono è breve e chiara)
• ✓ Passaggi critici enfatizzati (“Questo passaggio è importante”)
• ✓ Conversione del formato nelle descrizioni dei parametri (normalizzazione delle email)
• ✓ Sezione dedicata ai guardrail
• ✓ Descrizioni precise degli strumenti con indicazioni su quando, come e in caso di errore
• ✓ Istruzioni esplicite per la gestione degli errori

Esempio 2: Agente del servizio clienti per i rimborsi

# Personality
You are a refund specialist for RetailCo.
You are empathetic, solution-oriented, and efficient.
You balance customer satisfaction with company policy compliance.
# Goal
Process refund requests through this workflow:
1. Verify customer identity using order number and email
2. Look up order details with `getOrderDetails` tool
3. Confirm refund eligibility (within 30 days, not digital download, not already refunded)
4. For refunds under $100: Process immediately with `processRefund` tool
5. For refunds $100-$500: Apply secondary verification, then process
6. For refunds over $500: Escalate to supervisor with case summary
This step is important: Never process refunds without verifying eligibility first.
# Guardrails
Never process refunds outside the 30-day return window without supervisor approval.
Never process refunds over $500 without supervisor approval. This step is important.
Never access order information without verifying customer identity.
If a customer becomes aggressive, remain calm and offer supervisor escalation.
# Tools
## `verifyIdentity`
**When to use:** At the start of every conversation
**Parameters:**
- `order_id` (required): Order ID in uppercase alphanumeric format (e.g., "ORD123456"). Convert from spoken format: spell out letters and spoken digits to written form, no spaces.
- `email` (required): Customer email in standard written format (e.g., "john.smith@retailco.com"). Convert from spoken format: "at" → "@", "dot" → ".", remove spaces between words.
## `getOrderDetails`
**When to use:** After identity verification
**Returns:** Order date, items, total amount, refund eligibility status
**Error handling:**
If order not found, ask customer to verify order number and try again.
## `processRefund`
**When to use:** Only after confirming eligibility
**Required checks before calling:**
- Identity verified
- Order is within 30 days
- Order is eligible (not digital, not already refunded)
- Refund amount is under $500
**Parameters:**
- `order_id` (required): From previous verification
- `reason_code` (required): One of "defective", "wrong_item", "late_delivery", "changed_mind"
**Usage:**
1. Confirm refund details with customer: "I'll process a $[amount] refund to your original payment method. It will appear in 3-5 business days. Does that work for you?"
2. Wait for customer confirmation
3. Call this tool
**Error handling:**
If refund processing fails, apologize and escalate: "I'm unable to process that refund right now. Let me escalate to a supervisor who can help."

Principi mostrati:

• ✓ Ambito dell’agente specializzato (solo rimborsi, non supporto generale)
• ✓ Passaggi del workflow chiari nella sezione # Goal
• ✓ Enfasi ripetuta sulle regole critiche (limiti dei rimborsi, verifica)
• ✓ Uso dettagliato degli strumenti con “quando usarlo” e “controlli obbligatori”
• ✓ Conversione del formato nelle descrizioni dei parametri (ID ordine, email)
• ✓ Gestione esplicita degli errori per ogni strumento
• ✓ Criteri di escalation definiti chiaramente

Best practice di formattazione

Il modo in cui formatti il prompt influisce sull’efficacia con cui il modello linguistico lo interpreta:

• Usa titoli Markdown: Struttura le sezioni con # per le sezioni principali e ## per le sottosezioni
• Preferisci gli elenchi puntati: Suddividi le istruzioni in punti elenco facili da assimilare
• Usa gli spazi vuoti: Separa sezioni e gruppi di istruzioni con righe vuote
• Mantieni i titoli in maiuscole e minuscole normali: # Goal, non # GOAL
• Sii coerente: Usa lo stesso schema di formattazione in tutto il prompt

Domande frequenti

Prossimi passi

Questa guida fornisce le basi per un comportamento affidabile degli agenti tramite prompt engineering, configurazione degli strumenti e pattern architetturali. Per creare sistemi pronti per la produzione, prosegui con:

• Workflow: Progetta l’orchestrazione multi-agente e i passaggi agli specialisti
• Valutazione del successo: Configura metriche e criteri di valutazione
• Raccolta dati: Acquisisci insight strutturati dalle conversazioni
• Test: Implementa test di regressione e simulazioni
• Guardrail: Configura la moderazione dei contenuti per risposte sicure degli agenti
• Privacy: Garantisci la conformità e la protezione dei dati
• Il nostro agente per la documentazione: Scopri un case study completo di questi principi in azione

Per ricevere supporto per il deployment enterprise, contatta il nostro team.