Sådan bygger du en AI drevet organisation: Erfaring fra den virkelige verden

Du bygger en AI-drevet organisation nedefra. Start med én arbejdsopgave, byg løsningen, kør den i hånden fem til ti gange, og læg først et orkestreringslag ovenpå, når løsningerne holder hver gang.

Jeg tegnede første gang blueprintet til en AI-agent organisation i 2023, så startede jeg med at bygge den forrige år, men tog gruelig fejl af rækkefølgen.

I år har jeg 84 kortlagte processer, 27 AI-løsninger i drift og en governance struktur, som kun jeg må redigere.

Så idéen virker. Rækkefølgen afgør bare, om du henter gevinsten hjem undervejs eller først til sidst, og de fleste vælger den forkerte.

Tegningen jeg lavede i 2023

Jeg tegnede den her, fordi jeg ville vide, hvordan en virksomhed ser ud, når AI kører den. En hel organisation med roller, kommandoveje og en instans øverst, der bestemmer, hvad der er rigtigt og forkert. Ikke et flowchart over én automatisering.

Øverst sidder alignment-bestyrelsen. Den er bygget på fire ting, som hele organisationen skal køre efter. Formål, etik, moral og værdisæt. Alt hvad der ændrer strukturen, skal igennem den. Ved siden af ligger et alignment governance-lag, der holder overblik over alle aktiviteter og tjekker, at de stemmer med værdisættet.

Under bestyrelsen sidder en CEO-agent. Den uddelegerer til fem executives. CMO, CFO, CSO, CPO og en CAO, en Chief Agents Officer.

Under CMO'en forgrener det sig i tre spor, der ikke deler opgaver. Paid ads manager har Meta og Google under sig, og under Meta ligger en Facebook- og en Instagram-kampagnemanager med seks agenter til split-test, målgrupper, tekst, kampagneopsætning, video og billeder. Organic manager har SEO og sociale medier. Performance manager har kampagner og rapportering.

Pointen med opdelingen er, at en agent, der optimerer et annoncebudget, ikke skal lave søgeordsresearch. Hvert spor får sine egne agenter, fordi opgaverne kræver forskellig viden og forskellig adgang.

CAO-grenen er den, der gør organisationen levende. Den har en manager til at tilføje nye AI-agenter, en til at fjerne dem og en til at optimere dem. Under dem ligger værktøj, prompts og databaser, og nederst en API-agent, en structured data-agent og en test-agent. Organisationen kan altså ansætte og fyre sig selv, efterhånden som behovet skifter.

Til højre løber et chat- og messaging-lag. Områdechat mellem executives og managers, afdelingschat kun mellem agenter og manager i samme afdeling. Agenterne skal kunne tale sammen, men ikke på kryds og tværs af hele huset.

Idéen bag

Tanken var, at du bygger fundamentet af værdier først og derefter overlader det til AI'en selv at finde løsningerne. Du beder en AI om at køre en organisation. CAO'en spænder nye agenter op, når der mangler nogen, og systemet vokser indefra.

Idéerne kom ikke ud af ingenting. Jeg arbejdede med sprogmodeller i Tabtimize i 2021 og 2022, byggede min første agent dengang, og jeg vidste, at det her ville blive autonomt på et tidspunkt. Jeg tror stadig på det. Jeg havde bare overvurderet, hvor hurtigt det ville gå.

Jeg byggede den og satte den i gang

Tegningen blev til kode. Jeg byggede OrgAgent med en CEO på Opus, managers på Sonnet og workers på Haiku. En CAO, der hyrer og fyrer agenter. En alignment-bestyrelse med et dokument, som kun et menneske kan redigere, og som kan standse agenter, der bryder missionen. Et loop, der kører til arbejdet er gjort, venter og tjekker igen. Et dashboard på localhost med org-chart, kanban, budgetter og et live feed.

Så satte jeg den i gang på rigtige projekter.

Den fejlede ikke teknisk. Den kunne sagtens sætte tingene op. Problemet lå et andet sted, og det tog mig noget tid at se det. For at køre en forretning skal du have fingrene nede i dejen.

Google Tag Manager-fejlen

Den scene, der fik tiøren til at falde, ser sådan her ud.

