> This is a page from the ElevenLabs documentation. For a complete page index, fetch https://elevenlabs.io/docs/llms.txt. For the full documentation in a single file, fetch https://elevenlabs.io/docs/llms-full.txt.

# Promptinggids

## Inleiding

Effectieve prompting transformeert [ElevenLabs Agents](/docs/nl/eleven-agents/overview) van robotachtig naar levensecht.

![Promptinggids voor ElevenLabs Agents](/docs/_fern-img/255df05f53675feaf54c765c4ee294fda00a7c14de1b02f155922012bf0a5433.webp)

Een systeemprompt is de blauwdruk voor de persoonlijkheid en het beleid van je AI-agent. In zakelijk gebruik is deze vaak uitgebreid en definieert hij de rol, doelen en toegestane tools van de agent, stapsgewijze instructies voor bepaalde taken en guardrails die beschrijven wat de agent niet mag doen. De manier waarop je deze prompt structureert, heeft rechtstreeks invloed op de betrouwbaarheid.

> **Note**
>
> De systeemprompt bepaalt het conversationele gedrag en de stijl van reacties, maar niet de
> gespreksmechanismen zoals beurtwisseling of agentinstellingen, zoals de talen die een agent kan
> spreken. Deze aspecten worden op platformniveau beheerd.

> **Werk samen met je AI-assistent iteratief aan prompts**
>
> Met de [gehoste MCP-server](/docs/nl/eleven-agents/operate/hosted-mcp) kunnen Claude en andere MCP-clients
> de systeemprompt van een agent rechtstreeks lezen en bijwerken, zodat je prompts conversationeel kunt opstellen, beoordelen en
> verfijnen.

![Betrouwbaarheidskader voor enterprise-
agents](/docs/_fern-img/18c7dd3bf58a6715656d588834a278dbc1f368eaed2cbf91aeea3e977c2631ed.webp)

## Basisprincipes van prompt engineering

Een systeemprompt is de blauwdruk voor de persoonlijkheid en het beleid van je AI-agent. In zakelijk gebruik is deze vaak uitgebreid: de rol, doelen, toegestane tools, stapsgewijze instructies voor bepaalde taken en guardrails die beschrijven wat de agent niet mag doen, worden erin vastgelegd. Hoe je deze prompt structureert, heeft direct invloed op de betrouwbaarheid.

De volgende principes vormen de basis van prompt engineering voor productieomgevingen:

### Verdeel instructies over duidelijke secties

Door instructies te verdelen over aparte secties met markdownkoppen, kan het model ze correct prioriteren en interpreteren. Gebruik witruimte en regeleinden om instructies te scheiden.

**Waarom dit belangrijk is voor betrouwbaarheid:** Modellen zijn getraind om extra aandacht te besteden aan bepaalde koppen (vooral `# Guardrails`), en duidelijke sectiegrenzen voorkomen dat regels uit de ene context doorwerken in een andere.

**`Minder effectieve aanpak`**

```mdx title="Minder effectieve aanpak"
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.
```

**`Aanbevolen aanpak`**

```mdx title="Aanbevolen aanpak"
# Personality

You are a customer service agent for Acme Corp. You are polite, efficient, and solution-oriented.

# Goal

Help customers resolve issues quickly by looking up orders and processing refunds when appropriate.

# Guardrails

Never share sensitive customer data across conversations.
Always verify customer identity before accessing account information.

# Tone

Keep responses concise (under 3 sentences) unless the user requests detailed explanations.
```

### Wees zo beknopt mogelijk

Houd elke instructie kort, duidelijk en actiegericht. Verwijder stopwoorden en herhaal alleen wat essentieel is om het model correct te laten handelen.

**Waarom dit belangrijk is voor betrouwbaarheid:** Beknopte instructies verminderen dubbelzinnigheid en tokengebruik. Elk onnodig woord kan verkeerd worden geïnterpreteerd.

**`Minder effectieve aanpak`**

