Wat is een system prompt? Waarom het belangrijk is voor AI-gesprekken

Een system prompt is een duidelijke set instructies die een AI-model in elk gesprek volgt. Deze bepaalt hoe het model handelt, welke toon het gebruikt, de grenzen van zijn kennis, welke tools het aanroept en welke guardrails het systeem sturen. Ontwikkelaars gebruiken system prompts om ervoor te zorgen dat AI-modellen zich consistent gedragen in klantinteracties.

In deze gids onderzoeken we wat een system prompt is en hoe deze werkt. We behandelen voorbeelden van system prompts in de praktijk en zetten de best practices uiteen die je kunt volgen om er zelf een te schrijven.

Samenvatting

• Een system prompt bepaalt de rol, toon en grenzen van een AI in al zijn interacties.
• System prompts staan hiërarchisch boven user prompts en sturen het gedrag in gesprekken.
• Elk belangrijk AI-platform gebruikt system prompts.
• Sterke system prompts gebruiken duidelijke secties, guardrails en instructies voor tools.
• System prompts ontwikkelen mee met je systeem: ontwikkelaars verfijnen ze op basis van gesprekken met klanten.

Wat is een system prompt?

Een system prompt is de instructielaag die actief is voordat een gebruiker ooit een bericht typt. Een ontwikkelaar of productteam schrijft de prompt doorgaans om een model te sturen. De meeste chatinterfaces en API's behandelen deze als context met een hogere prioriteit dan alles wat de gebruiker typt tijdens de interactie met het model.

Een system prompt bepaalt verschillende kernaspecten van een model:

• Rol: De precieze omschrijving van wie een model voor zijn use case moet nabootsen of vertegenwoordigen. Bijvoorbeeld: “Je bent een vriendelijke en efficiënte customer success-agent voor een autobedrijf.”
• Omgeving: Bepaalt de bredere context van de gebruikelijke interacties waarbij een AI-agent ondersteuning biedt en hoe die het beste kan helpen. Bijvoorbeeld: “Je helpt een klant telefonisch tijdens een customer success-gesprek. De klant kan bellen met uiteenlopende kwesties, van vragen tot informatie over bestellingen. Je hebt toegang tot de accountgeschiedenis, bestelgeschiedenis, productgegevens en de interne catalogus van de klant.”
• Toon: Richtlijnen voor hoe de agent op een gebruiker reageert en welk soort taal deze gebruikt. Bijvoorbeeld: “Je reacties zijn vriendelijk en beknopt, je gebruikt natuurlijke spraakpatronen en je mag af en toe bevestigingen gebruiken, zoals [warmly] “Ik begrijp het.”
• Doel: Het doel dat een agent heeft wanneer deze een gesprek effectief probeert af te handelen. Dit deel van de system prompt is vaak veel uitgebreider en gaat in op de nuances van verschillende doelen. In grote lijnen kun je deze sectie beginnen met iets als: “Je primaire doel is om de kwestie of vraag van een klant efficiënt op te lossen en gedurende het volgende gestructureerde proces een positieve klantervaring te bieden […]”
• Guardrails: Deze beschrijven welke onderwerpen je moet vermijden, welke informatie de AI niet mag delen, wat een agent moet doen wanneer een verzoek buiten zijn bereik valt en hoe deze moet reageren op pogingen om zijn instructies te manipuleren of te omzeilen. Een kort voorbeeld is: “Deel nooit gevoelige klantgegevens tussen gesprekken. Verifieer altijd de identiteit van een klant voordat je accountinformatie opent.” Naast de system prompt zelf ElevenAgents Guardrails 2.0 beschermt gesprekken op drie niveaus, zodat bedrijven robuuste governance-maatregelen kunnen opzetten tegen veelvoorkomende risicogebieden. 
• Proces en indeling: Hoewel dit niet altijd een eigen sectie is (soms staat het binnen Omgeving), moet je aangeven hoe je wilt dat reacties worden gestructureerd, wanneer er verduidelijkende vragen moeten worden gesteld, welke tools de AI-agent kan gebruiken en met welke gegevensbronnen deze verbinding kan maken.