Jeg byggede en AI-løsning til en marketingproces og kørte den igennem. Undervejs opdagede jeg, at der skal sættes tracking op via Google Tag Manager på hjemmesiden, før en bestemt type annoncering kan køre. Det havde jeg taget for givet. Jeg plejer at hyre mig fra den opgave, så den står ingen steder i mine noter, og jeg tænker aldrig over den.

Jeg fandt det først, mens jeg selv sad og lavede løsningen.

En top-down organisation opdager aldrig den slags. CEO-agenten kan ikke spørge om et trin, den ikke ved eksisterer, og jeg kunne ikke fortælle den om det, fordi jeg heller ikke vidste det. Den type hul sidder i de fleste af dine processer og venter på, at nogen kører opgaven manuelt nok gange til at snuble over det.

Den ved ikke, hvad den ikke ved

Der er en anden grund til, at top-down knækker, og den handler om, hvordan sprogmodeller arbejder.

En LLM er verbose. Den giver dig det brede, generiske svar, fordi det er der, sandsynlighedsmassen ligger. Vil du have fat i det specifikke, skal du grave ned i modellens latent space og køre et aktiveringsflow, der trækker det frem. Selv der får du noget, der er skruet sammen af det, den har set mest af.

Og hvad så, hvis viden om din konkrete case findes på engelsk? Eller beskriver, hvordan man gør i USA? Så anbefaler den værktøjer, vi ikke bruger i Danmark, og en fremgangsmåde, der ikke passer til dansk praksis. Du får et setup, der ser rigtigt ud og er forkert.

Du ender med noget rodet og generisk, der ikke holder kvalitet. Og skal AI køre min eksisterende forretning, er kvaliteten ikke til forhandling.

Bottom-up, sådan ser det ud bygget

Så jeg vendte det om. I dag ligger min organisation i en mappe, der hedder AGM AI Central, og den er bygget nedefra.

Det er 27 AI-løsninger, som ligger spredt ud i afdelingsmapperne, dér hvor arbejdet foregår. LinkedIn har fem, annoncer har tre, testimonials har fire, e-mail har fem, salg har to. Community, tracking, Facebook, online events, YouTube og Buildable (mit LMS+CRM) har hver deres.

Placeringen lyder som en detalje, og den afgør kvaliteten. En løsning, der ligger i den mappe, hvor opgaven bor, er bygget af nogen, der kendte opgaven. En løsning i en central mappe er som regel bygget af nogen, der gættede.

Governance-dokumentet kun jeg må redigere

Øverst i mappen ligger et dokument, der hedder ORKESTRERING.md. Første linje siger, at ændringer i dokumentet kun må foretages af mig, aldrig af en agent. Det er alignment-bestyrelsen fra 2023-tegningen, men flyttet ned i bunden af stakken, hvor den kan bruges til noget i dag.

To regler bærer det hele. Den første siger, at står en proces ikke i mit procesregister, findes den ikke og må ikke automatiseres. Den anden siger, at en automatiseret kørsel kun udfører den proces, dens trigger peger på. Den opfinder ikke nye opgaver undervejs.

Opdager en kørsel, at der mangler en proces, skriver den et forslag i loggen og stopper. Den handler ikke på det. Det er den korte version af alt, jeg lærte af top-down-forsøget.

Tre risikoklasser

Hver proces får en farve, og farven afgør, hvad AI må gøre uden mig.

Fire regler står over alt andet, uanset hvad en prompt siger. Ingen kørsel gennemfører betalinger eller ændrer betalingsopsætning. Ingen kørsel sletter data uden for sine egne arbejdsmapper. Ingen kørsel underskriver eller indgår aftaler. Ingen kørsel sender noget til eksterne modtagere, medmindre processen står som grøn for netop det trin.

Hærdningsreglen

En proces må ikke få en automatisk trigger, før den har kørt manuelt tre gange med dokumentation. Det er dér, edge casene dukker op, og de skal skrives ind i løsningen, mens de er friske.

Når triggeren tændes, kører processen skygge i en uge parallelt med min manuelle rutine. Først derefter slipper jeg den manuelle. Skal en gul proces forfremmes til grøn, kræver det ti godkendelser i træk uden en eneste rettelse fra mig.

