Byg din første AI-agent i n8n: en komplet arbejdsgang til leadtriage

Den mest undervurderede funktion i n8n er AI-agentnoden. Den gør en statisk arbejdsgang (»når X sker, gør Y«) mere fleksibel: AI-modellen beslutter, hvilke handlinger der skal udføres ud fra situationen.

I denne artikel bygger vi en virkelig, fungerende agent fra ende til anden: et system til leadtriage, der modtager nye leads, beriger dem med data, scorer dem, skriver et udkast til et personligt svar og sender dem det rette sted hen. Til sidst forstår du både mekanikken i n8n-agenter og de designmønstre, der adskiller en nyttig agent fra en skrøbelig demo.

Vi forudsætter, at du har installeret n8n — enten på din egen server eller via n8n.cloud — og har en fungerende API-nøgle til Claude eller OpenAI. Hvis n8n er nyt for dig, bør du først gennemgå den grundlæggende vejledning.

Lad ikke den første version sende svar automatisk til virkelige leads. Send udkast til menneskelig kontrol, indtil du har logfiler, idempotens, scoregrænser og tilstrækkeligt mange gennemgåede kørsler til at vide, hvordan arbejdsgangen opfører sig med rodede input.

Det bygger vi

Arbejdsgangen:

1. Et nyt lead ankommer via en webhook (fra en formular, et arrangement, et CRM-system osv.).
2. Agenten beriger leadet med virksomhedsoplysninger (ved hjælp af websøgning).
3. Den scorer leadet på tre dimensioner: match, intention og hast.
4. Den skriver et udkast til et personligt svar.
5. Ud fra scoren gør den ét af følgende:
   • Svarer automatisk og opretter en CRM-post (for leads med høj sikkerhed og godt match),
   • Skriver et svarudkast til menneskelig kontrol og sender en Slack-notifikation (for leads i mellemgruppen),
   • Eller nøjes med at logge og underrette uden at svare (for leads med dårligt match).

Mønsteret kan generaliseres. Erstat »leadtriage« med »sortering af supportsager«, »screening af kandidater«, »håndtering af pressehenvendelser« eller »routing af kundefeedback« — strukturen er den samme.

Det tilhørende JSON-skema, som er linket fra denne artikel, definerer inputpayloaden. Brug det til at validere webhook-inputtet, før agentnoden ser det.

Tilføj en valideringsport før agenten

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

Denne port beskytter arbejdsgangen mod fejlformaterede indsendelser, gentagne webhook-genforsøg og promptinjektion skjult i formularfelter. Agenten kan stadig læse beskeden, men arbejdsgangen afgør, om posten er gyldig nok til behandling.

Tankemodellen: agent = LLM + værktøjer + løkke

Før vi bygger, skal begrebet være på plads.

En »agent« i 2026 er en LLM, der kan bruge værktøjer. I stedet for at generere ét svar beslutter modellen, hvilke handlinger — kaldet »værktøjer« — den vil kalde. Når et værktøj har returneret et resultat, ser modellen resultatet og beslutter næste skridt: et nyt værktøj, et andet trin eller et endeligt svar.

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

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

Modellen beslutter, hvilke værktøjer den vil kalde, i hvilken rækkefølge og med hvilke argumenter. Efter hvert værktøjskald vurderer modellen situationen igen. Når den vurderer, at arbejdet er udført, returnerer den et endeligt svar.

Dette adskiller sig grundlæggende fra en statisk arbejdsgang, fordi modellen bestemmer trinrækkefølgen, ikke dig. Kompetencen i 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 dens adfærd.
3. At tilføje sikkerhedsforanstaltninger, så den ikke kommer på afveje.
4. At designe outputtet, 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 Method: POST
• Response Mode: “When last node finishes”
• Path: noget i stil med /lead-triage

Denne webhook modtager leadindsendelser. n8n giver dig en URL, som du kan angive som destination for indsendelser fra din formular eller dit CRM-systems udgående webhook.

Gem arbejdsgangen én gang under testen, så webhook-URL’en bliver aktiv, og hav en eksempelpayload klar. En typisk webhookpayload for et lead 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 testpayloaden for at se dataene strømme ind.

Trin 2: Noden AI Agent

Tilføj en node af typen AI Agent efter webhooken. Konfigurer den:

• Agent Type: Conversational (eller “Tools Agent” i nyere versioner — vælg den variant, der understøtter værktøjskald).
• Chat Model: Claude (Anthropic) eller OpenAI. Til en agentarbejdsgang er Claude Sonnet 4.5 eller GPT-5 gode standardvalg. Reasoning-modeller fungerer, men er langsommere i agentløkker.
• Memory: None til tilstandsløs triage (hvert lead er uafhængigt). Brug en memory-node til agentsamtaler over flere runder.
• System Message: Her defineres agentens adfærd. Brug skabelonen nedenfor.
• User Message: Hent leaddata fra webhooken.

Systembeskeden:

Du er en agent til leadtriage for [Your Company Name], en AI-konsulentvirksomhed.

Din opgave er at behandle indgående leads og generere en struktureret triagebeslutning.

For hvert lead skal du:

1. Bruge værktøjet `enrich_lead` til at indsamle kontekst om virksomheden.
2. Score leadet på tre dimensioner:
   - Match: Passer leadet til vores ideelle kundeprofil?
     - Virksomheder med 10-200 medarbejdere inden for B2B, produktion eller professionelle tjenester.
     - Roller inden for marketing, drift, teknisk ledelse eller virksomhedsledelse.
   - Intention: Hvor seriøs er henvendelsen?
     - "Bare nysgerrig" kontra "aktivt i gang med at evaluere" kontra "klar til at købe".
   - Hast: Er der angivet eller antydet en tidsfrist?
3. Bruge værktøjet `score_lead` til at registrere scorerne.
4. Bruge værktøjet `draft_response` til at generere et personligt svar.
5. Bruge værktøjet `route_lead` med én af følgende værdier: "auto_reply", "human_review", "log_only".

Routingregler:
- "auto_reply", hvis Match >= 7/10 OG Intention >= 7/10. Svaret bliver sendt automatisk.
- "human_review", hvis Match >= 5/10 ELLER Intention >= 5/10. Et menneske kontrollerer svaret, før det sendes.
- "log_only", hvis Match < 5/10 OG Intention < 5/10. Vi registrerer blot leadet og går videre.

Opfind aldrig oplysninger. Markér [unclear] i begrundelsen for scoren, hvis noget er uklart.

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

Bemærk strukturen. Vi har:

• En tydelig opgavebeskrivelse.
• En eksplicit proces (trin 1-5).
• Eksplicitte scoringskriterier.
• Eksplicit routinglogik.
• Et påkrævet outputformat.

Agenten følger ikke altid dette perfekt. Jo mere konkret systembeskeden er, desto mere pålideligt udfører den 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, routing ligger uden for den tilladte enum, eller svarudkastet er tomt.

Trin 3: Værktøjerne

Agenten skal have værktøjer, den kan kalde. I n8n konfigureres værktøjer under agentnoden og kan være:

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

Vi bygger fire værktøjer til agenten.

Værktøj 1: enrich_lead

En underarbejdsgang, der:

1. Modtager et virksomhedsnavn og et e-maildomæne som input.
2. Bruger en HTTP-node til at kalde en API til websøgning (Perplexity, Serper, Brave Search eller Tavily) for virksomheden.
3. Returnerer et resumé på 3 sætninger: hvad virksomheden laver, dens omtrentlige størrelse og eventuelle væsentlige nyheder fra den seneste tid.

Beskrivelsen af værktøjet, som agenten læser for at afgøre, hvornår det skal kaldes:

Beriger et lead ved at slå virksomheden op. Input: virksomhedens navn og e-maildomæne. Output: et kort resumé af, hvad virksomheden laver, dens omtrentlige størrelse og eventuel væsentlig kontekst fra den seneste tid.

Værktøj 2: score_lead

Et enkelt værktøj, der modtager agentens scorer og skriver dem et sted. Det kan være:

• En række i Google Sheets.
• En indsættelse i en database.
• Et kald til et CRM-API.

Til test er det lettest at tilføje en række i Google Sheets. Beskrivelsen af værktøjet:

Registrerer leadets scorer. Input: fit_score, intent_score, urgency_score, reasoning. Output: bekræftelse.

Værktøj 3: draft_response

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

Skriv et personligt svar på en B2B-henvendelse. Input: den oprindelige besked fra leadet, resuméet af de berigede virksomhedsdata og scorerne for match/intention/hast.

Tone: varm, direkte og uden virksomhedsklichéer. Anerkend den konkrete forespørgsel. Henvis til noget fra de berigede virksomhedsdata — ikke noget generisk. Slut med et konkret næste skridt, f.eks. “ville 15 minutter i næste uge passe?”.

Længde: 80-120 ord.

Beskrivelsen af værktøjet:

Skriver et udkast til et personligt e-mailsvar til leadet. Input: leadets besked, resuméet af de berigede data og scorerne. Output: et e-mailudkast.

Værktøj 4: route_lead

Den afsluttende routinghandling. Afhængigt af routingargumentet gør værktøjet ét af følgende:

• Sender e-mailen og opretter en CRM-post (auto_reply).
• Gemmer udkastet og sender en Slack-notifikation (human_review).
• Nøjes med at logge og oprette en CRM-post (log_only).

Det implementeres som en underarbejdsgang med en switch-node, der sender til tre forskellige grene ud fra argumentet.

Beskrivelsen af værktøjet:

Sender leadet videre ud fra triagebeslutningen. Input: routingbeslutningen (“auto_reply”, “human_review”, “log_only”) og svarudkastet. Output: bekræftelse.

Trin 4: Test agenten

Kør en test med eksempelpayloaden, når agenten er konfigureret, og de fire værktøjer er tilknyttet.

I n8ns visning af kørslen bør du se:

1. Webhook modtager payloaden.
2. AI Agent starter.
3. Agenten kalder enrich_lead — du kan se værktøjet blive kørt og returnere.
4. Agenten vælger næste trin (mellemresultater er muligvis synlige afhængigt af model og indstillinger).
5. Agenten kalder score_lead.
6. Agenten kalder draft_response.
7. Agenten kalder route_lead med én af de tre routingmuligheder.
8. Agenten returnerer det endelige JSON.

Hvis noget går galt, viser n8ns fejlfindingspanel beskederne mellem agenten og dens værktøjer. De mest almindelige problemer:

• Værktøjsbeskrivelsen er ikke specifik nok. Modellen kan ikke udlede, hvornår værktøjet er relevant. Gør beskrivelserne mere konkrete.
• Værktøjets input- og outputskema stemmer ikke overens. Agenten kan ikke sende de rigtige argumenter. Beskriv skemaet eksplicit.
• Agenten kører i løkke for evigt. Den bliver ved med at kalde værktøjer uden at nå frem til et resultat. Tilføj en grænse for det maksimale antal iterationer, og gennemgå din systemprompt igen.

Trin 5: Tilføj sikkerhedsforanstaltninger

En agent uden sikkerhedsforanstaltninger er ikke sikker i produktion. Tilføj disse seks sikkerhedsforanstaltninger, før du betror den virkelig trafik:

1. Maksimalt antal iterationer. Sæt agentens maksimale antal iterationer til et rimeligt niveau (10-20). Det forhindrer løkker, der løber løbsk, når agenten fortsætter med at kalde værktøjer uden at afslutte.

2. Godkendelsesport til auto_reply. Selv hvis agenten vælger “auto_reply”, skal beslutningen gå gennem en kø til menneskelig godkendelse i de første par uger. Kontrollér, at agentens beslutninger om automatiske svar faktisk er gode, før de sendes til kunder uden gennemgang.

3. Tilladelsesliste til udgående handlinger. Konfigurer CRM-værktøjet og e-mailværktøjet, så de kun behandler poster, der matcher det forventede mønster. Det forhindrer agenten i at sende e-mail til en forkert adresse eller oprette poster for andre end leads.

4. Logning. Log hver agentkørsel — input, alle værktøjskald og det endelige output. Brug n8ns indbyggede kørselslogfiler, eller send data til en særskilt logningstjeneste. Når noget går galt, bruger du logfilerne til fejlfinding.

5. Omkostningsgrænser. Fastlæg et dagligt tokenbudget. AI-agenter kan løbe løbsk — en forkert konfigureret løkke kan bruge $50 på API-kald i én enkelt dårlig kørsel. n8n cloud har funktionen indbygget; ved egen hosting skal du overvåge forbruget på din API-nøgle.

6. Ejerskab over beslutninger. Modellen kan anbefale auto_reply, human_review eller log_only, men arbejdsgangen skal håndhæve den endelige regel. Hold routing-enum, scoregrænser og godkendelseskrav uden for prompten, så de kan testes og er synlige.

Trin 6: Produktionsmodning

Nogle få mønstre gør en fungerende prototype til noget, du kan have tillid til:

Idempotens. Sørg for, at gentagen behandling af det samme lead — på grund af et nyt webhookforsøg eller en manuel genkørsel — ikke opretter dubletter. Tilføj en kontrol i begyndelsen af arbejdsgangen: »Er dette lead blevet behandlet før?«

Fejlhåndtering. Omgiv hvert værktøjskald med fejlhåndtering. Hvis API’en til berigelse er nede, bør agenten ikke bryde sammen — den bør fortsætte med færre oplysninger og markere de manglende data.