```mdx title="Minder effectieve aanpak"
# 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.
```

**`Aanbevolen aanpak`**

```mdx title="Aanbevolen aanpak"
# Tone

Speak in a friendly, conversational manner while maintaining professionalism.
```

> **Note**
>
> Als je wilt dat de agent een specifieke toon aanhoudt, definieer die dan expliciet en beknopt in de sectie `#
>   Personality` of `# Tone`. Herhaal richtlijnen voor de toon niet door de hele prompt.

### Benadruk cruciale instructies

Markeer cruciale stappen door aan het einde van de regel "This step is important" toe te voegen. De 1 à 2 belangrijkste instructies twee keer in de prompt herhalen, kan helpen om ze te versterken.

**Waarom dit belangrijk is voor betrouwbaarheid:** In complexe prompts kunnen modellen recente context voorrang geven boven eerdere instructies. Nadruk en herhaling zorgen ervoor dat cruciale regels niet over het hoofd worden gezien.

**`Minder effectieve aanpak`**

```mdx title="Minder effectieve aanpak"
# Goal

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

**`Aanbevolen aanpak`**

```mdx title="Aanbevolen aanpak"
# Goal

Verify customer identity before accessing their account. This step is important.
Look up order details and provide status updates.
Process refund requests when eligible.

# Guardrails

Never access account information without verifying customer identity first. This step is important.
```

### Tekstnormalisatie

Text-to-speech-modellen, vooral snellere modellen, zijn het beste in het genereren van spraak uit alfabetische tekst. Cijfers en symbolen zoals "@" of "£" veroorzaken daarom eerder onjuiste uitspraken of stemhallucinaties.

Om dit op te lossen, normaliseren we niet-alfabetische tekst naar woorden voordat deze het TTS-model bereikt (bijv. `123` -> `one-hundred and twenty three`, `john@gmail.com` -> `john at gmail dot com`). Je kunt kiezen uit verschillende normalisatiestrategieën met verschillende afwegingen.

#### Normalisatiestrategieën

We ondersteunen twee normalisatiestrategieën via de agentconfiguratie [`text_normalisation_type`](/docs/nl/api-reference/agents/create#request.body.conversation_config.tts.text_normalisation_type):

**`system_prompt` (standaard)** — Voegt instructies toe aan de systeemprompt die de LLM vertellen om getallen en symbolen als woorden uit te schrijven voordat de tekst het TTS-model bereikt.

* Geen extra latentie
* LLM's kunnen soms niet correct normaliseren
* Transcripten bevatten alles uitgeschreven in woorden (bijv. "one thousand dollars" in plaats van "\$1,000")

> **Tip**
>
> Als je de TTS-normalisator niet wilt gebruiken en je merkt dat de LLM nog steeds af en toe reageert
> met niet-genormaliseerde tekst, overweeg dan om over te stappen op een intelligenter LLM of extra
> normalisatie-instructies aan de systeemprompt toe te voegen.

**`elevenlabs`** — Gebruikt onze [TTS-normalisator](/docs/nl/overview/capabilities/text-to-speech/best-practices#text-normalization) om tekst na LLM-generatie te normaliseren, voordat deze het TTS-model bereikt.

* Betrouwbaarder dan normalisatie op basis van een LLM
* De systeemprompt wordt niet gewijzigd
* Transcripten behouden natuurlijke opmaak met symbolen en getallen (bijv. "\$1,000")
* Voegt geringe latentie toe

> **Tip**
>
> Als leesbaarheid van transcripten belangrijk is voor je use case, overweeg dan de `elevenlabs`-normalisator. Deze
> houdt transcripten overzichtelijk met natuurlijke symbolen en getallen, terwijl de audio nog steeds correct wordt
> uitgesproken.

Je vindt deze configuratie op ons platform onder het tabblad "Agent". Klik op het tandwielpictogram in de sectie "Voices" om het venster met algemene steminstellingen te openen en stel deze optie onderaan in.

#### Gestructureerde gegevens voor toolinvoer

Bij gebruik van de normalisatie-instelling `system_prompt` schrijft de LLM symbolen en getallen als woorden in de reacties (bijv. `john at gmail dot com` in plaats van `john@gmail.com`). Gebruikerstranscripties uit speech-to-text kunnen ook in een niet-standaardvorm binnenkomen. Dit betekent dat de LLM bij gebruik van deze gegevens als parameters in tool calls mogelijk de ongestructureerde versie uit de gesprekscontext gebruikt.

Als een toolparameter een correct opgemaakte waarde verwacht (bijv. `john@gmail.com` en niet `john at gmail dot com`), moet de LLM dit weten. Neem de verwachte indeling rechtstreeks op in de beschrijving van de toolparameter, met een voorbeeld.

**`Minder effectief: vage parameterbeschrijving`**

```mdx title="Minder effectief: vage parameterbeschrijving"
## `lookupAccount` tool parameters

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