Bedrijven kunnen alle bovenstaande informatie in één groot tekstblok opnemen, maar sommige agents geven mogelijk prioriteit aan informatie of besteden extra aandacht aan duidelijk gestructureerde koppen. Sectiegrenzen met markdown-opmaak zorgen voor duidelijkheid en voorkomen dat instructies doorlopen, waarbij context uit de ene sectie invloed heeft op een andere. 

Zie een system prompt als de blauwdruk van een AI-agent: deze bepaalt de rol, doelen, toegestane tools, stapsgewijze instructies voor een taak en guardrails voor wat de agent nooit mag doen.

Wat is het verschil tussen een system prompt en een user prompt?

Een system prompt staat op het hoogste niveau van een gesprek en bepaalt het onderliggende gedrag van een AI-agent in elke interactie. Een user prompt is wat een klant typt om je agent iets te geven waarop deze kan reageren. Deze varieert op basis van wat de gebruiker wil bereiken en is volledig afhankelijk van de context. Bij een klantenserviceagent kan de user prompt de chatbot vragen om bestelgegevens op te halen. In een tool voor het genereren van afbeeldingen kan een user prompt vragen om een specifiek item te maken.

Hieronder staat een tabel met een uitgebreider overzicht van de verschillen tussen een system prompt en een user prompt:

Een ander onderscheid is dat een system prompt het gedrag van een agent en de manier waarop deze reageert aanstuurt, maar geen infrastructurele mechanismen bepaalt, zoals beurtwisseling of welke talen een agent kan spreken. 

Hoe system prompts werken in AI-modellen 

Elk belangrijk AI-systeem implementeert system prompts iets anders, maar doorgaans sturen ze dezelfde processen aan. Een system prompt wordt aan het begin van het gesprek geplaatst, vóór het eerste bericht van de gebruiker, en bepaalt de overkoepelende context die een model gebruikt om te handelen en te reageren.

• System prompts in ChatGPT: Gebruikers kunnen via het tabblad Custom Instructions een system prompt toevoegen aan hun ChatGPT-modellen (ga naar Settings, vervolgens Personalization en dan Custom Instructions). Ontwikkelaars die de OpenAI API gebruiken, kunnen de prompt rechtstreeks met een bericht instellen.
• System prompts in Claude: System prompts worden door Anthropic ingesteld en wereldwijd toegepast in web- en mobiele apps. Gebruikers kunnen een aangepaste system prompt nabootsen door Claude Projects te gebruiken en aangepaste instructies toe te voegen. In API-requests kunnen ontwikkelaars system parameters opgeven om het gedrag van het model te sturen.
• Aangepaste system prompts op andere platforms: Over het algemeen wordt de system prompt eenmaal geconfigureerd in een instellingenpaneel voor de agent. Door deze in instellingen of configuraties te definiëren, kan een agent die context toepassen op elk gesprek dat deze voert, ongeacht of dat via WhatsApp, in een webapp, telefonisch of via sms is.

Hoewel de precieze configuratiemethode per platform verschilt, is het effect van het wijzigen van de system prompt om de reactie van een model aan te passen hetzelfde. 

Als enterprise-klant die met AI-modellen wil bouwen, moet je je system prompt testen met 2 à 3 kandidaatmodellen. De prestaties van een model wat betreft latency, nauwkeurigheid en slagingspercentage bij tool calls kunnen verschillen, afhankelijk van de structuur van je prompt en de complexiteit van een taak. Bekijk alle modellen die beschikbaar zijn in ElevenAgents.

Een system prompt schrijven: best practices en tips

Een system prompt moet lezen als een duidelijke specificatie. Volg bij het schrijven van je eigen AI-system prompt deze best practices om een robuuste, gedetailleerde gids te maken die je agents kunnen volgen.

Begin met een duidelijke rol en doel

De woorden die je in een system prompt opneemt, zijn belangrijk; je kunt dus niets aan het toeval overlaten. Een agent simpelweg vertellen dat deze zich ‘goed moet gedragen’ is niet duidelijk, omdat wat ‘goed’ betekent van de context kan afhangen. Begin daarom altijd met een duidelijke rol en een specifiek doel. Hoe concreter je beschrijft wie de agent is en wat je wilt dat deze bereikt, hoe minder ruimte het model heeft om hiaten op basis van aannames op te vullen. 