Går det galt, ryger den ned igen. Én alvorlig fejl, en forkert modtager, forkerte tal, en brudt rød regel, og processen sættes tilbage til manuel. Fejlen skrives ind i løsningen, før den må aktiveres igen.

Princippet bag hedder reliable skill, fallible agent. En robust løsning kan godt drives af en agent, der laver fejl, fordi fejlhåndteringen ligger i løsningen. Den omvendte vej virker ikke. En fejlbar agent oven på svage løsninger bygger fejl oven på fejl, og det var præcis det, jeg kunne se i den tidligere top-buttom tilgang.

Én daglig kø

Alt gult lander ét sted, og jeg åbner det én gang om dagen klokken 08:30. Fem til femten minutter. Godkend, ret eller afvis.

To sætninger i dokumentet gør arbejdet her. Intet i køen haster pr. definition, så hastende ting er en designfejl. Og alt, der afbryder mig uden for køen, er også en designfejl, der skal rettes i processen. Ikke i mig.

Det flytter tres spredte afbrydelser om dagen til ét dagligt møde med mit AI-team. Samme kontrol, en brøkdel af friktionen. Godkendelse og afsendelse er altid to forskellige ting, så en opfølgende kørsel sender, ikke jeg.

Registret der husker i stedet for mit hoved

Alt sammen hænger på ét dokument, PROCES-REGISTRY.md, med 84 processer fordelt på ni områder. Økonomi har 13, marketing 16, salg 9, indhold 9, kundeservice og leverance 9, udvikling 9, videnstyring 8, administration 7 og to personlige.

Hver række har et id, hvilken løsning der udfører den, hvilken trigger der starter den, hvor ofte, hvilken risikoklasse, status og modenhed. Syv af dem holder jeg med vilje manuelle for altid. Workshops og keynotes, teamchecks, kontraktunderskrifter. De skal ikke automatiseres.

Det her løser mit oprindelige problem. Jeg kan ikke længere holde overblik over mine egne løsninger i hovedet, og det behøver jeg heller ikke. Registret husker. Jeg godkender.

Status lige nu: jeg trigger stadig alt selv

Så skal jeg være ærlig om, hvor langt jeg er.

Min runs-log for juli har 62 kørsler mellem den 13. og den 23. Trigger-kolonnen siger det samme i alle 62. Manuel. Julians ordre. Julians GO. Nul cron-kørsler, nul events, nul autonome beslutninger.

Nogle af logteksterne er nærmest citater fra mig selv. "GO TIL ALLE 3". "KØR DEN NU MED MIT LUI OPSLAG". "Julians feedback: ad-copy var AI-slop, al copy omskrevet efter stop-slop-skillen".

Jeg har n8n-flows, der kører af sig selv, og de kører fint. Men det er ren automation. Der sidder ingen sprogmodel og træffer en beslutning om, hvorvidt noget skal ske. Den træffer beslutningen bagefter, når flowet har afleveret data.

Grunden er, at jeg er i læringsfasen. Jeg kunne principielt køre det autonomt i morgen. Jeg vil bare vide, at hver løsning holder, før jeg slipper den.

Sammenholder du 2023-tegningen med, hvad der står i mapperne i dag, er mønsteret tydeligt. Alignment-bestyrelsen er blevet til ORKESTRERING.md. Alignment governance er blevet til runs-loggen. CEO-agenten findes ikke og er erstattet af procesregistret. Paid ads manager og Organic manager er blevet til mapper. Split-test-agenten og billede content-agenten er blevet til konkrete løsninger, der virker.

Hele bunden af tegningen er bygget. Toppen er erstattet af en markdown-fil og et menneske.

CMO-agenten ligger klar, men mappen er tom

Næste skridt har jeg allerede skrevet ned. Der ligger en færdig byggeplan for en CMO-agent med charter, missionsfil, læringsfil, backlog og kontekstfil. Charteret er det eneste, jeg selv må redigere, og den vigtigste linje i det er listen over ting, agenten aldrig må. Sende noget eksternt, bruge penge, kontakte kunder, redigere sit eget charter.