**`Aanbevolen: expliciete indeling in parameterbeschrijving`**

```mdx title="Aanbevolen: expliciete indeling in parameterbeschrijving"
## `lookupAccount` tool parameters

- `email` (required): "The user's email in standard email format, e.g. 'john@gmail.com'."
- `phone` (required): "The user's phone number as digits only, e.g. '5551234567'."
- `confirmation_code` (required): "The user's confirmation code as a single alphanumeric string without spaces, e.g. 'ABC123'."
```

### Reserveer een sectie voor guardrails

Vermeld alle ononderhandelbare regels die het model altijd moet volgen in een aparte sectie `# Guardrails`. Modellen zijn getraind om extra aandacht te besteden aan deze kop.

**Waarom dit belangrijk is voor betrouwbaarheid:** Guardrails voorkomen ongepaste reacties en helpen naleving van beleid te waarborgen. Door ze in een aparte sectie te centraliseren, zijn ze eenvoudiger te controleren en bij te werken.

**`Aanbevolen aanpak`**

```mdx title="Aanbevolen aanpak"
# 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.
```

Lees onze gids over [Guardrails](/docs/nl/eleven-agents/best-practices/guardrails) voor meer informatie over het ontwerpen van effectieve guardrails.

## Toolconfiguratie voor betrouwbaarheid

Agents die transactionele workflows kunnen afhandelen, kunnen zeer effectief zijn. Hiervoor moeten ze zijn uitgerust met tools waarmee ze acties in andere systemen kunnen uitvoeren of daar live gegevens kunnen ophalen.

Net zo belangrijk als de promptstructuur is hoe je de beschikbare tools voor je agent beschrijft. Duidelijke, actiegerichte tooldefinities helpen het model om ze correct aan te roepen en soepel van fouten te herstellen.

### Beschrijf tools nauwkeurig met gedetailleerde parameters

Voeg bij het maken van een tool beschrijvingen toe aan alle parameters. Dit helpt de LLM tool calls nauwkeurig op te bouwen.

**Toolbeschrijving:** "Zoekt de bestelstatus van een klant op aan de hand van de bestel-ID en geeft de huidige status, geschatte leverdatum en trackingnummer terug."

**Parameterbeschrijvingen:**

* `order_id` (verplicht): "De unieke bestel-ID, opgemaakt als geschreven tekens (bijv. 'ORD123456')"
* `include_history` (optioneel): "Als true, wordt de volledige bestelgeschiedenis teruggegeven, inclusief statuswijzigingen"

**Waarom dit belangrijk is voor betrouwbaarheid:** Parameterbeschrijvingen fungeren als inline documentatie voor het model. Ze verduidelijken verwachte indelingen, verplichte en optionele velden, en toegestane waarden.

### Leg in de systeemprompt uit wanneer en hoe je elke tool gebruikt

Definieer in je systeemprompt duidelijk wanneer en hoe elke tool moet worden gebruikt. Vertrouw niet alleen op toolbeschrijvingen: geef ook gebruikscontext en logica voor de volgorde.

