> 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.

# Guide till promptning

## Introduktion

Effektiv promptning gör [ElevenLabs Agents](/docs/sv/eleven-agents/overview) mer naturtrogna i stället för robotiska.

![Guide till promptning för ElevenLabs Agents](/docs/_fern-img/255df05f53675feaf54c765c4ee294fda00a7c14de1b02f155922012bf0a5433.webp)

En systemprompt är ritningen för din AI-agents personlighet och policyer. I företagsanvändning är den ofta omfattande – den definierar agentens roll, mål, tillåtna verktyg, stegvisa instruktioner för vissa uppgifter och skyddsräcken som beskriver vad agenten inte ska göra. Hur du strukturerar den här prompten påverkar direkt tillförlitligheten.

> **Note**
>
> Systemprompten styr samtalsbeteende och svarsformat, men inte mekaniken i konversationsflödet,
> som turtagning, eller agentinställningar som vilka språk en agent kan
> tala. Dessa aspekter hanteras på plattformsnivå.

> **Förfina prompter med din AI-assistent**
>
> Den [hostade MCP-servern](/docs/sv/eleven-agents/operate/hosted-mcp) låter Claude och andra MCP-klienter
> läsa och uppdatera en agents systemprompt direkt, så att du kan utforma, granska och förfina prompter
> samtalsmässigt.

![Ramverk för tillförlitlighet hos
företagsagenter](/docs/_fern-img/18c7dd3bf58a6715656d588834a278dbc1f368eaed2cbf91aeea3e977c2631ed.webp)

## Grunderna i prompt engineering

En systemprompt är personlighets- och policyritningen för din AI-agent. I företagsanvändning är den ofta omfattande – den definierar agentens roll, mål, tillåtna verktyg, steg-för-steg-instruktioner för vissa uppgifter och skyddsräcken som beskriver vad agenten inte ska göra. Hur du strukturerar den här prompten påverkar direkt tillförlitligheten.

Följande principer utgör grunden för prompt engineering i produktionsklass:

### Dela upp instruktioner i tydliga avsnitt

Att dela upp instruktioner i separata avsnitt med markdown-rubriker hjälper modellen att prioritera och tolka dem korrekt. Använd tomrader och radbrytningar för att skilja instruktioner åt.

**Varför detta är viktigt för tillförlitligheten:** Modeller är tränade att ägna vissa rubriker extra uppmärksamhet (särskilt `# Guardrails`), och tydliga avsnittsgränser förhindrar att instruktioner flyter ihop så att regler från ett sammanhang påverkar ett annat.

**`Mindre effektiv metod`**

```mdx title="Mindre effektiv metod"
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.
```

**`Rekommenderad metod`**

```mdx title="Rekommenderad metod"
# 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.
```

### Var så kortfattad som möjligt

Håll varje instruktion kort, tydlig och handlingsinriktad. Ta bort utfyllnadsord och upprepa bara det som är nödvändigt för att modellen ska kunna agera korrekt.

**Varför detta är viktigt för tillförlitligheten:** Kortfattade instruktioner minskar tvetydighet och tokenanvändning. Varje onödigt ord är en möjlig källa till misstolkning.

**`Mindre effektiv metod`**

```mdx title="Mindre effektiv metod"
# 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.
```

**`Rekommenderad metod`**

```mdx title="Rekommenderad metod"
# Tone

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

> **Note**
>
> Om du behöver att agenten håller en viss ton definierar du den uttryckligen och kortfattat i avsnittet `#
>   Personality` eller `# Tone`. Undvik att upprepa vägledning om ton genom hela prompten.

### Betona kritiska instruktioner

Markera kritiska steg genom att lägga till "Det här steget är viktigt" i slutet av raden. Att upprepa de 1–2 viktigaste instruktionerna två gånger i prompten kan förstärka dem.

**Varför detta är viktigt för tillförlitligheten:** I komplexa promptar kan modeller prioritera nyligt sammanhang framför tidigare instruktioner. Betoning och upprepning säkerställer att kritiska regler inte förbises.