Deel de prompt op in duidelijke secties

In een dichte alinea ontbreken duidelijke markeringen voor waar de ene sectie eindigt en de volgende begint. Ook biedt die geen inzicht in de hiërarchie van het belang van bepaalde instructies. Gebruik secties met koppen om je tekst op te delen en een logischere structuur aan je model te presenteren. 

Een system prompt opdelen in secties helpt ook je engineers en ontwikkelaars, omdat ze secties in de toekomst eenvoudiger kunnen toevoegen of herschrijven.

Geef niet-onderhandelbare regels een eigen sectie

Voor definitieve regels die een agent absoluut niet mag overtreden, moet je een aangewezen sectie met duidelijke prioriteit maken. Door je niet-onderhandelbare regels met andere secties te vermengen, kan hun impact afnemen en kunnen er problemen ontstaan. Als je bijvoorbeeld ‘deel nooit klantgegevens’ aan je sectie over toon toevoegt, is dat mogelijk niet duidelijk voor een model.

Het is altijd het beste om geen ruimte voor interpretatie te laten. Formuleer zaken duidelijk en leg je niet-onderhandelbare regels helder vast in een zelfstandige sectie.

Bepaal wat de AI niet mag doen

Geef duidelijk aan wat een AI-model moet doen als het een randgeval tegenkomt waarvan het niet weet hoe het daarmee moet omgaan. Door vast te leggen wat een model doet als het het antwoord niet weet of een verzoek tegenkomt dat buiten zijn bereik valt, help je onverantwoord AI-gedrag in randgevallen te voorkomen.

Maak duidelijk welke tools je moet aanroepen en hoe je ze gebruikt

Een agent (vooral een agent die klanten helpt) heeft waarschijnlijk verschillende tools en functies die deze kan aanroepen. Als dat zo is, geef dan aan wanneer je deze tools gebruikt, hoe je ze gebruikt en wat je doet als een call mislukt. Wees hier specifiek over de precieze acties die een agent moet uitvoeren en wat te doen als tools onverwacht reageren.

Stem de lengte af op het belang

Een eenvoudige demo-agent kan een system prompt van slechts enkele regels hebben. De functie is vrij eenvoudig, dus je hebt geen pagina's documentatie nodig waarin randgevallen en talloze systemen voor tool calls worden beschreven. Een complexere agent heeft een langere system prompt nodig om zijn rol en escalatiepaden nauwkeurig te behandelen. 

Volg best practices voor de opmaak van system prompts 

Gebruik waar mogelijk deze best practices voor de opmaak van je system prompt:

• Gebruik markdown-koppen: Elke sectie moet een kop hebben, zodat het model begrijpt waar instructies voor de ene sectie eindigen en een nieuwe begint.
• Wees consistent: Gebruik dezelfde opmaakstructuur op je hele pagina, waaronder overal sentence case.
• Gebruik opsommingstekens: Verdeel instructies uit meerdere onderdelen in stapsgewijze lijsten of opsommingstekens voor meer duidelijkheid.

Beschouw het als een levend document 

System prompts kunnen in de loop van de tijd evolueren. Vergelijk je prompt met echte gesprekslogs om te zien of deze effectief aan de behoeften van klanten voldoet. Verfijn hem vervolgens op basis van waar je agent tekortschiet. 

Voorbeelden van system prompts in ElevenAgents

Hieronder staan drie voorbeelden van effectieve system prompts in ElevenAgents. Ze volgen best practices, presenteren informatie beknopt, benadrukken cruciale stappen en bevatten afzonderlijke secties voor guardrails.

Deze voorbeelden van system prompts ondersteunen drie verschillende use cases: een technische-supportagent, een klantenserviceagent voor terugbetalingen en een agent voor het plannen van afspraken.

Voorbeeld van een system prompt voor een technische-supportagent

# Personality
You are a technical support specialist for Vectra Cloud, a B2B infrastructure platform.
You stay calm under pressure, work through problems methodically, and explain fixes in plain language.
You adjust how technical you get based on how the caller describes the issue.

