Bygg din första AI-agent i n8n: ett komplett arbetsflöde för leadprioritering

AI Agent-noden i n8n låter en modell välja mellan konfigurerade verktyg. Den flexibiliteten tillför icke-determinism och fler möjliga fel, så använd en agent först när enklare deterministisk dirigering inte räcker.

Den här artikeln beskriver en design för leadkvalificering som tar emot ett lead, hämtar tillåten kontext, föreslår poäng och ett utkast, validerar resultatet och skickar det till mänsklig granskning. Det är varken ett importerbart arbetsflöde eller en rapporterad körning. Acceptanstesterna nedan definierar vad som återstår innan lösningen fungerar från början till slut.

Vi utgår från att du har installerat n8n (på en egen server eller via n8n Cloud) och har en fungerande API-nyckel för Claude eller OpenAI. Om n8n är nytt för dig bör du först gå igenom deras grundläggande introduktion.

Designen följer också OWASP:s varning om överdriven handlingsfrihet: minimera verktygsbehörigheter, minimera autonomi och kräv godkännande som arbetsflödet verkställer för åtgärder med konsekvenser. Om leaddata kommer från en tredje part eller ska användas för kontakt, kontrollera källa, information till den registrerade, rättslig grund, spärrlistor och kanalregler innan data läses in eller någon kontaktas. EU-kommissionen förklarar att data från tredje part inte automatiskt får återanvändas för marknadsföring.

Låt inte den första versionen skicka svar automatiskt till riktiga leads. Skicka utkasten till mänsklig granskning tills du har loggar, idempotens, poängtrösklar och tillräckligt många granskade körningar för att veta att arbetsflödet hanterar röriga indata korrekt.

Det här ska vi bygga

Arbetsflödet:

1. Ett nytt lead kommer in via en webhook (från ett formulär, ett evenemang, ett CRM-system och så vidare).
2. Agenten berikar leadet med företagsinformation (med hjälp av webbsökning).
3. Den poängsätter leadet utifrån tre dimensioner: lämplighet, avsikt och brådska.
4. Den skriver ett utkast till ett personligt meddelande.
5. Beroende på poängen gör den något av följande:
   • Köar ett svar och ett CRM-förslag för godkännande (för leads med hög lämplighet och hög säkerhet i bedömningen),
   • Skriver ett svarsutkast som en människa får granska och skickar en Slack-avisering (för medelprioriterade leads),
   • Eller loggar och aviserar utan att svara (för leads med låg lämplighet).

Delar av mönstret kan återanvändas för triage med små konsekvenser, men varje ny domän kräver en egen analys av data, fel, rättvisa och professionell granskning. Återanvänd inte en försäljningspoäng för beslut om anställning, vård, juridik, ekonomi, barns säkerhet eller byggarbete.

Det tillhörande JSON-schemat som länkas från den här artikeln definierar indatans nyttolast. Använd det för att validera webhook-indatan innan agentnoden får se den.

Lägg till en valideringsspärr före agenten

Webhooken ska inte skicka godtyckliga formulärdata direkt till agenten. Lägg in ett valideringssteg mellan utlösaren och agenten:

Den här spärren skyddar arbetsflödet mot felaktigt utformade inskick, upprepade webhookförsök och promptinjektioner som döljs i formulärfält. Agenten kan fortfarande läsa meddelandet, men arbetsflödet avgör om posten är tillräckligt giltig för att bearbetas.

Den mentala modellen: agent = LLM + verktyg + loop

Innan vi börjar bygga behöver vi förstå konceptet.

En ”agent” år 2026 är en LLM som kan använda verktyg. I stället för att skapa ett enda svar bestämmer modellen vilka åtgärder (som kallas ”verktyg”) den ska anropa. Efter varje verktygssvar ser modellen resultatet och bestämmer vad den ska göra härnäst – anropa ett nytt verktyg, utföra ett annat steg eller lämna ett slutligt svar.

AI Agent-noden i n8n implementerar den här loopen. Du ger modellen:

• En systemprompt (dess instruktioner och personlighet).
• En användarprompt (indata för den aktuella körningen).
• En uppsättning verktyg (andra n8n-noder eller underarbetsflöden som modellen kan anropa).

Modellen bestämmer vilka verktyg som ska anropas, i vilken ordning och med vilka argument. Efter varje verktygssvar gör modellen en ny bedömning. När den anser att den har gjort tillräckligt lämnar den ett slutligt svar.

Det här skiljer sig i grunden från ett statiskt arbetsflöde eftersom det är modellen, inte du, som bestämmer stegens ordning. Förmågan att utforma agenter handlar om att:

1. Ge modellen rätt verktyg (varken för få eller för många).
2. Skriva en systemprompt som avgränsar dess beteende.
3. Lägga till skyddsräcken så att den inte avviker från uppgiften.
4. Utforma utdata så att efterföljande noder kan använda dem på ett tillförlitligt sätt.

Steg 1: Utlösaren

Öppna n8n och skapa ett nytt arbetsflöde. Konfigurera utlösaren så här:

• Nod: Webhook
• HTTP-metod: POST
• Svarsläge: ”När den sista noden är klar”
• Sökväg: exempelvis /lead-triage

Den här webhooken tar emot inskickade leads. n8n ger dig en URL som du kan ange som mål för inskick från formuläret eller för utgående webhooks från CRM-systemet.

För att testa sparar du arbetsflödet en gång så att webhookens URL aktiveras och förbereder en exempelnyttolast. En typisk nyttolast från en webhook för leads kan se ut så här:

{
  "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"
}

Klicka på ”Testa steg” och skicka in testnyttolasten för att se hur data flödar in.

Steg 2: AI Agent-noden

Lägg till en AI Agent-nod efter webhooken. Konfigurera den så här:

• Agent / Tools Agent: De aktuella AI Agent-noderna i n8n (1.82+) visar inte längre någon rullista för Agent Type. De körs som Tools Agent. Anslut en chattmodell och verktygen nedan. I äldre mallar som fortfarande visar Agent Type väljer du Tools Agent. Conversational och andra äldre typer har tagits bort.
• Chattmodell: Claude (Anthropic) eller OpenAI. Börja med leverantörens aktuella allmänmodell och byt till en snabbare eller mer kapabel nivå först när dina utvärderingar motiverar det. Lägen för utökat resonemang kan öka både fördröjning och kostnad i varje agentsteg.
• Minne: Inget för tillståndslös leadkvalificering (varje lead är oberoende). Använd en minnesnod för agentsamtal i flera turer.
• Systemmeddelande: Här definieras agentens beteende. Använd mallen nedan.
• Användarmeddelande: Hämta leadinformationen från webhooken.

Systemmeddelandet:

Du är en agent för leadkvalificering hos [Ditt företagsnamn], ett AI-konsultföretag.

Din uppgift är att bearbeta inkommande leads och lämna ett strukturerat kvalificeringsbeslut.

För varje lead måste du:

1. Använda verktyget `enrich_lead` för att samla in bakgrundsinformation om företaget.
2. Poängsätta leadet utifrån tre dimensioner:
   - Lämplighet: motsvarar leadet vår ideala kundprofil?
     - Företag med 10-200 anställda inom B2B, tillverkning eller professionella tjänster.
     - Roller inom marknadsföring, verksamhet, teknisk ledning eller företagsledning.
   - Avsikt: hur seriös är förfrågan?
     - "Bara nyfiken" jämfört med "utvärderar aktivt" och "redo att köpa".
   - Angelägenhetsgrad: finns det en uttalad eller underförstådd tidsplan?
3. Använda verktyget `score_lead` för att registrera poängen.
4. Använda verktyget `draft_response` för att skriva ett personligt svar.
5. Använda verktyget `propose_route` med något av följande värden: "review_priority", "human_review", "log_only".

Dirigeringsregler (utvärdera i denna ordning; första matchningen gäller):
- "review_priority" om lämplighet >= 7/10 OCH avsikt >= 7/10. Svaret får prioriterad mänsklig granskning.
- "human_review" om lämplighet >= 5/10 ELLER avsikt >= 5/10. En människa kontrollerar svaret innan det skickas.
- "log_only" om lämplighet < 5/10 OCH avsikt < 5/10. Vi registrerar bara leadet och går vidare.

Hitta aldrig på information. Om något är oklart markerar du [oklart] i motiveringen till poängsättningen.

Avsluta alltid med att returnera ett JSON-objekt med:
{
  "fit_score": <1-10>,
  "intent_score": <1-10>,
  "urgency_score": <1-10>,
  "reasoning": "<2-3 meningar>",
  "drafted_response": "<e-postmeddelandets brödtext>",
  "routing": "<review_priority|human_review|log_only>"
}

Lägg märke till strukturen. Vi har:

• En tydlig arbetsbeskrivning.
• En explicit process (steg 1–5).
• Explicita poängkriterier.
• Explicit dirigeringslogik.
• Ett obligatoriskt utdataformat.

Agenten kommer inte alltid att följa detta perfekt. Men ju mer konkret systemmeddelandet är, desto tillförlitligare utför agenten samma typ av process varje gång.

