Byg din første AI-agent i n8n: kvalificering af kundeemner fra start til slut

Noden n8n AI Agent giver en model mulighed for at vælge mellem konfigurerede værktøjer. Fleksibiliteten medfører ikke-deterministisk adfærd og flere mulige fejlkilder, så brug kun en agent, når enklere deterministisk routing ikke er tilstrækkelig.

Denne artikel beskriver et design til kvalificering af kundeemner. Arbejdsgangen modtager et kundeemne, henter tilladt kontekst, foreslår scorer og et udkast, validerer resultatet og sender det til menneskelig gennemgang. Det er hverken en arbejdsgang, der kan importeres, eller en dokumenteret kørsel. Accepttestene nedenfor angiver, hvad der stadig mangler, før løsningen fungerer fra ende til anden.

Vi antager, at du har installeret n8n, enten på din egen server eller via n8n Cloud, og at du har en fungerende API-nøgle til Claude eller OpenAI. Hvis du er ny i n8n, bør du først gennemgå den grundlæggende vejledning.

Designet følger også OWASPs advarsel om overdreven handlefrihed: Begræns værktøjernes rettigheder og agentens autonomi, og kræv godkendelse i selve arbejdsgangen før handlinger med konsekvenser. Hvis oplysningerne om kundeemner stammer fra en tredjepart eller skal bruges til opsøgende salg, skal du kontrollere kilden, oplysningskravene, det retlige grundlag, fravalgslisterne og reglerne for den valgte kanal før indsamling eller kontakt. Europa-Kommissionen forklarer, at tredjepartsdata ikke automatisk må genanvendes til markedsføring.

Lad ikke den første version automatisk sende svar til reelle kundeemner. Send udkast til menneskelig gennemgang, indtil du har logfiler, idempotens, scoregrænser og nok gennemgåede kørsler til at vide, at arbejdsgangen fungerer med uordnede inddata.

Det, vi bygger

Arbejdsgangen:

1. Et nyt kundeemne ankommer via en webhook (fra en formular, et arrangement, et CRM-system osv.).
2. Agenten supplerer kundeemnet med virksomhedsoplysninger ved hjælp af websøgning.
3. Den scorer kundeemnet på tre dimensioner: match, hensigt og hastegrad.
4. Den udarbejder et personligt svar.
5. Baseret på resultatet gør den enten:
   • Sætter et svar og et forslag til CRM-opdatering i kø til godkendelse for kundeemner med høj sikkerhed og et stærkt match.
   • Udarbejder et svar til menneskelig gennemgang og sender en Slack-notifikation for kundeemner i mellemgruppen.
   • Eller nøjes med at logge og underrette uden at svare, når matchet er svagt.

Dele af mønsteret kan genbruges til prioritering med begrænsede konsekvenser, men hvert nyt domæne kræver sin egen analyse af data, fejl, rimelighed og behovet for faglig gennemgang. Genbrug ikke et scoringsdesign fra salg til beslutninger om ansættelse, sundhed, jura, økonomi, børns sikkerhed eller byggeri.

Det tilhørende JSON-skema, som artiklen linker til, definerer inputdataene. Brug det til at validere webhook-inputtet, før agentnoden ser det.

Tilføj en valideringskontrol før agenten

Webhooken bør ikke videresende vilkårlige formulardata direkte til agenten. Indsæt et valideringstrin mellem udløseren og agenten:

Denne kontrol beskytter arbejdsgangen mod ugyldige indsendelser, gentagne webhook-forsøg og promptinjektion skjult i formularfelter. Agenten kan stadig læse beskeden, men det er arbejdsgangen, der afgør, om posten er gyldig nok til at blive behandlet.

Den mentale model: agent = stor sprogmodel (LLM) + værktøjer + løkke

Før vi bygger, skal begrebet være klart.

En »agent« betyder i 2026 en stor sprogmodel, der kan bruge værktøjer. I stedet for at producere ét svar vælger modellen, hvilke handlinger, kaldet værktøjer, den vil udføre. Når et værktøj har returneret et resultat, vurderer modellen det og vælger næste skridt: et andet værktøj, endnu et trin eller et endeligt svar.