Den skal vækkes tre gange. Mandag klokken 07:00 til ugentligt review, hver dag klokken 06:30 til et pulstjek, og fredag klokken 15:00 for at skrive ugens læringer ned. Derudover skal den kunne vækkes af hændelser i den virkelige verden. En ny lead, en ny mail, et svar på noget, en annonce der pludselig performer, en KPI der afviger fra målet.

Pointen med den er ikke, at den skal opfinde marketing. Den skal forstå hele mit setup, se hvad der er sket, og sætte de rigtige delløsninger i gang. Så den bliver netop denne "autonome" del, af setuppet, der gør, at tingene bare køre af sig selv.

Hvad så med økonomien (eller tokenomics)? Det er designet er omkostningslet fra. Et loop, hvor de fleste kørsler koster næsten ingenting, fordi agenten kigger, ser at der intet er at gøre og logger det. Et naivt loop, der kører hvert kvarter, ville koste omkring 430 dollars om måneden. Denne her tilgang lander under 50.

Derfor betaler bottom-up sig undervejs

Det argument, jeg gerne ville have hørt i 2023, handler om, hvornår pengene kommer ind.

Bygger du top-down, får du først afkast, når du er færdig. Du bygger bestyrelsen, CEO'en og executives, og først når de har noget at dirigere, sker der noget i forretningen. Og du bliver aldrig færdig, fordi hver gang du kommer tættere på, opdager du et nyt hul som Google Tag Manager-hullet.

Bygger du nedefra, tjener den første løsning sig hjem i uge to. Den næste i uge tre. Fundamentet til det autonome lag vokser af sig selv, mens du henter gevinsten hjem hele vejen. Du venter ikke på fremtiden, du bygger den, mens du får betaling for det.

Top-down gør AI til et projekt med en deadline. Bottom-up gør det til en arbejdsform, du kan leve i.

Appetitten gør dine processer flere, ikke færre

Der er en bivirkning, ingen advarede mig om, og jeg blev glad for den.

Lad os sige, at du har 20 arbejdsopgaver i marketing og salg.

Får du AI til at håndtere 80 til 90% af dem, sidder du tilbage med to eller tre processer manuelt. Så har du pludselig tid mellem hænderne. Hvad gør du så? Du tilføjer selvfølgelig flere opgaver.

Du udvider markedet til flere kundetyper og sortimentet til flere produkter, indhold til flere kanaler/sprog, og du kan håndtere det på samme tid som før.

Jeg kan mærke det på mig selv. Før havde jeg kun overskud til at poste indhold på LinkedIn. Nu er nyhedsbrevet med. Så kommer Facebook, YouTube og resten, og på et tidspunkt flere gange om dagen. Det samme gælder salg og forretningsudvikling.

Jeg har 0 processer i registret i dag. Det tal er et øjebliksbillede, ikke et loft. Der er opgaver, jeg for et år siden ikke turde drømme om at tage fat på, fordi de var for tunge. Dem kan jeg tage nu, og så bliver de til processer nummer 85, 90 og 120.

Gevinsten akkumulerer. Tag 50 procent af arbejdet fra dine hænder, og du har 50 procent flere opgaver, du kan sætte i søen. Kør den samme øvelse på de nye opgaver, og du står samme sted igen med endnu mere plads.

Derfor vinder de små de næste år

Nu til den del, hvor jeg gætter. Jeg tror, at eksplosiv værditilvækst kommer i små og mellemstore virksomheder på kort bane, og at store organisationer bliver hægtet af. Ikke fordi de er dumme, men fordi de har bygget noget, der nu står i vejen for dem.

Governance-spørgsmålet uden svar

Jeg har haft samtaler med mange topledere og mellemledere, og de siger alle sammen det samme. Hvad med governance? Hvad med det her? Det tør vi ikke. Hvem står tilbage med ansvaret?

Det er ikke en undskyldning. Det er et rigtigt spørgsmål. Lad os antage, at en agent går ud og sletter noget, den ikke skulle. Risikoen er lav, men den findes. Hvem har så ansvaret i en virksomhed med 20.000 ansatte? Er det personen, der byggede agenten? Personen, der triggede den? Er det ledelsen? Ingen kender svaret, og derfor bevæger ingen sig.

