Så orkestrerar jag AI-agenter med n8n
Jag ser n8n mindre som "ett verktyg som kör AI-agenter" och mer som ett deterministiskt skal runt probabilistiska steg. Det är en viktig skillnad.
Jag ser n8n mindre som "ett verktyg som kör AI-agenter" och mer som ett deterministiskt skal runt probabilistiska steg. Det är en viktig skillnad. Om hela logiken stoppas in i en AI Agent-node får jag snabbt samma problem som med en mega-prompt: svårt att se var felet uppstod, svårt att återköra ett enskilt steg och svårt att lägga olika permissions på olika ansvar.
Workflowet äger state
Jag vill att n8n eller databasen vet vilket state ett case befinner sig i. Modellen ska inte behöva komma ihåg det från konversationen.
Varje övergång blir en vanlig workflow-operation. AI-steget levererar ett strukturerat resultat som avgör om övergången får ske.
En agentroll per tydligt jobb
I contentliknande flöden kan jag ha separata steg för research, review och writing. I review-automation kan en modell klassificera sentiment eller risk, en annan formulera förslag och ett deterministiskt steg bestämma om svaret får skickas automatiskt. Poängen är inte att maximera antal agenter. Det är att kunna svara på vem som äger vilket fel.
Structured output mellan noder
Jag försöker undvika att nästa nod ska tolka fri text som "det verkar godkänt". Hellre:
Sedan kan en IF-node eller kodregel fatta state-beslutet. Det gör att modellen får använda sin styrka — klassificering och språkförståelse — medan kontrollflödet är synligt.
Retries måste vara medvetna
Ett vanligt automationsfel är att retry betyder "kör samma sak igen". För nätverksfel är det rimligt. För ett semantiskt fel är det ofta värdelöst. Jag skiljer därför på exempelvis:
n8n:s execution-historik och retry-funktioner gör det också möjligt att återköra misslyckade workflows med tidigare execution data, vilket är användbart för reproducerbar debugging.
Human fallback ska vara en branch
Jag vill inte lägga mänskligt godkännande på allt. Jag vill att workflowet själv eskalerar när riskklassen kräver det.
n8n dokumenterar uttryckligen human fallback och human-in-the-loop för AI tool calls som en del av sitt AI-stöd. För mig är det mest användbart när det kopplas till en explicit riskmodell.
Subworkflows slår jätteduken
När ett n8n-flöde blir stort bryter jag hellre ut stabila funktioner: research_source, validate_output, send_notification, persist_state. Då kan samma komponent användas av flera agentflöden. Det gör även versionering enklare — en ändring i notification-logik behöver inte blandas med promptändringar.
Observability före skala
Innan jag låter ett workflow köra hundratals gånger vill jag kunna se:
- execution ID,
- case/article ID,
- modell och promptversion,
- token/API-kostnad,
- state transition,
- feltyp,
- retry count,
- human escalation.
När detta finns blir automationen mycket mindre mystisk. AI-steget är bara en komponent i en vanlig produktionskedja. Det är därför jag gillar n8n för den här typen av system: inte för att canvasen gör modellen smartare, utan för att den gör orkestreringen synlig, separerbar och återkörbar.