**`Mindre effektiv metod`**

```mdx title="Mindre effektiv metod"
# Goal

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

**`Rekommenderad metod`**

```mdx title="Rekommenderad metod"
# 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.
```

### Textnormalisering

Text to Speech-modeller, särskilt snabbare modeller, är bäst på att generera tal från alfabetisk text. Därför är det mer sannolikt att siffror och symboler som "@" eller "£" orsakar felaktiga uttal eller rösthallucinationer.

För att lösa detta normaliserar vi icke-alfabetisk text till ord innan den når TTS-modellen (t.ex. `123` -> `one-hundred and twenty three`, `john@gmail.com` -> `john at gmail dot com`) och låter dig välja mellan olika normaliseringsstrategier med olika avvägningar.

#### Normaliseringsstrategier

Vi stöder två normaliseringsstrategier via agentkonfigurationen [`text_normalisation_type`](/docs/sv/api-reference/agents/create#request.body.conversation_config.tts.text_normalisation_type):

**`system_prompt` (standard)** — Lägger till instruktioner i systemprompten som säger åt LLM:en att skriva ut siffror och symboler som ord innan texten når TTS-modellen.

* Ingen extra latens
* LLM:er kan ibland misslyckas med att normalisera korrekt
* Transkriptioner innehåller allt utskrivet med ord (t.ex. "one thousand dollars" i stället för "\$1,000")

> **Tip**
>
> Om du inte vill använda TTS-normaliseraren och märker att LLM:en fortfarande ibland svarar
> med onormaliserad text kan du överväga att byta till en mer intelligent LLM eller lägga till fler
> normaliseringsinstruktioner i systemprompten.

**`elevenlabs`** — Använder vår [TTS-normaliserare](/docs/sv/overview/capabilities/text-to-speech/best-practices#text-normalization) för att normalisera text efter LLM-generering och innan den når TTS-modellen.

* Mer tillförlitlig än LLM-baserad normalisering
* Systemprompten ändras inte
* Transkriptioner behåller naturlig formatering med symboler och siffror (t.ex. "\$1,000")
* Lägger till mindre latens

> **Tip**
>
> Om läsbarheten i transkriptioner är viktig för ditt användningsfall bör du överväga att använda
> normaliseraren `elevenlabs`. Den håller transkriptionerna rena med naturliga symboler och siffror
> samtidigt som den fortfarande ger korrekt talat ljud.

Du hittar den här konfigurationen på vår plattform under fliken "Agent" genom att klicka på kugghjulsikonen i avsnittet "Voices" för att öppna panelen med gemensamma röstinställningar och konfigurera den längst ned.

#### Strukturerade data för verktygsindata

När du använder normaliseringsinställningen `system_prompt` skriver LLM:en ut symboler och siffror som ord i sina svar (t.ex. `john at gmail dot com` i stället för `john@gmail.com`). Användartranskriptioner från tal-till-text kan också komma i ett icke-standardiserat format. Det innebär att LLM:en kan använda den ostrukturerade version som finns i konversationssammanhanget när dessa uppgifter används som parametrar i verktygsanrop.

Om en verktygsparameter förväntar sig ett korrekt formaterat värde (t.ex. `john@gmail.com`, inte `john at gmail dot com`) måste LLM:en känna till det. Ange det förväntade formatet direkt i verktygsparameterbeskrivningen med ett exempel.

**`Mindre effektivt: vag parameterbeskrivning`**

```mdx title="Mindre effektivt: vag parameterbeskrivning"
## `lookupAccount` tool parameters

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

**`Rekommenderat: uttryckligt format i parameterbeskrivningen`**

```mdx title="Rekommenderat: uttryckligt format i parameterbeskrivningen"
## `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'."
```

### Avsätt ett avsnitt för skyddsräcken

Lista alla icke förhandlingsbara regler som modellen alltid måste följa i ett särskilt avsnitt med `# Guardrails`. Modeller är tränade att ägna den här rubriken extra uppmärksamhet.