JSON-objektet räcker inte i sig. Lägg till ett valideringssteg efter agentnoden och avvisa körningar där poäng saknas, dirigeringen ligger utanför tillåtna enum-värden eller svarsutkastet är tomt.

Steg 3: Verktygen

Agenten behöver verktyg att anropa. I n8n konfigureras verktygen under agentnoden och kan vara:

• Underarbetsflöden.
• HTTP-anrop.
• Inbyggda verktygsnoder.

Vi bygger fyra verktyg åt vår agent.

Verktyg 1: enrich_lead

Ett underarbetsflöde som:

1. Tar emot ett företagsnamn och en e-postdomän som indata.
2. Använder ett godkänt sök- eller företagsdata-API vars villkor tillåter användningen.
3. Returnerar strukturerade påståenden med kanoniska käll-URL:er och hämtningsdatum. Okänd storlek eller identitet förblir okänd.

Beskrivningen av verktyget (som agenten läser för att avgöra när det ska anropas):

Hämtar tillåten offentlig kontext om ett leadföretag. Indata: företagets namn och e-postdomän. Utdata: verifierade påståenden med käll-URL och hämtningsdatum samt oklarheter och fel. Dra inga slutsatser om identitet, storlek eller nyheter utan en källa.

Verktyg 2: score_lead

Ett deterministiskt valideringsverktyg som:

• Tar emot föreslagna poäng och kontrollerar typ, intervall, obligatorisk motivering och tillåtna etiketter.
• Returnerar valideringsfel eller ett normaliserat poängobjekt.
• Saknar behörighet att skriva till en databas, ett kalkylark, ett CRM-system, e-post eller något annat system.

Spara först när agentens slutliga utdata har klarat samma schema på serversidan.

Beskrivningen av verktyget:

Validerar föreslagna leadpoäng utan att spara dem. Indata: fit_score, intent_score, urgency_score och motivering. Utdata: {valid, errors, normalized_scores}. Verktyget kan inte skriva poster eller skicka meddelanden.

Verktyg 3: draft_response

Ett underarbetsflöde som tar emot informationen om leadet och poängen och skapar ett personligt utkast till e-postmeddelande. Underarbetsflödet anropar internt en annan AI-nod med en specifik prompt för att skriva utkastet:

Skriv ett personligt svar på en B2B-förfrågan. Indata: leadets ursprungliga meddelande, sammanfattningen av den kompletterande företagsinformationen och poängen för lämplighet/avsikt/brådska.

Ton: varm, direkt och utan företagsklyschor. Bekräfta den specifika förfrågan. Hänvisa endast till kompletterande företagsinformation när påståendet har en källa och är relevant. Utelämna det annars. Avsluta med ett föreslaget nästa steg för mänsklig granskning.

Längd: 80–120 ord.

Beskrivningen av verktyget:

Skriver ett personligt e-postsvar till leadet. Indata: leadets meddelande, sammanfattningen av den kompletterande informationen och poängen. Utdata: ett utkast till e-postmeddelande.

Verktyg 4: propose_route

Det här verktyget registrerar en av tre föreslagna vägar. Det skickar inte e-post och skriver inte till CRM-systemet:

• review_priority: placera utkastet i kön för prioriterad mänsklig granskning.
• human_review: placera utkastet i den vanliga kön för mänsklig granskning.
• log_only: registrera triageresultatet utan att förbereda en utgående åtgärd.

En deterministisk Switch-nod efter schemavalideringen verkställer tillåtna enum-värden och skickar review_priority och human_review till en godkännandekö. Endast ett separat underarbetsflöde med godkännandespärr har behörighet att göra kundsynliga skrivningar.

Implementera detta som ett underarbetsflöde utan sidoeffekter som returnerar ett förslagsobjekt. När Agent-noden är klar avgör en deterministisk nod för schemavalidering och en Switch-nod vilken gren som får spara förslaget. Ingen av grenarna får nå en sändningsnod utan det separata godkännandeflödet.

Beskrivningen av verktyget:

Föreslår en väg. Indata: dirigeringsbeslut (review_priority, human_review eller log_only), poäng, motivering och utkast. Utdata: ett förslagsobjekt i minnet för deterministisk schemavalidering. Verktyget kan inte spara, skicka e-post eller uppdatera CRM-systemet.

Steg 4: Testa agenten

När agenten är konfigurerad och de fyra verktygen är anslutna kör du ett test med exempelnyttolasten.

Det här bör du se i n8n:s körningsvy:

1. Webhook tar emot nyttolasten.
2. AI Agent startar.
3. Agenten anropar enrich_lead – du ser hur verktyget körs och returnerar ett svar.
4. Agenten väljer nästa steg (beroende på modell och inställningar kan mellanliggande körspår visas eller döljas).
5. Agenten anropar score_lead.
6. Agenten anropar draft_response.
7. Agenten anropar propose_route med ett av de tre dirigeringsalternativen.
8. Agenten returnerar slutlig JSON.

Om något går fel visar n8n:s felsökningspanel meddelandena mellan agenten och dess verktyg. De vanligaste problemen är:

• Verktygsbeskrivningen är inte tillräckligt specifik. Modellen kan inte avgöra när verktyget är lämpligt. Gör beskrivningarna mer konkreta.
• Verktygets schema för indata/utdata stämmer inte. Agenten kan inte skicka rätt argument. Var explicit med schemat.
• Agenten loopar i all oändlighet. Den fortsätter att anropa verktyg utan att slutföra uppgiften. Lägg till en gräns för maximalt antal iterationer och se över systemprompten.

Steg 5: Lägg till skyddsräcken

En agent utan skydd är inte säker i produktion. Lägg till följande sex skyddsräcken innan du anförtror den verklig trafik:

1. Maximalt antal iterationer. Sätt en ändlig gräns utifrån det minsta antal som dina godkända utvärderingsfall kräver. Testa att en nådd gräns skickar arbetet till en människa och inte kan lämna en partiell sidoeffekt.

2. Godkännandespärr för varje föreslaget svar. review_priority ändrar köns ordning, men ger inte tillstånd att skicka. Håll kundkommunikation bakom autentiserat mänskligt godkännande tills en separat godkänd policy säger något annat. Dra aldrig slutsatsen att något är säkert bara för att ett antal veckor har gått.

3. Tillåtelselista för utgående åtgärder. Konfigurera CRM-verktyget och e-postverktyget så att de endast hanterar poster som matchar det förväntade mönstret. Det förhindrar att agenten skickar e-post till fel adress eller skapar poster för sådant som inte är leads.

4. Loggning. Skicka godkänd metadata för varje körning: stabil referens till körning och lead, arbetsflödes- och modellversioner, verktygsnamn och resultat, valideringsresultat, väg, godkännare, omförsök och fel. Rå leadindata, berikningsresultat, utkast och verktygsargument innehåller personuppgifter eller konfidentiella data och kräver ett separat beslut om syfte, maskning, åtkomst och lagringstid.

5. Kostnadsgränser. Sätt ett ändligt antal agentiterationer och tidsgränser för arbetsflödet samt konfigurera kostnads- och anropsvarningar eller gränser hos modellleverantören. n8n beskriver abonnemangsgränser i villkoren för körningar och funktioner. Anta inte att n8n Cloud verkställer en daglig budget för en egen leverantörsnyckel. Följ användningen hos leverantören och testa nödstoppet.

6. Beslutsansvar. Modellen kan rekommendera review_priority, human_review eller log_only, men arbetsflödet verkställer den slutliga regeln. Håll enum-värdena för dirigering, poängtrösklarna och godkännandekraven utanför prompten så att de går att testa och är synliga.

Steg 6: Produktionshärdning

Här är några mönster som förvandlar en fungerande prototyp till något du kan lita på:

Idempotens. Se till att samma lead inte kan skapa dubblettposter eller dubbla meddelanden om det bearbetas två gånger på grund av ett nytt webhookförsök eller en manuell omkörning. En kontroll som först läser och sedan skriver är känslig för kapplöpningsfel. Reservera en unik nyckel atomärt i en databas och använd samma nyckel för varje efterföljande skrivning. Följ designen med atomär reservation, lease, godkännandetoken och outbox.

Felhantering. Omge varje verktygsanrop med felhantering. Om berikningen inte är tillgänglig eller företagets identitet är oklar ska arbetsflödet flagga att data saknas och skicka ärendet till mänsklig granskning. Det får inte hitta på personliga fakta bara för att färdigställa utkastet.

Observerbarhet. Följ viktiga mätvärden: genomsnittlig körtid, frekvensen för verktygsanrop och den procentandel som dirigeras till varje väg. Avvikelser är signaler.

Pilotgranskning. Granska varje körning i en avgränsad pilot med samtycke mot det ursprungliga leadet. Dimensionera piloten så att den omfattar källtyper, språk, saknade fält, oklara företag, injektionsförsök och prioritetsklasser. Följ upp felaktig berikning, poäng, väg, tidsfrist och utkast. Ett fast antal på 50 fastställer inte en tillförlitlighetsnivå.

