Introduction Hej alle, jeg er Max Nechaev - ingeniørchef hos Snoonu, grundlægger og AI-entusiast. Jeg har været i softwareudvikling i ganske lang tid. Tilbage, da jeg byggede iOS-apps, var der tonsvis af arkitektoniske mønstre derude. De følte sig solide. Tænkte igennem. Battle-testet i årevis. På det tidspunkt havde jeg aldrig forestillet mig, at jeg ville være den, der skabte en ny arkitektur - især ikke for AI-systemer. Men før vi kommer til løsningen, lad os tale om problemet. Lige nu går AI igennem en vanvittig hypecyklus. Startups dukker op og dør hver dag. Flere og flere mennesker dykker ind i værktøjer med lav kode og uden kode som Make, n8n og andre. Og du ved hvad? jeg synes, det er fantastisk. Millioner af mennesker træder ind i en ny slags virkelighed. Det føles som de tidlige dage på internettet, da hjemmesider gik fra statisk til interaktiv, og det føltes pludselig som om alt var muligt. Flere mennesker bygger AI-agenter. Og jeg elsker det. Men der er en fangst. Der er stadig ingen fælles forståelse for, hvordan man arkitekterer fleksible, skalerbare AI-systemer. ingen reelle designmønstre. ingen bredt vedtaget struktur. Jo mere jeg kiggede rundt, jo mere jeg så det. Agenter bygget i n8n ligner spaghetti. Umuligt at læse, debugge eller skalere. Tutorials om bygning agenter i Python? samme historie. Alt dumpet i en fil, ingen adskillelse af bekymringer. Sikker, erfarne udviklere kan vide, at de skal dele ting ud - men begyndere ikke. Så i dag vil jeg dele den løsning, jeg er kommet til at stole på. Sådan strukturerer jeg mine AI-systemer. Sådan adskiller jeg ansvarsområder. Hvordan holder jeg tingene fleksible, skalerbare og faktisk sunde. Lad mig introducere dig til min ramme, design mønster, eller arkitektur - kald det, hvad du vil - Det er agent action chains. AAC Meet AAC (Agent Action Chains) På et tidspunkt indså jeg noget simpelt. Hvis kaos fortsætter med at ske igen og igen, er det måske ikke et uheld. Så jeg begyndte at eksperimentere. Først med blokke inde i n8n. Så begyndte jeg at adskille logik manuelt - her er hvor jeg håndterer input, her er hvor jeg gør behandling, her er kernelogikken. Til sidst begyndte roller at dukke op. Og så ramte det mig. Dette har brug for struktur. Dette har brug for arkitektur. Sådan blev AAC født - Agent Action Chains. Det er ikke en anden ramme med tusind sider af dokumenter. AAC er en måde at opbygge AI-systemer på som en voksen ingeniør, ikke som nogen, der stikker tingene sammen og håber på det bedste. Hvad er den centrale idé? Jeg opdelte systemet i agenter med klare roller. Hver agent gør præcis én ting. De taler alle gennem JSON-kontrakter - ingen gætning, ingen magi, ingen rod. Alt bliver forudsigeligt, skalerbart og lettere at debugge. Tænk på det som et hold. En håndfuld input. Andre processer af data. En tredje beslutter, hvad der skal gøres næste gang. En anden agent taler til hukommelsen. En fanger fiaskoer. En anden kigger og logger alt. Alle kender deres job. Og sammen kører systemet som et schweizisk ur. Skønheden ved AAC er, at den er platformagnostisk. Du kan implementere den i n8n, i , i Python ved hjælp af FastAPI, selv inde i LangChain eller LangGraph, hvis du tager dig tid til at konfigurere det korrekt. af Make.com Here’s How It Works (In Plain English) Forestil dig et solidt team. Ikke en kaotisk gruppe, hvor alle gør alt på én gang, men en besætning, hvor hver person kender deres job, ejer deres plads og leverer et klart resultat. Det er præcis sådan AAC fungerer. Når en input rammer systemet - hvad enten det er fra en bruger eller en ekstern tjeneste - passerer det først gennem en agent, der simpelthen åbner døren og slukker den. Så kommer grundlæggende behandling. Vi skynder os ikke til konklusioner. Først strukturerer vi input, renser støjen, normaliserer det. Det trin alene sparer timer på at debugge ned ad vejen. En ren input er halvdelen af arkitekturen. Det er hjernen i systemet. Det udfører ikke selve opgaven. I stedet finder det ud af, hvem der skal gøre hvad, i hvilken rækkefølge, med hvilke parametre. Orchestratorens rolle er at planlægge, styre og styre strømmen. Så tager specialisterne over. Disse agenter er fokuserede. En klassificerer, en anden opsummerer, en tredje henter eksterne data og så videre. Hver har et klart formål. De overlapper ikke, de kæmper ikke over ansvar, de omskriver ikke hinandens outputs. Du kan udveksle dem, forbedre dem, genbruge dem - ligesom gode softwaremoduler. Når systemet har brug for at huske noget, kommer hukommelsen i spil. Det er dets egen agent. Det gemmer ikke alt blindt. I stedet ved det, hvordan man henter de rigtige ting på det rigtige tidspunkt - tidligere samtaler, brugerkontekst, interne fakta. Fejlhåndtering behandles lige så alvorligt. AAC omfatter en dedikeret agent til det - Guard. Det overvåger fejl, fanger undtagelser, tager handling, når noget går i stykker. Det er ikke en patch, ikke en tilfældig prøve. Det er en reel del af arkitekturen. Og det er ansvarlig for modstandsdygtighed. Mens alt dette sker, observerer observatøren stille. Det sporer, hvad hver agent gør, hvor længe ting tager, hvilke beslutninger der træffes. Ikke kun for sjov - dette giver dig synlighed i systemet. Ikke "fungerede det?" men Det virkede, Det fungerede, og hvor det kunne mislykkes. Hvordan Hvorfor Og endelig, når hele kæden har gjort sit arbejde, er resultatet formateret og leveret - tilbage til brugeren, i en API-respons, eller hvor det skal gå. Det er AAC. Et system bygget ikke kun for at fungere, men for at udvikle sig, skalere og forblive under kontrol. All AAC Roles: Who Does What and Why It Matters AAC er bygget på en klar adskillelse af ansvarsområder. Hver agent er ikke bare en teknisk blok - det er en logisk enhed med en defineret rolle og en kommunikationskontrakt. Denne sektion nedbryder, hvad disse roller er for, hvordan de interagerer, og hvorfor det ofte fører til arkitektonisk smerte senere. Ingress Agent: the Entry Point Håndtering af det indgående signal. Purpose: Dette kunne være en webhook, en formularindsendelse, en Telegram-meddelelse, en Kafka-begivenhed - det betyder virkelig ikke noget. Fordi blanding af logik med integration lag er det første skridt mod at opbygge en monolit. I n8n er dette normalt bare en webhook-nod. Den modtager forespørgslen, logger dataene og sender en ren JSON-gearload ind i systemet. Eksempel på en pseudokode: { "source": "user", "payload": { "message": "I’d like to return my order" } } Preprocessing Agent: the Filter and Normalizer Gør rå input til noget nyttigt. Purpose: Dette agent renser støjen. Det fastsætter huse, striber mærkelige symboler, validerer struktur og udtrækker nøglefelter. Det sikrer, at alt, der er gået ind i systemet, er forudsigeligt og konsekvent. Mange mennesker hopper over forbehandling. Stor fejltagelse. Det er ikke bare en "godt at have" - det er fundamentet. Især når du beskæftiger dig med LLM'er, er konteksthygiejne alt. En rodet input og hele ræsonnementskæden kan falde i stykker. I n8n er dette typisk en funktionsknode. I koden kan det være middleware, en handler eller en lille utility-klasse. const cleanInput = input.message.trim().toLowerCase() Orchestrator Agent: the Brain of the System afgøre, hvad der skal ske. Purpose: Orkestratoren gør ikke arbejdet selv. Dets opgave er at planlægge, delegere og overvåge. Det tager den rensede input, viser brugerens hensigt og aktiverer de rigtige specialiserede agenter. I enkle tilfælde kan dette bare være en if/else blok. I mere avancerede opsætninger er det en fuldblæst LLM, der kører med omhyggeligt udformede opfordringer. For eksempel kan du have GPT-4 returnerer en struktureret udførelsesplan i JSON: { "steps": [ {"agent": "Classifier", "input": {...}}, {"agent": "Memory", "input": {...}}, {"agent": "Responder", "input": {...}} ] } Du kan endda give det en liste over tilgængelige agenter og lade det vælge den bedste vej fremad. Nøgleidéen er denne: orkestratoren løser ikke problemet, den bygger ruten, den bestemmer, hvem der skal gøre hvad, og i hvilken rækkefølge. Specialist Agents: Focused Experts (TOOLS) udføre en enkelt, veldefineret opgave. Purpose: Disse agenter er ikke her for at løse hele problemet - bare et bestemt stykke af det, og gør det godt. Klassificering af en anmodning Genererer et svar Udvinding af enheder Opkald til et eksternt API Oversættelse af tekst Du kan ende med snesevis af disse. Hver er en separat funktion, en ren modul eller en underflow i n8n. Og det er præcis, hvad der gør systemet fleksibelt og skalerbart. Vil du tilføje en ny evne? Bare oprette en ny specialist og registrere den. Orchestrator behøver ikke at blive omskrevet - det skal bare vide, at dette værktøj eksisterer. Eksempel på en kontrakt mellem orkestrator og en specialist: { "agent": "Classifier", "input": { "text": "My order never arrived" }, "output_expected": { "label": "delivery_problem" } } Memory Agent: the Interface to the Past Skab relevant kontekst. Purpose: Denne agent henter fakta. Det er det. Det forespørger en database, en vektorbutik, en Redis-cache - uanset hvad du har - og returnerer nøjagtigt, hvad der er nødvendigt. Det træffer ikke beslutninger, gætter ikke, hallucinerer ikke. Du kan bruge det til at hente en brugers tidligere ordrer, matche vektorindlejringer fra en videnbase eller fange tidligere interaktioner. I AAC er hukommelsen altid sin egen ting. På den måde kan du skalere den, cache den eller endda tilslutte den til flere systemer. SELECT * FROM orders WHERE user_id = "user_42" ORDER BY created_at DESC LIMIT 3 Guard Agent: Protection from Chaos Fang og håndter fiaskoer Purpose: Hvis en specialist styrter ned eller orkestratoren bryder ned, træder vagten ind. Den logger fejlen, sender advarsler, og valgfrit kører tilbagetrækningslogik - som at gentage med en anden agent eller returnere et sikkert standardsvar. I produktionen er denne rolle ikke forhandlingsbar. Fejl vil ske. GPT kan returnere skrald. API'er kan være tidløse. Du har brug for et lag, der ved, hvad man skal gøre, når tingene går side om side. Eksempel: GPT returnerer en ugyldig JSON. Vagten fanger den, logger problemet, underretter Slack og sender en falsk besked. { "error": "Invalid JSON from Summarizer", "fallback_response": "Sorry, I couldn’t process your request. Forwarding it to a human operator." } Observer Agent: the System’s Black Box logge, analysere og give dig synlighed i, hvad der rent faktisk skete. Purpose: Denne agent forstyrrer ikke – den bare kigger. Vil du spore, hvor lang tid det tog hver agent at reagere? Hvilke data trak hukommelsesagenten? Hvor ofte måtte Guarden udløse et fald? Observer logger alt det til ethvert værktøj, du bruger - Supabase, Amplitude, Segment eller noget brugerdefineret. Du håber du ikke har brug for det, men når noget går i stykker, er det den eneste måde at forstå, hvad der gik galt. Uden en observatør, du flyver blind. med det, får du et fuldt billede. Egress Agent: the Final Touch Gør processen ren. Purpose: Denne agent tager det endelige output, formaterer det og leverer det, hvor det skal gå - til brugeren, en API, en webhook, Slack, hvad som helst. En af de mest almindelige fejl er at glemme dette trin.Uden en dedikeret egress agent, risikerer du at sende brudte data, rå logs eller svar til det forkerte sted. { "status": "success", "reply": "We’ve reviewed your case. Thank you for reaching out!" } Du kan køre dem parallelt, erstatte dem uafhængigt, genbruge dem på tværs af kæder. What’s Next? How to Start Using AAC in Your Projects Hvordan man begynder at bruge AAC i dine projekter Hvis du læser dette, er chancerne, at du allerede har stået over for de samme problemer, jeg gjorde. Dit projekt fortsætter med at vokse. Brugssager multipliceres. Logikken spredes bredere. Agenterne bliver "smartere" - men systemet bliver mere skrøbeligt. Hvad var en flot MVP i går er nu blevet til et rodet rod. Vil du tilføje en ny gren? Det er et problem. Forsøger at afhjælpe, hvorfor GPT returnerede noget mærkeligt? Ingen anelse om, hvor det endda skete. Dette er det øjeblik, du begynder at spørge - er der en anden måde? Der er . At implementere AAC betyder at ændre den måde, du tænker på. Det er et skift fra magi til teknik. Og udgangspunktet er ikke kode. Det ser på dit system anderledes. klart. uden illusioner. Prøv at forestille dig din logik som en kæde af uafhængige specialister. En tager input. En anden forbereder dataene. En tredje beslutter, hvad man skal gøre. Så kommer udføreren. Efter det - hukommelse. Derefter fanger nogen fejl. Endelig logger nogen, hvad der skete. Det er din fremtidige agent, AAC-stil. Lige nu, men alle disse roller er enten implicit eller blandet sammen så slemt, at ingen ved, hvad der er hvad. Det første rigtige skridt er at gøre disse roller eksplicitte. Selv kun mentalt. Skitser dem ud. Giv dem navne. Begynd at stille de rigtige spørgsmål: hvem er ansvarlig for orkestrering her? Hvor er hukommelsen? Hvordan ved jeg, om ting faktisk fungerede? Hvad sker der, hvis en blok mislykkes? Når du gør det, bliver værdien af modularitet indlysende. Når alt er bundtet til ét sted, bryder en fejl hele systemet. Men når tingene er struktureret som løst parrede agenter, bliver fejl isoleret - og systemet fortsætter med at køre. Det er derfor i AAC, hver agent er isoleret, kommunikerer gennem kontrakter, og har ingen bevidsthed om de andre. Det er som mikroservices inde i en rørledning. Kun enklere. og hurtigere. Og så begynder det sjove. Pludselig indser du, at du kan genbruge stykker af systemet. Det samme klassificeringsagent, der håndterer en strømning, kan bruges i en anden. Hukommelsesblokken kan deles på tværs af flere kæder. Du kan endda gøre orkestrator smartere - lad det vælge, hvilke agenter der skal udløses. Dette er ikke fantasi. Dette er den baseline modenhed AAC bringer. På kodeløse platforme som n8n bliver dette en rigtig supermagt. Du begynder at opbygge et bibliotek af agenter. Hver af dem er en underflow med en defineret kontrakt. Vil du opbygge en ny bot? Bare ring de agenter, du har brug for, i den rækkefølge, du har brug for dem. Vil du erstatte en blok? Gør det uden frygt. Vil du overvåge ydeevnen eller spore, hvor ting fejler mest? Du har allerede det - Observer logger alt, Guard fanger hver fejl. Du begynder at se systemet som en ingeniør, ikke nogen bange for at røre koden. Du designer.Du omdanner en kæde af GPT-opkald til ægte arkitektur - noget, der lever, skalerer, logger, udvikler sig. Og hvis du ikke har tid til at genopbygge alt lige nu - det er okay. Start med en strømning. Et indgangspunkt. Et ærligt øjeblik, hvor du siger, "OK, lad mig prøve en ny tilgang her. Lad mig adskille rollerne. Tilføj lidt kontrol." Det er det øjeblik, du begynder at bygge med AAC. Og chancerne er - du vil ikke ønske at vende tilbage.