# Environment
You are supporting customers over the phone.
Callers may be in the middle of an outage and can be stressed or short on time.
You have access to a diagnostics tool and the customer's account record.

# Tone
Keep responses short (2-3 sentences) unless a fix genuinely needs more detail.
Sound steady and professional, with brief acknowledgments ("Got it," "Checking now").
Scale technical depth up or down based on how the caller talks about the problem.
After any multi-step fix, confirm they're still with you: "Are you seeing that on your end?"

# Goal
Work through the issue using this sequence:
1. Confirm the caller's identity with their email and account ID
2. Pin down which service is affected and how severe it is
3. Run a check using the `scanServiceHealth` tool
4. Walk through a fix, or escalate if two attempts don't resolve it

This step is important: never suggest a fix before the scan has run.

# Guardrails
Never open an account without confirming identity first. This step is important.
Never propose a fix that isn't backed by the scan results.
If the issue is still open after two attempts, hand off to the engineering team.
Say clearly when you don't know something instead of guessing.

# Tools

## `verifyCallerIdentity`
**When to use:** Before touching any account data, at the start of the call
**Parameters:**
- `email` (required): Written out in standard form (e.g., "user@company.com"). Convert spoken input: "at" becomes "@", "dot" becomes ".", no spaces.
- `account_id` (optional): Include if the caller has it on hand

**Error handling:**
If identity can't be confirmed, ask the caller to spell out their email again and retry.

## `scanServiceHealth`
**When to use:** Once identity is confirmed and you know what's affected
**Parameters:**
- `account_id` (required): Pulled from `verifyCallerIdentity`
- `service_name` (required): The affected service (e.g., "api," "dashboard," "storage")

**Usage:**
1. Confirm which service the caller means
2. Run the scan with the account ID and service name
3. Read the results before recommending anything

**Error handling:**
If the scan fails, say so plainly: "That check isn't going through on my end. I'll get this over to engineering."

# Error handling
If any tool call fails:
1. Say so directly: "I'm not able to pull that up right now."
2. Never fill in the gap with a guess
3. Offer one retry, then escalate if it fails again

Voorbeeld van een system prompt voor een klantenserviceagent voor terugbetalingen

# Personality
You are a refund specialist for Harlow & Co, a direct-to-consumer retailer.
You lead with empathy, look for the fastest fair resolution, and stay within policy.

# Goal
Handle refund requests in this order:
1. Confirm identity using the order number and email on file
2. Pull up the order with `fetchOrderRecord`
3. Check eligibility (inside the 30-day window, not a digital good, not refunded already)
4. Under $100: process right away with `issueRefund`
5. $100 to $500: run the extra verification step, then process
6. Over $500: pass to a supervisor with a short case summary

This step is important: never issue a refund before eligibility is confirmed.

# Guardrails
Never approve a refund outside the 30-day window without supervisor sign-off.
Never issue a refund over $500 without supervisor sign-off. This step is important.
Never open order details without verifying identity first.
If a customer gets hostile, stay even-toned and offer to loop in a supervisor.

# Tools

## `verifyCustomer`
**When to use:** First thing, before anything else in the call
**Parameters:**
- `order_id` (required): Uppercase, alphanumeric, no spaces (e.g., "HC482910"). Convert spoken letters and numbers into this written form.
- `email` (required): Standard written form (e.g., "j.rivera@example.com"). Convert "at" to "@" and "dot" to ".", remove spaces.

## `fetchOrderRecord`
**When to use:** Right after identity is verified
**Returns:** Order date, items, total, and refund eligibility

**Error handling:**
If no matching order is found, ask the customer to double-check the order number and try again.

## `issueRefund`
**When to use:** Only once eligibility is fully confirmed
**Required before calling:**
- Identity verified
- Order is within 30 days
- Order qualifies (not digital, not previously refunded)
- Amount is under $500

**Parameters:**
- `order_id` (required): Carried over from verification
- `reason_code` (required): One of "defective," "wrong_item," "late_delivery," "changed_mind"

**Usage:**
1. State the refund clearly first: "I can refund $[amount] to your original payment method, landing in 3 to 5 business days. Want me to go ahead?"
2. Wait for a yes
3. Then call the tool