n8ns AI-agent-node implementerer denne løkke. Du giver modellen:

• En systemprompt med instruktioner og tone.
• En brugerprompt med input til den aktuelle kørsel.
• Et sæt af værktøjer (andre n8n-noder eller underarbejdsgange, som modellen kan kalde).

Modellen afgør, hvilke værktøjer der skal kaldes, i hvilken rækkefølge og med hvilke argumenter. Når hvert værktøj har returneret et resultat, vurderer modellen situationen igen. Når den vurderer, at opgaven er løst, returnerer den et endeligt svar.

Dette er fundamentalt anderledes end en statisk arbejdsgang, fordi rækkefølgen af trin bestemmes af modellen og ikke af dig. Færdigheden inden for agentdesign ligger i:

1. At give modellen de rigtige værktøjer (hverken for få eller for mange).
2. At skrive en systemprompt, der afgrænser agentens adfærd.
3. At tilføje sikkerhedsforanstaltninger, så agenten ikke kører af sporet.
4. At designe resultatet, så efterfølgende noder kan bruge det pålideligt.

Trin 1: Udløseren

Åbn n8n og opret en ny arbejdsgang. Udløseren:

• Node: Webhook
• HTTP-metode: POST
• Svartilstand: »Når den sidste node er færdig«
• Sti: noget i stil med /lead-triage

Denne webhook modtager indsendelser af kundeemner. n8n giver dig en URL, som du kan angive som destination for formularindsendelser eller udgående webhooks fra dit CRM-system.

Til testen skal du gemme arbejdsgangen én gang, så webhook-URL’en bliver aktiv, og have et eksempel på inputdata klar. Data fra en typisk webhook til kundeemner kan se sådan ud:

{
  "name": "Anna Lehtinen",
  "email": "anna@somecompany.fi",
  "company": "Some Company OÜ",
  "role": "Head of Marketing",
  "message": "Interested in your AI consulting services. We have a team of 10 and need help with prompt engineering training.",
  "source": "website-form",
  "timestamp": "2026-05-15T14:30:00Z"
}

Klik på »Test step«, og indsend testdataene for at se dem flyde ind i arbejdsgangen.

Trin 2: AI Agent-noden

Tilføj en AI-agent-node efter webhooken. Konfigurer den:

• Agent / Tools Agent: De aktuelle n8n AI Agent-noder (1.82+) viser ikke længere en rullemenu til valg af Agent Type; de kører som en Tools Agent. Tilslut en chatmodel og værktøjerne nedenfor. I ældre skabeloner, der stadig viser Agent Type, skal du vælge Tools Agent. Conversational og andre tidligere agenttyper er fjernet.
• Chatmodel: Claude (Anthropic) eller OpenAI. Begynd med den aktuelle generelle model hos din udbyder, og skift først til en hurtigere eller mere kapabel model, når dine evalueringer berettiger det. Tilstande med øget ræsonneringsindsats kan øge både latenstid og omkostninger for hvert agenttrin.
• Hukommelse: Ingen til tilstandsløs prioritering, hvor hver henvendelse er uafhængig. Brug en hukommelsesnode til agentsamtaler i flere trin.
• Systemmeddelelse: Her defineres agentens adfærd. Brug skabelonen nedenfor.
• Brugermeddelelse: Hent dataene om kundeemnet fra webhooken.

Systemmeddelelsen:

Du er en agent til kvalificering af kundeemner hos [Your Company Name], en AI-konsulentvirksomhed.

Din opgave er at behandle indkommende kundeemner og producere et struktureret forslag til prioritering.

For hvert kundeemne skal du:

1. Brug værktøjet `enrich_lead` til at indsamle kontekst om virksomheden.
2. Vurdér kundeemnet på tre dimensioner:
   - Match: matcher kundeemnet vores ideelle kundeprofil?
     - Virksomheder med 10-200 ansatte inden for B2B, produktion eller professionelle services.
     - Roller i marketing, drift, ingeniørledelse eller ledelsesniveau.
   - Hensigt: hvor seriøs er henvendelsen?
     - "Nysgerrig" kontra "i gang med at vurdere muligheder" kontra "klar til at købe."
   - Hastegrad: er der en angivet eller underforstået tidsramme?