**Varför detta är viktigt för tillförlitligheten:** Skyddsräcken förhindrar olämpliga svar och säkerställer att policyer följs. Att samla dem i ett särskilt avsnitt gör dem enklare att granska och uppdatera.

**`Rekommenderad metod`**

```mdx title="Rekommenderad metod"
# 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.
```

Om du vill veta mer om att utforma effektiva skyddsräcken kan du läsa vår guide om [Guardrails](/docs/sv/eleven-agents/best-practices/guardrails).

## Verktygskonfiguration för tillförlitlighet

Agenter som kan hantera transaktionsbaserade arbetsflöden kan vara mycket effektiva. För att möjliggöra detta måste de utrustas med verktyg som låter dem utföra åtgärder i andra system eller hämta live-data från dem.

Lika viktigt som promptens struktur är hur du beskriver de verktyg som är tillgängliga för din agent. Tydliga, handlingsinriktade verktygsdefinitioner hjälper modellen att anropa dem korrekt och återhämta sig smidigt efter fel.

### Beskriv verktyg exakt med detaljerade parametrar

När du skapar ett verktyg lägger du till beskrivningar för alla parametrar. Det hjälper LLM:en att skapa korrekta verktygsanrop.

**Verktygsbeskrivning:** "Slår upp kundens orderstatus via order-ID och returnerar aktuell status, beräknat leveransdatum och spårningsnummer."

**Parameterbeskrivningar:**

* `order_id` (obligatorisk): "Den unika orderidentifieraren, formaterad som skrivna tecken (t.ex. 'ORD123456')"
* `include_history` (valfri): "Om värdet är true returneras fullständig orderhistorik, inklusive statusändringar"

**Varför detta är viktigt för tillförlitligheten:** Parameterbeskrivningar fungerar som intern dokumentation för modellen. De förtydligar formatkrav, obligatoriska respektive valfria fält och godtagbara värden.

### Förklara när och hur varje verktyg ska användas i systemprompten

Definiera tydligt i systemprompten när och hur varje verktyg ska användas. Förlita dig inte enbart på verktygsbeskrivningar – ange användningssammanhang och sekvenseringslogik.

**`Rekommenderad metod`**

```mdx title="Rekommenderad metod"
# 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.
```

### Ange förväntade format i verktygsparameterbeskrivningar