Ett verkställbart nödstopp. Spärra körning och varje komponent som verkställer sidoeffekter utanför modellen så att en behörig operatör kan pausa nya och återupptagna körningar utan en ny driftsättning. Testa att det avstängda läget blockerar köade och pågående sändningar. En promptinstruktion eller ett värde som bara agenten ”kontrollerar” är inte ett nödstopp.

Det viktigaste designbeslutet: vilka verktyg agenten ska få

Verktygsuppsättningen är det som har störst inverkan på agentens kvalitet. Det finns två typiska fellägen:

För få verktyg. Agenten kan inte utföra sin uppgift. Den försöker kringgå de saknade funktionerna, ofta genom att hallucinera.

För många verktyg. Agenten blir förvirrad, väljer fel verktyg eller slösar iterationer på att utforska. Kvaliteten försämras.

En bra regel är: börja med minsta användbara verktygsuppsättning och lägg bara till verktyg när agenten bevisligen behöver dem.

För leadkvalificering är de fyra verktyg vi valde ungefär lagom. Du kan även lägga till:

• Ett “lookup_existing_customer”-verktyg som kontrollerar om leadet redan är kund.
• Ett “schedule_meeting”-verktyg som integreras med kalendern.
• Ett “translate”-verktyg om leads kommer in på flera språk.

Men varje nytt verktyg innebär ytterligare ett beslut som agenten måste fatta. Varje verktyg måste verkligen förtjäna sin plats.

Mönster som kan generaliseras

Samma kontrollidéer kan hjälpa andra triageflöden, men etiketterna och åtgärderna nedan får inte överföras utan domängranskning:

Klassificering av supportärenden. Hämta tillåten kundhistorik och föreslå kategori eller prioritet. Håll åtgärder som rör konto, säkerhet, återbetalning, rättigheter och kundmeddelanden bakom policy- och människospärrar.

Arbetslivsflöden. Anpassa inte leadpoängen till automatiserade beslut om intervju eller avslag. Anställningsbeslut kan skapa juridiska risker och risk för diskriminering och kräver kvalificerad HR- och juridisk granskning, tillgänglighetskontroller, utvärdering av snedvridning, information till arbetstagare eller sökande och meningsfullt mänskligt beslutsfattande.

Hantering av pressförfrågningar. Byt ut informationsberikningen mot “lookup_publication” och dirigeringen mot prioritetsbaserade svar.

Dirigering av kundåterkoppling. Byt ut informationsberikningen mot sentimentanalys och produktkategorisering.

Inköpsförfrågningar. Byt ut informationsberikningen mot leverantörssökningar, poängsättningen mot regelefterlevnad och dirigeringen mot godkännandeflöden.

En återanvändbar form för arbete med små konsekvenser är: validera en inkommande händelse → hämta minsta tillåtna kontext → be om ett strukturerat förslag → validera deterministiskt → låt fastställda regler och behöriga människor besluta → verkställ genom idempotenta, spärrade verktyg. Modellen föreslår. Den äger inte beslut med konsekvenser.

När du INTE ska använda en agent

Vissa arbetsflöden har ingen nytta av en agent. Om logiken är helt deterministisk – ”gör alltid A, sedan B och därefter C” – är ett vanligt n8n-arbetsflöde utan agent snabbare, billigare och mer tillförlitligt.

Agenten förtjänar sin plats när:

• Antalet möjliga vägar är stort.
• Rätt väg beror på en bedömning, inte på strikta regler.
• Vissa beslut kräver att information från flera källor vägs samman.

Om beslutsträdet består av några få om-så-annars-satser kan du helt enkelt använda om-så-annars-noder. Spara agenten till fall där om-så-annars-logiken blir ohanterlig.

Bygg den en gång för ett verkligt arbetsflöde

En AI-agent i n8n är ett arbetsflöde där en modell får välja mellan konfigurerade verktyg. En produktionsdesign begränsar valet och låter ansvariga människor och deterministisk policy behålla kontrollen över beslut med konsekvenser.

Designen är färdig först efter ett test av dubblettleverans, ett test av ogiltiga utdata, ett test av överskriden tidsgräns hos leverantören, ett test av avvisat godkännande och en kontroll av att sändningsnoden inte kan nås utan godkännande. Mät byggtid, latens, korrigeringsgrad och kostnad i din egen instans. Artikeln lovar varken en installationstid eller ett produktionsresultat.

Bygg och testa först med syntetiska data eller icke-produktionsdata som ni har samtycke att använda. Återanvänd kontrollmönstret – snävt avgränsade verktyg, scheman, idempotens, stoppregler och granskningsspärrar – men gör om domän- och riskanalysen för varje nytt arbetsflöde.