3. Brug værktøjet `score_lead` til at gemme vurderingerne.
4. Brug værktøjet `draft_response` til at producere et personligt svar.
5. Brug værktøjet `propose_route` med en af følgende: "review_priority", "human_review", "log_only".

Routingregler (vurder dem i denne rækkefølge; det første match gælder):
- "review_priority" hvis Match >= 7/10 OG Hensigt >= 7/10. Svaret får prioriteret menneskelig gennemgang.
- "human_review" hvis Match >= 5/10 ELLER Hensigt >= 5/10. En person kontrollerer det før afsendelse.
- "log_only" ellers (Match < 5/10 OG Hensigt < 5/10). Vi registrerer det blot og går videre.

Opfind aldrig oplysninger. Hvis noget er uklart, skal du markere [unclear] i begrundelsen for vurderingen.

Afslut altid ved at returnere et JSON-objekt med:
{
  "fit_score": <1-10>,
  "intent_score": <1-10>,
  "urgency_score": <1-10>,
  "reasoning": "<2-3 sætninger>",
  "drafted_response": "<the email body>",
  "routing": "<review_priority|human_review|log_only>"
}

Bemærk strukturen. Vi har:

• En klar opgavebeskrivelse.
• En eksplicit proces (trin 1-5).
• Eksplicitte vurderingskriterier.
• Eksplicit routinglogik.
• Et obligatorisk resultatformat.

Agenten vil ikke altid følge dette perfekt. Men jo mere konkret systemmeddelelsen er, desto mere pålideligt udfører den samme struktur hver gang.

JSON-objektet er ikke tilstrækkeligt i sig selv. Tilføj et valideringstrin efter agentnoden, og afvis kørsler, hvor scorer mangler, routingværdien ligger uden for den tilladte enum, eller svarudkastet er tomt.

Trin 3: Værktøjerne

Agenten har brug for værktøjer, den kan kalde. I n8n konfigureres de under agentnoden og kan være:

• Underarbejdsgange.
• HTTP-anmodninger.
• Indbyggede værktøjsnoder.

Lad os bygge fire værktøjer til vores agent.

Værktøj 1: enrich_lead

En underarbejdsgang, der:

1. Modtager et firmanavn og et e-maildomæne som input.
2. Bruger en godkendt søge- eller virksomhedsdata-API, hvis vilkår tillader brugen.
3. Returnerer strukturerede påstande med kanoniske kilde-URL’er og hentningsdatoer; ukendt størrelse eller identitet forbliver uoplyst.

Værktøjets beskrivelse (som agenten læser for at afgøre, hvornår den skal kalde det):

Henter tilladt offentlig kontekst om en virksomhed, der er registreret som kundeemne. Input: virksomhedsnavn og e-maildomæne. Resultat: verificerede påstande med kilde-URL og hentningsdato samt oplysninger om tvetydighed og fejl. Udled ikke identitet, størrelse eller nyheder uden en kilde.

Værktøj 2: score_lead

Et deterministisk valideringsværktøj, der:

• Modtager foreslåede scorer og kontrollerer datatype, interval, påkrævet begrundelse og tilladte etiketter.
• Returnerer valideringsfejl eller et normaliseret scoreobjekt.
• Har ingen database, regneark, CRM, e-mail eller andre skriveadgangsoplysninger.

Gem først noget, når agentens endelige resultat består den samme skemavalidering på serversiden.

Værktøjets beskrivelse:

Validerer foreslåede scorer for kundeemnet uden at gemme dem. Input: fit_score, intent_score, urgency_score og begrundelse. Resultat: {valid, errors, normalized_scores}. Værktøjet kan ikke skrive poster eller sende beskeder.

Værktøj 3: draft_response

En underarbejdsgang, der modtager konteksten om kundeemnet og scorerne som input og producerer et personligt e-mailudkast. Underarbejdsgangen kalder internt en anden AI-node med en specifik prompt til udkastet:

Udarbejd et personligt svar på en B2B-henvendelse. Input: kundeemnets oprindelige besked, resuméet af de supplerende virksomhedsoplysninger og scorerne for match, hensigt og hastegrad.

Tone: varm og direkte, uden virksomhedsklichéer. Anerkend den konkrete henvendelse. Henvis kun til de supplerende oplysninger, når påstanden har en kilde og er relevant; udelad den ellers. Afslut med et foreslået næste skridt, som et menneske kan gennemgå.

Længde: 80-120 ord.

Værktøjets beskrivelse:

Udarbejder et personligt e-mailsvar til kundeemnet. Input: kundeemnets besked, resuméet af de supplerende oplysninger og scorerne. Resultat: et e-mailudkast.

Værktøj 4: propose_route

Dette værktøj registrerer en af tre foreslåede ruter; det sender ikke e-mail eller skriver til CRM-systemet:

• review_priority: placér udkastet i køen til prioriteret menneskelig gennemgang.
• human_review: placér udkastet i den almindelige kø til menneskelig gennemgang.
• log_only: registrér resultatet af prioriteringen uden at forberede en udgående handling.

En deterministisk Switch-node efter skemavalideringen håndhæver den tilladte enum og sender review_priority og human_review til en godkendelseskø. Kun en separat underarbejdsgang med godkendelseskrav må foretage kundevendte skrivninger.

Implementér dette som en underarbejdsgang uden sideeffekter, der returnerer et forslagsobjekt. Når Agent-noden er færdig, afgør en deterministisk node til skemavalidering og en Switch-node, hvilken gren der må gemme forslaget. Ingen af grenene må nå en afsendelsesnode uden den separate godkendelsesarbejdsgang.

Værktøjets beskrivelse:

Foreslår en rute. Input: routingbeslutning (review_priority, human_review eller log_only), scorer, begrundelse og udkast. Resultat: et objekt i hukommelsen til deterministisk skemavalidering. Værktøjet kan ikke gemme data permanent, sende e-mail eller opdatere CRM-systemet.

Trin 4: Test agenten

Når agenten er konfigureret, og de fire værktøjer er tilknyttet, skal du køre en test med eksempeldataene.

Det, du bør se i n8ns udførelsesvisning:

1. Webhooken modtager inputdataene.
2. AI-agenten starter.
3. Agenten kalder enrich_lead — du ser værktøjet køre og returnere et resultat.
4. Agenten vælger næste trin. Afhængigt af model og indstillinger kan loggen fra mellemtrinnet være skjult.
5. Agenten kalder score_lead.
6. Agenten kalder draft_response.
7. Agenten kalder propose_route med en af de tre routingmuligheder.
8. Agenten returnerer det endelige JSON.

Hvis der opstår en fejl, viser n8ns fejlsøgningspanel beskederne mellem agenten og dens værktøjer. De mest almindelige problemer:

• Værktøjsbeskrivelsen er ikke præcis nok. Modellen kan ikke afgøre, hvornår værktøjet er relevant. Gør beskrivelsen mere konkret.
• Værktøjets input- og resultatskema passer ikke sammen. Agenten kan ikke videregive de rigtige argumenter. Beskriv skemaet eksplicit.
• Agenten kører i en endeløs løkke. Den bliver ved med at kalde værktøjer uden at nå et resultat. Sæt en øvre grænse for antallet af iterationer, og gennemgå systemprompten.

Trin 5: Tilføj sikkerhedsforanstaltninger

En ren agent er usikker i produktion. Seks sikkerhedsforanstaltninger, du skal tilføje, før du stoler på den med ægte trafik:

1. Maksimalt antal iterationer. Fastlæg en endelig grænse ud fra det mindste antal, som dine vellykkede evalueringsscenarier kræver. Test, at en overskridelse sender sagen videre til et menneske og ikke efterlader delvise sideeffekter.

2. Godkendelsespunkt for hvert foreslået svar. review_priority ændrer rækkefølgen i køen; det giver ikke tilladelse til at sende. Hold kundekommunikation bag en autentificeret menneskelig godkendelse, indtil en særskilt godkendt politik siger noget andet, og udled aldrig sikkerhed alene af, hvor mange uger der er gået.