Observerbarhed. Følg centrale målinger: gennemsnitlig kørselstid, hyppigheden af værktøjskald og procentdelen, der sendes til hver rute. Afvigelser er signaler.

Gennemgang af kørsler. Gennemgå alle kørsler for de første 50 virkelige leads op imod det oprindelige lead. Registrer forkert berigelse af virksomhedsdata, forkert score, forkert rute, manglende tidsfrist og dårlig kvalitet i udkastet. Reducer ikke den menneskelige kontrol, før disse fejltyper er sjældne og forstået.

En »nødstopsknap«. Sørg for, at agenten kan slås fra uden en ny udrulning. Det kan være en enkel miljøvariabel eller en arbejdsgangskontakt, som agenten kontrollerer først. Det er nyttigt, når du opdager en dårlig beslutning i produktion og vil sætte driften på pause.

Den vigtigste designbeslutning: hvilke værktøjer agenten får

Den største faktor for agentens kvalitet er værktøjssættet. Der er to fejltyper:

For få værktøjer. Agenten kan ikke udføre sin opgave. Den forsøger at skjule de manglende funktioner, ofte ved at hallucinere.

For mange værktøjer. Agenten bliver forvirret, vælger det forkerte værktøj eller spilder iterationer på at undersøge muligheder. Kvaliteten falder.

En god regel er: Begynd med det mindst mulige brugbare værktøjssæt, og tilføj kun værktøjer, når agenten beviseligt har brug for dem.

Til leadtriage er de fire valgte værktøjer omtrent de rigtige. Du kan tilføje:

• Et værktøj ved navn “lookup_existing_customer”, som kontrollerer, om leadet allerede er kunde.
• Et værktøj ved navn “schedule_meeting”, som integreres med din kalender.
• Et værktøj ved navn “translate”, hvis leads kommer på flere sprog.

Men hvert nyt værktøj er endnu en beslutning, agenten skal træffe. Hvert værktøj skal reelt gøre sig fortjent til sin plads.

Mønstre, der kan generaliseres

Det, du har bygget til leadtriage, fungerer til mange andre anvendelser:

Sortering af supportsager. Erstat berigelse med “lookup_customer_history” og routing med “auto_solve / escalate / categorise”.

Screening af jobkandidater. Erstat berigelse med “parse_cv”, scoring med kriterier for match med rollen og routing med “interview / reject / flag for human review”.

Håndtering af pressehenvendelser. Erstat berigelse med “lookup_publication” og routing med et svar baseret på prioritet.

Routing af kundefeedback. Erstat berigelse med sentimentanalyse og produktkategorisering.

Indkøbsanmodninger. Erstat berigelse med opslag af leverandører, scoring med efterlevelse af politikker og routing med godkendelsesforløb.

Det underliggende mønster er altid det samme: en indgående hændelse → berig → score eller klassificer → skriv svarudkast → send videre. Agenten træffer beslutningerne; værktøjerne udfører dem.

Hvornår du IKKE skal bruge en agent

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

Agenten gør sig fortjent til sin plads, når:

• Antallet af mulige veje er stort.
• Den rigtige vej afhænger af en vurdering, ikke af strenge regler.
• Nogle beslutninger kræver, at oplysninger fra flere kilder sammenfattes.

Hvis dit beslutningstræ består af nogle få if-then-else-sætninger, skal du blot bruge if-then-else-noder. Gem agenten til tilfælde, hvor if-then-else bliver uoverskueligt.

Byg den én gang på virkeligt arbejde

En AI-agent i n8n er en arbejdsgang, hvor modellen ud fra et sæt værktøjer beslutter, hvilke handlinger den skal udføre og i hvilken rækkefølge. Når den er bygget godt, håndterer den den type vurderingstungt arbejde med flere trin, som tidligere krævede menneskelig kontrol i processen.

Arbejdsgangen til leadtriage, som vi byggede, kræver cirka to timers arbejde for en person, der ikke tidligere har bygget n8n-agenter, plus nogle få ugers finjustering på virkelige data. Gevinsten er, at hvert indgående lead inden for få minutter bliver beriget, scoret, får skrevet et svarudkast og sendes videre, mens menneskelig kontrol kun bruges, hvor den faktisk tilfører værdi.

Byg den én gang på en virkelig arbejdsgang, der betyder noget for dig. Designmønsteret til agenter er en af de færdigheder, der giver størst udbytte i AI-arbejde i 2026.