En virksomhed med to eller tre ansatte har ikke det problem. Svaret er givet på forhånd. Alt skal stadig kunne trackes og logges, og compliance gælder for alle, men det er lettere at overskue med to mand end med 20.000.

Jeg kommer til at tænke på Romerriget. De byggede et så stærkt bureaukratisk fundament, at det til sidst blev deres død. Når alt skal koordineres, kan ingenting prioriteres. Det er ikke en ny tanke. Men lige nu bliver den sat på spidsen, fordi det her ikke handler om, hvorvidt du har en hjemmeside eller kan nå at integrere et par IT-systemer.

Nej, det handler om, hvordan du kan overdrage hele din virksomheds drift til AI.

Afdelinger findes, fordi ét menneske ikke kan holde det hele

Prøv et tankeeksperiment med mig. To virksomheder sælger det samme. Den ene har tre ansatte, den anden 500.

Hvad er forskellen? I den store er HR en afdeling for sig, økonomi en afdeling for sig, marketing og salg hver deres. Opgaverne er ikke svære. Man deler op, fordi kapaciteten ikke findes, når man vokser, og fordi nogen skal tage sig af hver del. Et menneske kan ikke holde styr på det hele.

Et menneske med et sæt AI-løsninger, agenter, n8n-flows og vibe-codede værktøjer kan holde flere af dem på én gang, fordi de bare eksekverer løsninger, der allerede findes.

Om tre personer så lige kan matche 500, ved jeg ikke. Det er mit gæt, ikke et regnestykke, og jeg har ikke set data på det. Men retningen tvivler jeg ikke på.

Den store organisation har også en implementeringsomkostning, den lille slipper for. Der skal godkendes hos en chef, alle skal orienteres løbende, og der er så mange trin at tænke over, at der går en måned, før nogen overhovedet begynder at bygge. På den samme måned har den lille virksomhed fået AI til at håndtere 20 procent af arbejdet. Så ruller bolden.

Oveni ligger et HR (lad os faktisk bare sige samfunds)-problem, ingen taler højt om. Du kan ikke bare fyre mange mennesker, og det ville heller ikke være i orden. Og de mennesker, der skal implementere løsningen, har måske ikke selv lyst til det.

Policy-ændringen ved 20 kunder mod 50.000

Størrelse gør ondt et helt konkret sted, og det er, når du skal ændre din privatlivspolitik.

Har jeg 20 kunder, kan jeg skrive personligt til hver enkelt.

"Hej Karsten, jeg vil gerne levere en bedre service, hurtigere og måske billigere, og det gør jeg ved at lade AI håndtere en del af dit materiale. Her er hvilken information det drejer sig om, sådan pseudonymiserer jeg den, og til de følsomme dele bruger jeg open source-modeller..."

Siger en kunde nej til det, må vi holde op med at arbejde sammen.

Har du 50.000 kunder, kan du godt sende beskeden ud. Men flere tusinde svarer aldrig, og en del accepterer aldrig. Du kan ikke stille dem det samme ultimatum, og du kan ikke ringe dem op.

Det samme gælder juraen. Færre kunder betyder færre kontraktuelle forhold at holde styr på. Og i en lille virksomhed kan du sætte AI til at gennemgå de kontrakter, du har. Igen er det logik, ikke en case, jeg har kørt. Men logikken holder.

Mine kursister har allerede skiftet spørgsmål

Det stærkeste bevis, jeg har, kommer ikke fra mig selv.

Flere deltagere på AI Growth Minds er soloselvstændige eller har en enkelt medarbejder eller en samarbejdspartner, højst fem mennesker. De har brugt få måneder på at komme dertil, hvor AI håndterer store dele af deres driftsopgaver.

Og spørgsmålet, de stiller mig, har ændret sig...

Før spurgte de, hvordan man overhovedet gør det. Nu spørger de, hvordan de gør det godt nok og hurtigt nok til at skalere endnu mere. De sidder selv som flaskehals, fordi de hele tiden skal trigge og eksekutere deres egne løsninger, og de vil have det autonomt.

De står altså med præcis det problem, jeg selv står i. Jeg har aldrig hørt det spørgsmål stillet i en stor organisation, for de er ikke nået dertil.

Den anden fælde: at tro det er svært