3. Liste over tilladte udgående handlinger. Konfigurér CRM- og e-mailværktøjerne, så de kun handler på poster, der matcher det forventede mønster. Det hjælper med at forhindre agenten i at sende e-mail til forkerte adresser eller oprette poster om uvedkommende personer.

4. Logning. Registrér godkendte metadata for hver kørsel: en stabil reference til kørslen og kundeemnet, versioner af arbejdsgangen og modellen, værktøjsnavne og resultater, valideringsresultat, rute, godkender, genforsøg og fejl. Rå input om kundeemner, supplerende virksomhedsoplysninger, udkast og værktøjsargumenter indeholder personlige eller fortrolige data og kræver en særskilt beslutning om formål, redigering, adgang og opbevaring.

5. Omkostningsbegrænsninger. Begræns antallet af agentiterationer, og sæt tidsgrænser i arbejdsgangen. Konfigurér desuden advarsler eller grænser for forbrug og kald hos modeludbyderen. Grænserne i n8n-planen beskrives som kørsler og funktioner; antag ikke, at n8n Cloud håndhæver et dagligt budget for en API-nøgle fra din egen modeludbyder. Overvåg forbruget hos udbyderen, og test nødstopfunktionen.

6. Beslutningsejerskab. Modellen kan anbefale review_priority, human_review eller log_only; arbejdsgangen håndhæver den endelige regel. Behold routing-enummet, scoretærsklerne og godkendelseskravene uden for prompten, så de kan testes og er synlige.

Trin 6: Produktionsoptimering og sikring

Et par mønstre, der gør en fungerende prototype til noget, du kan stole på:

Idempotens. Sørg for, at det samme kundeemne ikke kan oprette dublerede poster eller beskeder, hvis det behandles to gange, for eksempel efter en ny webhook-levering eller en manuel genkørsel. En læs-og-skriv-kontrol er sårbar over for samtidighedsfejl: Opret en unik nøgle atomisk i databasen, og brug den samme nøgle ved alle efterfølgende skrivninger. Følg designet med atomisk krav, lease, godkendelsestoken og udbakke.

Fejlhåndtering. Omgiv hvert værktøjskald med fejlhåndtering. Hvis de supplerende oplysninger ikke er tilgængelige, eller virksomhedsidentiteten er tvetydig, skal arbejdsgangen markere de manglende data og sende sagen til menneskelig gennemgang. Den må ikke opfinde personlige oplysninger blot for at færdiggøre udkastet.

Observerbarhed. Følg centrale målinger: gennemsnitlig køretid, hyppighed af værktøjskald og andelen, der sendes til hver rute. Afvigelser er signaler, der skal undersøges.

Pilotgennemgang. Gennemgå hver kørsel i en afgrænset pilot med de nødvendige tilladelser, og sammenlign med det oprindelige kundeemne. Piloten skal dække kildetyper, sprog, manglende felter, tvetydige virksomheder, injektionsforsøg og prioriteringsklasser. Registrér fejl i supplerende oplysninger, scoring, routing, tidsfrister og udkast. Et fast antal på 50 kørsler dokumenterer ikke i sig selv et bestemt pålidelighedsniveau.

En håndhævelig nødstopfunktion. Placér styringen af kørsler og alle komponenter, der udløser sideeffekter, uden for modellen, så en autoriseret operatør kan sætte nye og genoptagne kørsler på pause uden at genudrulle systemet. Test, at den deaktiverede tilstand blokerer både afsendelser i kø og igangværende afsendelser. En promptinstruktion eller værdi, som agenten blot »kontrollerer«, er ikke et nødstop.

Den vigtigste designbeslutning: hvilke værktøjer der skal gives til agenten

Værktøjssættet har stor betydning for agentens kvalitet. Der er to typiske fejl:

For få værktøjer. Agenten kan ikke udføre arbejdet og kan forsøge at kompensere for manglende funktioner ved at opfinde oplysninger eller handlinger.

For mange værktøjer. Agenten bliver forvirret, vælger det forkerte værktøj eller spilder iterationer på udforskning. Kvaliteten forringes.