När verktyg kräver strukturerade identifierare (e-postadresser, telefonnummer, koder) ska du göra det förväntade formatet tydligt i parameterbeskrivningen med ett exempel. Detta är särskilt viktigt eftersom normalisering och tal-till-text-transkribering kan skapa värden i talad form i konversationssammanhanget. Se [strukturerade data för verktygsindata](#structured-data-for-tool-inputs) för bakgrund.

**`Mindre effektivt: vag parameterbeskrivning`**

```mdx title="Mindre effektivt: vag parameterbeskrivning"
## `lookupAccount` tool parameters

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

**`Rekommenderat: uttryckligt format med exempel`**

```mdx title="Rekommenderat: uttryckligt format med exempel"
## `lookupAccount` tool parameters

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

### Hantera fel i verktygsanrop smidigt

Verktyg kan ibland misslyckas på grund av nätverksproblem, saknade data eller andra fel. Ta med tydliga instruktioner för återställning i systemprompten.

**Varför detta är viktigt för tillförlitligheten:** Verktygsfel är oundvikliga i produktion. Utan tydliga hanteringsinstruktioner kan agenter hallucinera svar eller ge felaktig information.

**`Rekommenderad metod`**

```mdx title="Rekommenderad metod"
# 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?"
```

För detaljerad vägledning om att bygga tillförlitliga verktygsintegrationer kan du läsa vår dokumentation om [klientverktyg](/docs/sv/eleven-agents/customization/tools/client-tools), [webhook-verktyg](/docs/sv/eleven-agents/customization/tools/webhook-tools) och [MCP-verktyg](/docs/sv/eleven-agents/customization/tools/mcp).

## Arkitekturmönster för företagsagenter

Även om starka promptar och verktyg utgör grunden för agenters tillförlitlighet kräver produktionssystem genomtänkt arkitektur. Företagsagenter hanterar komplexa arbetsflöden som ofta går utöver vad en enda, monolitisk prompt klarar.

### Håll agenter specialiserade

Alltför breda instruktioner eller stora kontextfönster ökar latensen och minskar noggrannheten. Varje agent bör ha en smal, tydligt definierad kunskapsbas och uppsättning ansvarsområden.

**Varför detta är viktigt för tillförlitligheten:** Specialiserade agenter har färre specialfall att hantera, tydligare framgångskriterier och snabbare svarstider. De är enklare att testa, felsöka och förbättra.

> **Note**
>
> En generell agent som "gör allt" är svårare att underhålla och har större risk att misslyckas i
> produktion än ett nätverk av specialiserade agenter med tydliga överlämningar.

### Använd mönster med samordnare och specialister

För komplexa uppgifter utformar du arbetsflöden med flera agenter som lämnar över uppgifter mellan specialiserade agenter – och till mänskliga operatörer vid behov.

**Arkitekturmönster:**

1. **Samordnaragent:** Dirigerar inkommande förfrågningar till lämpliga specialiserade agenter baserat på avsiktsklassificering
2. **Specialiserade agenter:** Hanterar domänspecifika uppgifter (fakturering, schemaläggning, teknisk support osv.)
3. **Eskalering till människa:** Definierade överlämningskriterier för komplexa eller känsliga ärenden

**Fördelar med detta mönster:**

* Varje specialist har en fokuserad prompt och mindre kontext
* Enklare att uppdatera enskilda specialister utan att påverka systemet
* Tydliga mätvärden per domän (lösningsgrad för fakturering, framgångsgrad för schemaläggning osv.)
* Minskad latens per interaktion (mindre promptar, snabbare inferens)

### Definiera tydliga överlämningskriterier

När du utformar arbetsflöden med flera agenter ska du ange exakt när och hur kontrollen ska överföras mellan agenter eller till mänskliga operatörer.

**`Exempel på samordnaragent`**

```mdx title="Exempel på samordnaragent"
# 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
```

**`Exempel på specialistagent`**

```mdx title="Exempel på specialistagent"
# 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.
```

För detaljerad vägledning om att bygga arbetsflöden med flera agenter kan du läsa vår dokumentation om [arbetsflöden](/docs/sv/eleven-agents/customization/agent-workflows).

## Modellval för tillförlitlighet i företag

Valet av rätt modell beror på dina prestandakrav – särskilt latens, noggrannhet och tillförlitlighet vid verktygsanrop. Olika modeller erbjuder olika avvägningar mellan hastighet, resonemangsförmåga och kostnad.

### Förstå avvägningarna

**Latens:** Mindre modeller (med färre parametrar) svarar vanligtvis snabbare, vilket gör dem lämpliga för frekventa interaktioner med låg komplexitet.

**Noggrannhet:** Större modeller har bättre resonemangsförmåga och hanterar komplexa uppgifter i flera steg bättre, men med högre latens och kostnad.

**Tillförlitlighet vid verktygsanrop:** Alla modeller hanterar inte verktygs-/funktionsanrop med samma precision. Vissa är mycket bra på strukturerade utdata, medan andra kan behöva mer uttryckliga promptar.

### Modellrekommendationer per användningsfall

Baserat på driftsättningar med miljontals agentinteraktioner framträder följande mönster:

* **GLM 5.2 eller GPT-6 Luna (rekommenderad startpunkt):** Bäst för allmänna företagsagenter där latens, noggrannhet och kostnad alla måste balanseras. Ger låg till måttlig latens med stark prestanda för verktygsanrop och rimlig kostnad per interaktion. Perfekt för kundsupport, schemaläggning, orderhantering och hantering av allmänna förfrågningar.

* **DeepSeek Flash 4.1 eller Gemini 3.5 Flash-Lite (ultralåg latens):** Bäst för frekventa, enkla interaktioner där hastighet är avgörande. Ger lägst latens med bred allmänkunskap, men lägre prestanda för komplexa verktygsanrop. Kostnadseffektivt i stor skala för inledande dirigering/triage, enkla vanliga frågor, mötesbekräftelser och grundläggande datainsamling.

* **Claude Sonnet 5.5 (komplext resonemang):** Bäst för problemlösning i flera steg, nyanserade bedömningar och komplex verktygsorkestrering. Ger högst noggrannhet och resonemangsförmåga med utmärkt tillförlitlighet vid verktygsanrop, men med högre latens och kostnad. Perfekt för uppgifter där misstag är kostsamma, till exempel teknisk felsökning, finansiell rådgivning, regelefterlevnadskänsliga arbetsflöden och komplexa beslut om återbetalning/eskalering.

Modellutbudet från leverantörer ändras ofta. Kontrollera aktuella alternativ och priser på sidan [Models](/docs/sv/eleven-agents/customization/llm) innan du väljer en modell för produktion.

### Jämför med dina faktiska promptar

Modellprestanda varierar avsevärt beroende på promptstruktur och uppgiftskomplexitet. Innan du väljer en modell:

1. Testa 2–3 kandidatmodeller med din faktiska systemprompt
2. Utvärdera med riktiga användarfrågor eller syntetiska testfall
3. Mät latens, noggrannhet och framgångsgrad för verktygsanrop
4. Optimera för den bästa avvägningen utifrån dina specifika krav

För detaljerade alternativ för modellkonfiguration kan du läsa vår [Models-dokumentation](/docs/sv/eleven-agents/customization/llm).

## Iteration och testning

Tillförlitlighet i produktion kommer från kontinuerlig iteration. Även välkonstruerade promptar kan misslyckas i verklig användning. Det viktiga är att lära av dessa misslyckanden och förbättra genom disciplinerat testande.

### Konfigurera utvärderingskriterier

Koppla konkreta utvärderingskriterier till varje agent för att övervaka resultat över tid och kontrollera regressioner.

**Viktiga mätvärden att följa:**

* **Uppgiftsgenomförandegrad:** Andelen användaravsikter som hanteras framgångsrikt
* **Eskaleringsgrad:** Andelen konversationer som kräver mänsklig hjälp

För detaljerad vägledning om att konfigurera utvärderingskriterier i ElevenLabs, se [Framgångsutvärdering](/docs/sv/eleven-agents/customization/agent-analysis/success-evaluation).

### Analysera felmönster

När agenter underpresterar identifierar du mönster i problematiska interaktioner:

* **Var ger agenten felaktig information?** → Förstärk instruktionerna i specifika avsnitt
* **När misslyckas den med att förstå användarens avsikt?** → Lägg till exempel eller förenkla språket
* **Vilka användarinmatningar får den att bryta karaktär?** → Lägg till skyddsräcken för specialfall
* **Vilka verktyg misslyckas oftast?** → Förbättra felhanteringen eller parameterbeskrivningarna

Granska konversationstranskriptioner där användarnöjdheten var låg eller uppgifter inte slutfördes.

### Gör riktade förbättringar

Uppdatera specifika avsnitt i prompten för att åtgärda identifierade problem:

1. **Avgränsa problemet:** Identifiera vilket promptavsnitt eller vilken verktygsdefinition som orsakar fel
2. **Testa ändringar med specifika exempel:** Använd konversationer som tidigare misslyckades som testfall
3. **Gör en ändring i taget:** Isolera förbättringar för att förstå vad som fungerar
4. **Utvärdera på nytt med samma testfall:** Kontrollera att ändringen löste problemet utan att skapa nya problem

> **Warning**
>
> Undvik att göra flera promptändringar samtidigt. Då blir det omöjligt att koppla
> förbättringar eller regressioner till specifika ändringar.

### Konfigurera datainsamling

Konfigurera agenten så att den sammanfattar data från varje konversation. Då kan du analysera interaktionsmönster, identifiera vanliga användarförfrågningar och kontinuerligt förbättra prompten utifrån verklig användning.

För detaljerad vägledning om att konfigurera datainsamling i ElevenLabs, se [Datainsamling](/docs/sv/eleven-agents/customization/agent-analysis/data-collection).

### Använd simulering för regressionstestning

Innan du driftsätter promptändringar i produktion testar du mot en uppsättning kända scenarier för att fånga regressioner.

För vägledning om att testa agenter programmatiskt, se [Simulera konversationer](/docs/sv/eleven-agents/guides/simulate-conversation).

## Produktionsaspekter

Företagsagenter behöver ytterligare skyddsåtgärder utöver promptkvalitet. Driftsättningar i produktion måste ta hänsyn till felhantering, regelefterlevnad och smidig degradering.

### Hantera fel i alla verktygsintegrationer

Varje externt verktygsanrop är en möjlig felpunkt. Se till att prompten innehåller uttrycklig felhantering för:

* **Nätverksfel:** "Jag har problem med att ansluta till vårt system. Låt mig försöka igen."
* **Saknade data:** "Jag ser inte den informationen i vårt system. Kan du bekräfta uppgifterna?"
* **Tidsgränsfel:** "Det här tar längre tid än väntat. Jag kan eskalera till en specialist eller försöka igen."
* **Behörighetsfel:** "Jag har inte åtkomst till den informationen. Låt mig koppla dig till någon som kan hjälpa till."

## Exempel på promptar

Följande exempel visar hur du tillämpar principerna i den här guiden på verkliga användningsfall i företag. Varje exempel innehåller kommentarer som visar vilka tillförlitlighetsprinciper som används.

### Exempel 1: Agent för teknisk support

**`Specialist på teknisk support`**

```mdx title="Specialist på teknisk 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
```

**Principer som visas:**

* ✓ Tydlig uppdelning i avsnitt (`# Personality`, `# Goal`, `# Tools` osv.)
* ✓ En åtgärd per rad (se numrerade steg i `# Goal`)
* ✓ Kortfattade instruktioner (tonavsnittet är kort och tydligt)
* ✓ Betoning av kritiska steg ("This step is important")
* ✓ Formatkonvertering i parameterbeskrivningar (normalisering av e-postadresser)
* ✓ Särskilt avsnitt för skyddsräcken
* ✓ Exakta verktygsbeskrivningar med vägledning om när/hur/fel
* ✓ Uttryckliga instruktioner för felhantering

### Exempel 2: Agent för återbetalningar inom kundservice

**`Specialist på återbetalningshantering`**

```mdx title="Specialist på återbetalningshantering" 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."
```

**Principer som visas:**

* ✓ Specialiserat agentomfång (endast återbetalningar, inte allmän support)
* ✓ Tydliga arbetsflödessteg i avsnittet `# Goal`
* ✓ Upprepad betoning av kritiska regler (återbetalningsgränser, verifiering)
* ✓ Detaljerad verktygsanvändning med "när det ska användas" och "obligatoriska kontroller"
* ✓ Formatkonvertering i parameterbeskrivningar (order-ID:n, e-postadresser)
* ✓ Uttrycklig felhantering per verktyg
* ✓ Tydligt definierade eskaleringskriterier

## Bästa praxis för formatering

Hur du formaterar prompten påverkar hur effektivt språkmodellen tolkar den:

* **Använd markdown-rubriker:** Strukturera avsnitt med `#` för huvudavsnitt och `##` för underavsnitt
* **Föredra punktlistor:** Dela upp instruktioner i lättöverskådliga punkter
* **Använd tomrum:** Separera avsnitt och instruktionsgrupper med tomrader
* **Skriv rubriker med normal versalisering:** `# Goal`, inte `# GOAL`
* **Var konsekvent:** Använd samma formateringsmönster genom hela prompten

## Vanliga frågor

#### Hur upprätthåller jag enhetlighet mellan flera agenter?

Skapa delade promptmallar för vanliga avsnitt som teckennormalisering, felhantering
och skyddsräcken. Lagra dem i ett centralt repository och hänvisa till dem i specialistagenter.
Använd orkestrerarmönstret för att säkerställa enhetlig routningslogik och tydliga överlämningsrutiner.

#### Vilken är den minsta möjliga prompten för produktion?

Inkludera minst: (1) definition av personlighet/roll, (2) primärt mål, (3) centrala skyddsräcken och
(4) verktygsbeskrivningar om verktyg används. Även enkla agenter gynnas av en tydlig
avsnittsstruktur och instruktioner för felhantering.

#### Hur hanterar jag utfasning av verktyg utan att agenter slutar fungera?

När du fasar ut ett verktyg ska du först lägga till ett nytt och sedan uppdatera prompten så att det nya verktyget prioriteras, samtidigt som
det gamla behålls som reserv. Övervaka användningen och ta sedan bort det gamla verktyget när användningen sjunker till
noll. Inkludera alltid felhantering så att agenter kan återhämta sig om ett utfasat verktyg anropas.

#### Bör jag använda olika promptar för olika LLM:er?

I allmänhet fungerar promptar som är strukturerade enligt principerna i den här guiden mellan olika modeller. Däremot
kan modellspecifik finjustering förbättra prestandan – särskilt för format för verktygsanrop och resonemangs-
steg. Testa din prompt med flera modeller och justera vid behov.

#### Hur lång bör min systemprompt vara?

Det finns ingen universell gräns, men promptar på över 2 000 token ökar latens och kostnad. Fokusera på
korthet: varje rad ska ha ett tydligt syfte. Om din prompt överskrider 2 000 token bör du överväga
att dela upp den i flera specialiserade agenter eller flytta referensmaterial till en kunskapsbas.

#### Hur balanserar jag enhetlighet med anpassningsförmåga?

Definiera centrala personlighetsdrag, mål och skyddsräcken tydligt, men tillåt flexibilitet i ton
och detaljnivå utifrån användarens kommunikationsstil. Använd villkorade instruktioner: "Om användaren är
frustrerad, bekräfta deras oro innan du går vidare."

#### Kan jag uppdatera promptar efter driftsättning?

Ja. Systempromptar kan ändras när som helst för att justera beteendet. Det är särskilt användbart
för att hantera nya problem eller förfina funktioner när du lär dig av användarinteraktioner.
Testa alltid ändringar i en stagingmiljö innan du driftsätter dem i produktion.

#### Hur förhindrar jag att agenter hallucinerar när verktyg misslyckas?

Inkludera tydliga instruktioner för felhantering för varje verktyg. Betona "gissa aldrig och hitta inte på
information" i avsnittet om skyddsräcken. Upprepa instruktionen i avsnitten om verktygsspecifik felhantering.
Testa scenarier där verktyg misslyckas under utvecklingen för att säkerställa att agenter följer återställnings-
instruktionerna.

## Nästa steg

Den här guiden ger grunden för tillförlitligt agentbeteende genom promptteknik, verktygskonfiguration och arkitektoniska mönster. För att bygga system redo för produktion kan du fortsätta med:

* **[Workflows](/docs/sv/eleven-agents/customization/agent-workflows):** Utforma orkestrering med flera agenter och överlämningar till specialister
* **[Utvärdering av resultat](/docs/sv/eleven-agents/customization/agent-analysis/success-evaluation):** Konfigurera mätvärden och utvärderingskriterier
* **[Datainsamling](/docs/sv/eleven-agents/customization/agent-analysis/data-collection):** Samla in strukturerade insikter från konversationer
* **[Testning](/docs/sv/eleven-agents/customization/agent-testing):** Implementera regressionstestning och simulering
* **[Skyddsräcken](/docs/sv/eleven-agents/best-practices/guardrails):** Konfigurera innehållsmoderering för säkra agentsvar
* **[Integritet](/docs/sv/eleven-agents/customization/privacy):** Säkerställ efterlevnad och dataskydd
* **[Vår Docs-agent](/docs/sv/eleven-agents/guides/elevenlabs-docs-agent):** Se en komplett fallstudie där dessa principer används

För stöd med driftsättning i företagsskala, [kontakta vårt team](https://elevenlabs.io/contact-sales).