Top-down er den ene fælde. Den anden er større, og langt mere udbredt.

Folk tror, det handler om at vibe-code sit eget harness, bygge komplekse agentsystemer og orkestrere flows i flere lag. Det gør det ikke. Deltagerne på mit forløb bygger deres første løsninger i uge et og har tre eller fire løsinger kørende i uge to. Så nemt er det.

Jeg siger ikke, at det er for tidligt at bygge en AI-drevet organisation. Teknisk kan det lade sig gøre i dag. Jeg siger, at rækkefølgen afgør, om du får noget ud af det undervejs eller først til sidst. Gør du det nedefra, får du gevinsten nu og bygger samtidig hen mod den dag, hvor AI kan håndtere det hele autonomt.

Sådan starter du på mandag

Første skridt er proces mapping. Du kan ikke bygge noget, før du ved, hvilke arbejdsopgaver og processer du har, og du kan ikke prioritere noget, du ikke har skrevet ned. Jeg har beskrevet hele fremgangsmåden i proces mapping med AI, hvor en lokal agent kortlagde 86 af mine processer på 38 minutter.

Når kortlægningen ligger der, segmenterer du. Find de processer, der har høj transaktionsværdi, og dem der giver dig det bedste afkast. Start dér, ikke ved den mest interessante.

Så skal hver proces have den adgang, en agent behøver for at udføre arbejdet. Det er trin to, og jeg har skrevet om, hvordan du vælger mellem CLI, API, MCP og computer use i adgangs-auditen.

Derefter bygger du én løsning og kører den manuelt fem til ti gange. Skriv hver edge case ind, mens den er frisk. Når du har et bibliotek af løsninger, der virker hver gang, lægger du orkestreringslaget ovenpå, og hvordan det lag ser ud, har jeg beskrevet i fremtidens virksomhed kører på en AI agent-organisation.

Vil du lære det selv?

Ved du ikke, hvilke AI-værktøjer, modeller og fremgangsmåder du skal bruge, så tag forløbet hos AI Growth Minds. Det viser dig fra start til slut, hvordan du skalerer din forretning med AI uden at ansætte, og jeg kender ikke et andet forløb i Danmark, der tager dig hele vejen.

Vil du have hjælp til at bygge løsningerne i din egen virksomhed, så se frameworket på Skalér din forretning med AI. Jeg tager på Danmarksturné og bygger dem sammen med jer on-premise, mens jeg holder workshop hos jer.

Ofte stillede spørgsmål

Hvordan bygger man en AI-drevet organisation?

Nedefra. Kortlæg dine processer, byg en AI-løsning til én opgave ad gangen, og kør hver løsning manuelt fem til ti gange, indtil den holder. Først når du har et bibliotek af hærdede løsninger, lægger du et orkestreringslag ovenpå, der afgør hvornår de skal køre.

Kan en CEO-agent bygge min organisation for mig?

Nej. En sprogmodel kender ikke de trin i dine processer, du aldrig har skrevet ned, og den ved ikke hvad den ikke ved. Den trækker på generisk viden, der ofte er amerikansk, og som ikke passer til dansk praksis. Kortlægningen skal komme fra dig.

Hvornår er mit setup modent nok til en AI-orkestrator?

Når dine løsninger har kørt manuelt nok gange til, at edge casene er skrevet ind i dem. Min egen regel er tre dokumenterede manuelle kørsler, før en proces må få en automatisk trigger, og ti godkendelser i træk uden rettelser, før den må køre uden mit tilsyn.

Hvorfor har små virksomheder en fordel frem for store?

Fordi ansvarsspørgsmålet ikke findes hos dem. I en virksomhed med 20.000 ansatte skal nogen svare på, hvem der bærer ansvaret, hvis en agent sletter noget. Med tre ansatte er svaret givet. Små virksomheder kan også ændre deres privatlivspolitik og informere kunderne på en eftermiddag.

Skal jeg kunne kode for at bygge en AI-drevet organisation?

Nej. Fælden er at tro, det kræver et selvbygget harness og komplekse systemer. Deltagerne på mit forløb bygger deres første løsninger i uge et og har tre til fire kørende i uge to. Simple løsninger slår komplekse.