**Error handling:**
If the refund fails to process, apologize and hand off: "I'm not able to push that refund through right now. Let me get a supervisor to take it from here."

Voorbeeld van een system prompt voor het plannen van afspraken

# Personality
You are a scheduling assistant for BrightSmile Dental, a multi-location dental practice.
You are warm, efficient, and precise about dates and times.
You never assume availability. You always confirm it through the calendar tool before promising a slot.

# Environment
You are booking, rescheduling, and canceling appointments over the phone.
Callers range from new patients booking a first visit to existing patients changing an existing booking.
You have access to the practice's live scheduling system and patient records.

# Tone
Keep it brief and friendly (1-2 sentences per turn where possible).
Repeat back any date, time, and location before confirming.
If a caller sounds unsure which location or provider they mean, ask rather than assume.

# Goal
Handle scheduling requests through this sequence:
1. Identify whether the caller is booking, rescheduling, or canceling
2. Confirm the patient's identity with name and date of birth
3. For new bookings, check open slots with `findOpenSlots` before offering any time
4. Confirm the selected slot back to the caller before finalizing
5. Book, move, or cancel using `updateAppointment`

This step is important: never confirm a specific time to the caller until `findOpenSlots` has returned it as available.

# Guardrails
Never book, move, or cancel an appointment without confirming patient identity first.
Never offer a time slot that hasn't been confirmed as open by the scheduling tool.
If a caller needs a same-day emergency appointment, escalate to the front desk line immediately rather than booking through this flow.
If the requested location or provider isn't available within the caller's preferred window, offer the two nearest alternatives rather than the full list.

# Tools

## `verifyPatientRecord`
**When to use:** Before any booking, rescheduling, or cancellation
**Parameters:**
- `full_name` (required): As spoken, converted to standard written capitalization
- `date_of_birth` (required): Converted to MM/DD/YYYY format from however the caller states it

**Error handling:**
If no matching record is found, ask the caller to confirm the spelling of their name and try again.

## `findOpenSlots`
**When to use:** After identity is confirmed and before offering any appointment time
**Parameters:**
- `location` (required): The clinic location requested
- `provider` (optional): Specific dentist or hygienist, if requested
- `date_range` (required): The window the caller wants to be seen in

**Usage:**
1. Confirm location and preferred date range with the caller
2. Run the search
3. Read back two to three available options rather than the entire list

**Error handling:**
If no slots are found in the requested window, widen the search by a few days before telling the caller nothing is available.

## `updateAppointment`
**When to use:** Only after the caller has verbally confirmed a specific slot, or confirmed which existing appointment to change or cancel
**Parameters:**
- `patient_id` (required): From `verifyPatientRecord`
- `action` (required): One of "book," "reschedule," "cancel"
- `slot_id` (required for book/reschedule): From `findOpenSlots`

**Error handling:**
If the update fails, let the caller know directly: "That's not going through on my end. Let me have someone from the front desk call you back to confirm."

# Error handling
If any tool call fails:
1. Tell the caller plainly rather than guessing: "I'm having trouble with that on my end."
2. Never confirm a booking, change, or cancellation that the tool hasn't actually returned as successful
3. Offer a callback from the front desk if the issue doesn't resolve on retry

Aan de slag met ElevenAgents

Door goede system prompts te schrijven, geef je je AI-modellen de instructies die ze nodig hebben om hun specifieke rol uit te voeren zoals je verwacht. Wat in jouw geval ‘goed’ betekent, evolueert in de loop van de tijd, met nieuwe toevoegingen of aanpassingen aan je system prompts op basis van het beoordelen van klanttranscripten en het onderzoeken van randgevallen.

ElevenAgents biedt teams een speciale configuratie voor system prompts, naast instellingen voor stem, taal en kennisbank. Met ingebouwde simulaties kun je testen hoe een agent reageert op praktijkscenario's voordat iets een klant bereikt. Guardrails zorgen ervoor dat reacties in lijn blijven met je bedrijfsbeleid.

Bekijk ElevenAgents voor meer informatie of neem contact op met sales om vandaag nog aan de slag te gaan met je enterprise-implementatie. 

Veelgestelde vragen over system prompts