**`Aanbevolen aanpak`**

```mdx title="Aanbevolen aanpak"
# 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.
```

### Geef verwachte indelingen op in beschrijvingen van toolparameters

Wanneer tools gestructureerde identifiers vereisen (e-mailadressen, telefoonnummers, codes), maak je de verwachte indeling expliciet in de parameterbeschrijving, met een voorbeeld. Dit is vooral belangrijk omdat normalisatie en speech-to-text-transcriptie waarden in gesproken vorm kunnen opleveren in de gesprekscontext. Zie [gestructureerde gegevens voor toolinvoer](#structured-data-for-tool-inputs) voor achtergrondinformatie.

**`Minder effectief: vage parameterbeschrijving`**

```mdx title="Minder effectief: vage parameterbeschrijving"
## `lookupAccount` tool parameters

- `email` (required): "The customer's email address."
```

**`Aanbevolen: expliciete indeling met voorbeeld`**

```mdx title="Aanbevolen: expliciete indeling met voorbeeld"
## `lookupAccount` tool parameters

- `email` (required): "The customer's email in standard email format, e.g. 'john.smith@company.com'."
```

### Handel fouten bij tool calls soepel af

Tools kunnen soms mislukken door netwerkproblemen, ontbrekende gegevens of andere fouten. Neem duidelijke herstelinstructies op in je systeemprompt.

**Waarom dit belangrijk is voor betrouwbaarheid:** Toolfouten zijn onvermijdelijk in productieomgevingen. Zonder expliciete instructies voor foutafhandeling kunnen agents reacties hallucineren of onjuiste informatie geven.

**`Aanbevolen aanpak`**

```mdx title="Aanbevolen aanpak"
# 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?"
```

Bekijk onze documentatie over [Client tools](/docs/nl/eleven-agents/customization/tools/client-tools), [Webhook tools](/docs/nl/eleven-agents/customization/tools/webhook-tools) en [MCP tools](/docs/nl/eleven-agents/customization/tools/mcp) voor uitgebreide richtlijnen voor het bouwen van betrouwbare toolintegraties.

## Architectuurpatronen voor bedrijfsagents

Sterke prompts en tools vormen de basis voor betrouwbare agents, maar productiesystemen vereisen een doordacht architectuurontwerp. Bedrijfsagents verwerken complexe workflows die vaak verder gaan dan wat één monolithische prompt aankan.

### Houd agents gespecialiseerd

Te brede instructies of grote contextvensters verhogen de latentie en verminderen de nauwkeurigheid. Elke agent moet een afgebakende, duidelijk gedefinieerde kennisbank en reeks verantwoordelijkheden hebben.

**Waarom dit belangrijk is voor betrouwbaarheid:** Gespecialiseerde agents hebben minder randgevallen om af te handelen, duidelijkere succescriteria en snellere reactietijden. Ze zijn eenvoudiger te testen, debuggen en verbeteren.

> **Note**
>
> Een algemene agent die "alles doet" is moeilijker te onderhouden en faalt in
> productie waarschijnlijk vaker dan een netwerk van gespecialiseerde agents met duidelijke overdrachten.

### Gebruik patronen met een orkestrator en specialisten

Ontwerp voor complexe taken multi-agentworkflows waarin taken worden overgedragen tussen gespecialiseerde agents, en waar nodig aan menselijke medewerkers.

**Architectuurpatroon:**

1. **Orkestratoragent:** Routeert binnenkomende verzoeken naar de juiste gespecialiseerde agents op basis van intentclassificatie
2. **Gespecialiseerde agents:** Verwerken domeinspecifieke taken (facturering, planning, technische support enz.)
3. **Escalatie naar een medewerker:** Vastgelegde criteria voor overdracht bij complexe of gevoelige gevallen

**Voordelen van dit patroon:**

* Elke specialist heeft een gerichte prompt en minder context
* Je kunt afzonderlijke specialisten eenvoudiger bijwerken zonder het systeem te beïnvloeden
* Duidelijke statistieken per domein (oplossingspercentage voor facturering, slagingspercentage voor planning enz.)
* Minder latentie per interactie (kleinere prompts, snellere inferentie)

### Definieer duidelijke overdrachtscriteria

Geef bij het ontwerpen van multi-agentworkflows precies aan wanneer en hoe de besturing moet worden overgedragen tussen agents of aan menselijke medewerkers.

**`Voorbeeld van een orkestratoragent`**

```mdx title="Voorbeeld van een orkestratoragent"
# 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
```

**`Voorbeeld van een gespecialiseerde agent`**

```mdx title="Voorbeeld van een gespecialiseerde agent"
# 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.
```

Bekijk onze documentatie over [Workflows](/docs/nl/eleven-agents/customization/agent-workflows) voor uitgebreide richtlijnen voor het bouwen van multi-agentworkflows.

## Modelselectie voor betrouwbaarheid in bedrijven

De keuze voor het juiste model hangt af van je prestatievereisten, met name latentie, nauwkeurigheid en betrouwbaarheid bij tool calls. Verschillende modellen bieden verschillende afwegingen tussen snelheid, redeneervermogen en kosten.

### Begrijp de afwegingen

**Latentie:** Kleinere modellen (met minder parameters) reageren doorgaans sneller, waardoor ze geschikt zijn voor frequente interacties met lage complexiteit.

**Nauwkeurigheid:** Grotere modellen bieden sterker redeneervermogen en kunnen complexe taken met meerdere stappen beter verwerken, maar hebben een hogere latentie en hogere kosten.

**Betrouwbaarheid bij tool calls:** Niet alle modellen behandelen tool/function calling even nauwkeurig. Sommige blinken uit in gestructureerde output, terwijl andere explicietere prompts vereisen.

### Modelaanbevelingen per use case

Op basis van implementaties met miljoenen agentinteracties komen de volgende patronen naar voren:

* **GLM 5.2 of GPT-6 Luna (aanbevolen startpunt):** Het beste voor algemene bedrijfsagents waarbij latentie, nauwkeurigheid en kosten allemaal in balans moeten zijn. Biedt lage tot gemiddelde latentie, sterke prestaties bij tool calls en redelijke kosten per interactie. Ideaal voor klantenservice, planning, orderbeheer en het afhandelen van algemene vragen.

* **DeepSeek Flash 4.1 of Gemini 3.5 Flash-Lite (ultralage latentie):** Het beste voor frequente, eenvoudige interacties waarbij snelheid cruciaal is. Biedt de laagste latentie met brede algemene kennis, maar presteert minder goed bij complexe tool calls. Schaalbaar en kosteneffectief voor eerste routering/triage, eenvoudige veelgestelde vragen, afspraakbevestigingen en basisgegevensverzameling.

* **Claude Sonnet 5.5 (complex redeneren):** Het beste voor probleemoplossing met meerdere stappen, genuanceerde beoordelingen en complexe toolorkestratie. Biedt de hoogste nauwkeurigheid en het sterkste redeneervermogen met uitstekende betrouwbaarheid bij tool calls, maar met hogere latentie en kosten. Ideaal voor taken waarbij fouten kostbaar zijn, zoals technische probleemoplossing, financieel advies, workflows die gevoelig zijn voor compliance en complexe beslissingen over terugbetalingen of escalaties.

Het modellenaanbod van providers verandert regelmatig. Controleer de huidige opties en prijzen op de pagina [Models](/docs/nl/eleven-agents/customization/llm) voordat je een model kiest voor productie.

### Benchmark met je eigen prompts

Modelprestaties variëren aanzienlijk op basis van promptstructuur en taakcomplexiteit. Doe het volgende voordat je een model kiest:

1. Test 2-3 kandidaatmodellen met je daadwerkelijke systeemprompt
2. Evalueer met echte gebruikersvragen of synthetische testcases
3. Meet latentie, nauwkeurigheid en het slagingspercentage van tool calls
4. Optimaliseer voor de beste afweging op basis van je specifieke vereisten

Bekijk onze [Models-documentatie](/docs/nl/eleven-agents/customization/llm) voor gedetailleerde opties voor modelconfiguratie.

## Iteratie en testen

Betrouwbaarheid in productieomgevingen komt voort uit voortdurende iteratie. Zelfs goed opgebouwde prompts kunnen bij werkelijk gebruik falen. Het gaat erom van die fouten te leren en via gedisciplineerd testen te verbeteren.

### Configureer evaluatiecriteria

Koppel concrete evaluatiecriteria aan elke agent om het succes in de loop van de tijd te monitoren en op regressies te controleren.

**Belangrijke statistieken om bij te houden:**

* **Taakvoltooiingspercentage:** Percentage gebruikersintenties dat succesvol is afgehandeld
* **Escalatiepercentage:** Percentage gesprekken waarvoor menselijke tussenkomst nodig is

Bekijk [Succesevaluatie](/docs/nl/eleven-agents/customization/agent-analysis/success-evaluation) voor uitgebreide richtlijnen voor het configureren van evaluatiecriteria in ElevenLabs.

### Analyseer foutpatronen

Identificeer patronen in problematische interacties wanneer agents ondermaats presteren:

* **Waar geeft de agent onjuiste informatie?** → Versterk instructies in specifieke secties
* **Wanneer begrijpt de agent de gebruikersintentie niet?** → Voeg voorbeelden toe of vereenvoudig de taal
* **Welke gebruikersinvoer zorgt ervoor dat de agent uit zijn rol valt?** → Voeg guardrails toe voor randgevallen
* **Welke tools falen het vaakst?** → Verbeter foutafhandeling of parameterbeschrijvingen

Bekijk gesprekstranscripten waarin de gebruiker weinig tevreden was of taken niet zijn voltooid.

### Breng gerichte verbeteringen aan

Werk specifieke secties van je prompt bij om vastgestelde problemen aan te pakken:

1. **Isoleer het probleem:** Bepaal welke promptsectie of tooldefinitie de fouten veroorzaakt
2. **Test wijzigingen met specifieke voorbeelden:** Gebruik gesprekken die eerder faalden als testcases
3. **Voer steeds één wijziging door:** Isoleer verbeteringen om te begrijpen wat werkt
4. **Evalueer opnieuw met dezelfde testcases:** Controleer of de wijziging het probleem oploste zonder nieuwe problemen te veroorzaken

> **Warning**
>
> Voer niet meerdere promptwijzigingen tegelijk door. Daardoor is het onmogelijk om
> verbeteringen of regressies aan specifieke wijzigingen toe te schrijven.

### Configureer gegevensverzameling

Configureer je agent om gegevens uit elk gesprek samen te vatten. Zo kun je interactiepatronen analyseren, veelvoorkomende gebruikersverzoeken identificeren en je prompt voortdurend verbeteren op basis van gebruik in de praktijk.

Bekijk [Gegevensverzameling](/docs/nl/eleven-agents/customization/agent-analysis/data-collection) voor uitgebreide richtlijnen voor het configureren van gegevensverzameling in ElevenLabs.

### Gebruik simulatie voor regressietesten

Test voordat je promptwijzigingen naar productie implementeert met een reeks bekende scenario's om regressies op te sporen.

Bekijk [Gesprekken simuleren](/docs/nl/eleven-agents/guides/simulate-conversation) voor richtlijnen voor het programmatisch testen van agents.

## Overwegingen voor productie

Bedrijfsagents vereisen extra waarborgen naast promptkwaliteit. Implementaties in productie moeten rekening houden met foutafhandeling, compliance en gecontroleerde degradatie.

### Handel fouten af in alle toolintegraties

Elke externe tool call is een mogelijk foutpunt. Zorg dat je prompt expliciete foutafhandeling bevat voor:

* **Netwerkfouten:** "Ik heb problemen met de verbinding met ons systeem. Laat me het opnieuw proberen."
* **Ontbrekende gegevens:** "Ik zie die informatie niet in ons systeem. Kun je de gegevens controleren?"
* **Time-outfouten:** "Dit duurt langer dan verwacht. Ik kan dit escaleren naar een specialist of het opnieuw proberen."
* **Toestemmingsfouten:** "Ik heb geen toegang tot die informatie. Ik verbind je door met iemand die kan helpen."

## Voorbeeldprompts

De volgende voorbeelden laten zien hoe je de principes uit deze gids toepast op praktische zakelijke use cases. Elk voorbeeld bevat annotaties die aangeven welke betrouwbaarheidsprincipes worden gebruikt.

### Voorbeeld 1: Agent voor technische support

**`Specialist technische support`**

```mdx title="Specialist technische support" maxLines=60
# 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
```

**Getoonde principes:**

* ✓ Duidelijke scheiding van secties (`# Personality`, `# Goal`, `# Tools` enz.)
* ✓ Eén actie per regel (zie de genummerde stappen in `# Goal`)
* ✓ Beknopte instructies (de toonsectie is kort en duidelijk)
* ✓ Benadrukte cruciale stappen ("This step is important")
* ✓ Indelingsconversie in parameterbeschrijvingen (normalisatie van e-mailadressen)
* ✓ Aparte sectie voor guardrails
* ✓ Nauwkeurige toolbeschrijvingen met richtlijnen voor wanneer/hoe/fouten
* ✓ Expliciete instructies voor foutafhandeling

### Voorbeeld 2: Agent voor terugbetalingen bij klantenservice

**`Specialist voor verwerking van terugbetalingen`**

```mdx title="Specialist voor verwerking van terugbetalingen" maxLines=50
# 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."
```

**Getoonde principes:**

* ✓ Gespecialiseerde agentscope (alleen terugbetalingen, geen algemene support)
* ✓ Duidelijke workflowstappen in de sectie `# Goal`
* ✓ Herhaalde nadruk op cruciale regels (limieten voor terugbetalingen, verificatie)
* ✓ Gedetailleerd toolgebruik met "wanneer gebruiken" en "vereiste controles"
* ✓ Indelingsconversie in parameterbeschrijvingen (bestel-ID's, e-mailadressen)
* ✓ Expliciete foutafhandeling per tool
* ✓ Duidelijk gedefinieerde escalatiecriteria

## Best practices voor opmaak

Hoe je je prompt opmaakt, beïnvloedt hoe effectief het taalmodel deze interpreteert:

* **Gebruik markdownkoppen:** Structureer secties met `#` voor hoofdsecties en `##` voor subsecties
* **Geef de voorkeur aan opsommingstekens:** Verdeel instructies in overzichtelijke opsommingstekens
* **Gebruik witruimte:** Scheid secties en instructiegroepen met lege regels
* **Houd koppen in zinsvorm:** `# Goal` en niet `# GOAL`
* **Wees consistent:** Gebruik hetzelfde opmaakpatroon in de hele prompt

## Veelgestelde vragen

#### Hoe behoud ik consistentie tussen meerdere agents?

Maak gedeelde prompttemplates voor veelvoorkomende onderdelen, zoals tekennormalisatie, foutafhandeling
en vangrails. Bewaar deze in een centrale repository en verwijs ernaar vanuit gespecialiseerde agents.
Gebruik het orchestratorpatroon voor consistente routeringslogica en overdrachtsprocedures.

#### Wat is de minimale werkbare prompt voor productie?

Neem minimaal het volgende op: (1) definitie van persoonlijkheid/rol, (2) primair doel, (3) kernvangrails en
(4) toolbeschrijvingen als je tools gebruikt. Zelfs eenvoudige agents hebben baat bij een expliciete sectie-
structuur en instructies voor foutafhandeling.

#### Hoe kan ik tools uitfaseren zonder agents te verstoren?

Voeg bij het uitfaseren van een tool eerst een nieuwe tool toe en pas daarna de prompt aan om de nieuwe tool te verkiezen, terwijl
je de oude als terugvaloptie behoudt. Monitor het gebruik en verwijder de oude tool zodra het gebruik daalt tot
nul. Neem altijd foutafhandeling op, zodat agents kunnen herstellen als een uitgefaseerde tool wordt aangeroepen.

#### Moet ik verschillende prompts gebruiken voor verschillende LLM's?

Over het algemeen werken prompts die zijn opgebouwd volgens de principes in deze handleiding voor verschillende modellen. Wel kan
modelspecifieke afstemming de prestaties verbeteren, vooral voor het formaat van toolaanroepen en redeneer-
stappen. Test je prompt met meerdere modellen en pas deze zo nodig aan.

#### Hoe lang moet mijn systeemprompt zijn?

Er is geen universele limiet, maar prompts van meer dan 2000 tokens verhogen de latentie en kosten. Richt je op
beknoptheid: elke regel moet een duidelijk doel dienen. Als je prompt langer is dan 2000 tokens, overweeg dan
deze op te splitsen in meerdere gespecialiseerde agents of referentiemateriaal onder te brengen in een kennisbank.

#### Hoe vind ik een balans tussen consistentie en aanpasbaarheid?

Leg kernpersoonlijkheidskenmerken, doelen en vangrails duidelijk vast, maar houd ruimte voor flexibiliteit in toon
en beknoptheid op basis van de communicatiestijl van de gebruiker. Gebruik voorwaardelijke instructies: "Als de gebruiker
gefrustreerd is, erken dan eerst diens zorgen voordat je doorgaat."

#### Kan ik prompts na de implementatie bijwerken?

Ja. Systeemprompts kunnen op elk moment worden aangepast om gedrag bij te sturen. Dit is vooral nuttig
om opkomende problemen aan te pakken of mogelijkheden te verfijnen op basis van gebruikersinteracties.
Test wijzigingen altijd in een stagingomgeving voordat je ze in productie implementeert.

#### Hoe voorkom ik dat agents hallucineren wanneer tools falen?

Neem voor elke tool expliciete instructies voor foutafhandeling op. Benadruk in het gedeelte met vangrails: "gok nooit en verzin geen
informatie". Herhaal deze instructie in de foutafhandelingssecties die specifiek zijn voor tools.
Test scenario's waarin tools falen tijdens de ontwikkeling om ervoor te zorgen dat agents de herstel-
instructies volgen.

## Volgende stappen

Deze handleiding legt de basis voor betrouwbaar agentgedrag met prompt engineering, toolconfiguratie en architectuurpatronen. Ga voor systemen van productiekwaliteit verder met:

* **[Workflows](/docs/nl/eleven-agents/customization/agent-workflows):** Ontwerp multi-agentorkestratie en overdrachten tussen specialisten
* **[Sucessevaluatie](/docs/nl/eleven-agents/customization/agent-analysis/success-evaluation):** Configureer metrics en evaluatiecriteria
* **[Gegevensverzameling](/docs/nl/eleven-agents/customization/agent-analysis/data-collection):** Leg gestructureerde inzichten uit gesprekken vast
* **[Testen](/docs/nl/eleven-agents/customization/agent-testing):** Implementeer regressietests en simulatie
* **[Vangrails](/docs/nl/eleven-agents/best-practices/guardrails):** Configureer contentmoderatie voor veilige agentreacties
* **[Privacy](/docs/nl/eleven-agents/customization/privacy):** Zorg voor naleving en gegevensbescherming
* **[Onze Docs Agent](/docs/nl/eleven-agents/guides/elevenlabs-docs-agent):** Bekijk een volledige casestudy waarin deze principes worden toegepast

Neem voor ondersteuning bij enterprise-implementatie [contact op met ons team](https://elevenlabs.io/contact-sales).