Et godt princip: begynd med det mindst mulige værktøjssæt, og tilføj kun flere værktøjer, når agenten tydeligt har brug for dem.

Til prioritering af kundeemner er de fire valgte værktøjer et rimeligt udgangspunkt. Du kan overveje at tilføje:

• Et værktøj som lookup_existing_customer til at kontrollere, om kundeemnet allerede er kunde.
• Et værktøj med navnet schedule_meeting, der integreres med din kalender.
• Et oversættelsesværktøj, hvis henvendelserne kommer på flere sprog.

Men hvert nyt værktøj giver agenten endnu et valg. Hvert værktøj skal derfor have en klar begrundelse.

Mønstre, der kan generaliseres

De samme styringsprincipper kan hjælpe andre triageringsarbejdsgange, men etiketterne og handlingerne nedenfor er ikke overførbare uden domænegennemgang:

Håndtering af supportsager. Hent tilladt kundehistorik, og foreslå kategori og prioritet. Hold handlinger vedrørende konti, sikkerhed, refusioner, rettigheder og kundemeddelelser bag politikker og menneskelig godkendelse.

Arbejdsgange ved ansættelse. Tilpas ikke leadscoringen til automatisering af jobsamtaler eller afslag. Ansættelsesbeslutninger kan skabe juridiske risici og risiko for diskrimination og kræver kvalificeret HR- og juridisk gennemgang, adgangskontrol, vurdering af bias, gennemsigtighed over for medarbejdere og ansøgere samt meningsfuld menneskelig beslutningstagning.

Håndtering af presseforespørgsler. Erstat de supplerende virksomhedsoplysninger med lookup_publication og routing med et forslag om prioriteret svar.

Routing af kundefeedback. Erstat de supplerende virksomhedsoplysninger med holdningsanalyse og produktkategorisering.

Indkøbsanmodninger. Erstat de supplerende oplysninger med leverandørsøgning, scoring med kontrol af politikoverholdelse og routing med godkendelsesarbejdsgange.

En genanvendelig form til opgaver med begrænsede konsekvenser er: Validér en indgående hændelse → hent mindst mulig tilladt kontekst → anmod om et struktureret forslag → validér deterministisk → lad autoriserede politikker og mennesker træffe beslutningen → udfør via idempotente værktøjer med adgangskontrol. Modellen foreslår; den ejer ikke beslutningen med konsekvenser.

Når du ikke skal bruge en AI-agent

Nogle arbejdsgange har ikke fordel af en AI-agent. Hvis logikken er fuldt deterministisk — »gør altid A, derefter B og til sidst C« — er en almindelig n8n-arbejdsgang uden en agent hurtigere, billigere og mere pålidelig.

Agenten fortjener sin plads, når:

• Antallet af mulige stier er stort.
• Den rigtige vej afhænger af faglig dømmekraft, ikke strenge regler.
• Nogle beslutninger kræver, at du syntetiserer information fra flere kilder.

Hvis dit beslutningstræ kun består af nogle få hvis-så-ellers-betingelser, skal du bruge almindelige betingelsesnoder. Gem agenten til de tilfælde, hvor denne logik bliver uoverskuelig.

Byg det én gang på en reel opgave

En AI-agent i n8n er en arbejdsgang, hvor en model kan vælge blandt konfigurerede værktøjer. Et produktionsdesign begrænser dette valg og sikrer, at mennesker med ansvar samt deterministiske retningslinjer har kontrollen over afgørende beslutninger.

Designet er først færdigt efter en test med en dubleret levering, en test af ugyldigt output, en test af timeout hos udbyderen, en test med afvist godkendelse og en kontrol af, at afsendelsesnoden ikke kan nås uden godkendelse. Mål byggetid, latenstid, rettelsesfrekvens og omkostninger på din egen installation; artiklen lover hverken en bestemt opsætningstid eller et bestemt produktionsresultat.

Byg og test først med syntetiske data eller ikke-produktionsdata, som du har tilladelse til at bruge. Genbrug kontrolmønsteret — snævre værktøjer, skemaer, idempotens, stopregler og godkendelsespunkter — men gennemfør domæne- og risikoanalysen på ny for hver arbejdsgang.