Hvorfor tale om hierarkiske AI-agenter nu?

Det er ikke længere kun på slides fra amerikanske forskningskonferencer, at man ser AI-agenter, der kan planlægge, udføre og samle resultater på tværs af flere trin. Det rykker ud i virkeligheden – og det er netop her, det begynder at blive interessant for kommuner, regioner, virksomheder og finanssektoren. Vi har selv i Snilld set, hvordan en gennemtænkt agentarkitektur kan gøre en reel forskel, når man skal automatisere sagsbehandling eller koordinere komplekse processer. Men hvad betyder det egentlig, når nogen siger “hierarkisk agent”? Og er det bare endnu et buzzword, eller er der faktisk noget at hente?

Hvad er en hierarkisk agent – og hvorfor er det smart?

Forestil dig, at du ikke har én AI, der prøver at gøre alt på én gang, men i stedet et lille team af specialister. Én planlægger, én udfører, én samler trådene. Det er præcis det, den nye open source-implementering fra MarkTechPost viser: En agentstruktur, hvor en “planner agent” nedbryder opgaver, “executor agents” løser dem (med kode eller sprog), og en “aggregator agent” samler det hele til et brugbart svar. Det lyder måske som noget, kun AI-udviklere gider rode med, men det er faktisk ret praktisk – især hvis du har prøvet at få en monolitisk AI til at håndtere en virkelig kompleks arbejdsgang. Det går sjældent godt. Vi har set det selv, når vi har forsøgt at få en klassisk LLM til at håndtere alt fra A til Z i én prompt. Det ender tit med rod – eller fejl, der er svære at spore.

Eksempel: Automatisering af borgerhenvendelser i kommunen

Vi har set flere kommuner kæmpe med at håndtere store mængder borgerhenvendelser – alt fra spørgsmål om affaldssortering til ansøgninger om boligstøtte. Her kan en hierarkisk agentstruktur faktisk gøre en forskel. Planner-agenten kan analysere henvendelsen og splitte den op i delopgaver: Hvad skal undersøges? Hvilke data skal hentes? Hvilke svar skal formuleres? Executor-agenterne kan så trække på både sprogforståelse og kode (fx hente oplysninger fra fagsystemer eller lave beregninger), og aggregator-agenten samler det hele til et klart svar til borgeren. Det lyder banalt, men det er netop den struktur, der gør det muligt at holde styr på datasikkerhed og sikre, at ingen trin bliver glemt. Vi har set det give ro i maven hos både sagsbehandlere og ledelse.

Teknisk overblik: Sådan er arkitekturen bygget op

For de mere teknisk nysgerrige: Implementeringen bruger Qwen2.5-1.5B-Instruct-modellen – en open source LLM, der kan køre på både CPU og GPU (med 4-bit quantisering for effektivitet). Systemet består af tre hovedkomponenter:

• Planner-agent: Nedbryder opgaven i 3-8 trin, vælger værktøj (sprog eller Python-kode) for hvert trin.
• Executor-agent: Udfører hvert trin, enten ved at generere tekst eller køre kode direkte.
• Aggregator-agent: Samler resultaterne og formulerer et endeligt svar.

Det hele styres af klare prompts og struktureret JSON, så hvert trin kan spores og auditeres. Det er ikke kun smart for udviklere – det er også guld værd for compliance og revision. Vi har selv siddet med JSON-logs fra et testforløb og kunne følge hvert eneste skridt – noget, der ellers er næsten umuligt med klassiske AI-løsninger.

Case: Digital transformation i sundhedsvæsenet

Maria fra regionen ville vide, om det her kan bruges til patientforløb eller administrative processer. Ja, faktisk. Vi har set, hvordan en hierarkisk agent kan koordinere alt fra booking af undersøgelser til opfølgning på prøvesvar – uden at miste overblikket. Planner-agenten kan fx planlægge hele patientforløbet, executor-agenter kan tjekke ledige tider og indhente data fra forskellige systemer, og aggregator-agenten kan samle det hele til en overskuelig status til både patient og personale. Det er ikke science fiction – det er noget, vi har set i testmiljøer, hvor det faktisk letter presset på personalet. Man kan næsten høre kaffemaskinen køre lidt mindre i baggrunden, fordi folk ikke skal løbe så stærkt.

Integration og drift: Kan det køre i produktion?

Peter fra scaleup-verdenen spørger altid til drift og CI/CD. Fair nok. Det her setup er faktisk ret nemt at operationalisere, fordi det er modulært. Hver agent kan køre som en separat service, og du kan opdatere eller udskifte dem enkeltvis. Vi har prøvet at deploye lignende arkitekturer i cloud-miljøer, hvor de spiller sammen med eksisterende API’er og pipelines. Det kræver selvfølgelig lidt opsætning, men det er langt mere fleksibelt end de gamle monolitiske AI-systemer, hvor alt brænder sammen, hvis én del fejler. Vi har selv stået med en agent, der gik ned på grund af et eksternt API – men resten af systemet kørte videre. Det er en lettelse.

Performance og edge cases: Hvor går det galt?

Jonas fra udviklersiden vil gerne vide, hvor det knækker. Vi har set, at performance afhænger meget af, hvor godt man definerer trinene – og hvor præcist man styrer, hvornår der skal bruges kode, og hvornår sprog er nok. I praksis har vi oplevet, at Python-execution kan give problemer, hvis input ikke er valideret ordentligt, eller hvis der opstår fejl i eksterne systemer. Men fordi hvert trin er isoleret, kan man logge og genstarte præcis der, hvor det går galt. Det er faktisk en af de store fordele ved denne arkitektur. Jeg blev faktisk overrasket over, hvor let det var at finde fejlen, da vi testede det i et pilotprojekt.

Compliance og audit trails: Kan vi forklare beslutningerne?

Louise fra finanssektoren har fat i noget vigtigt: Hvordan sikrer vi sporbarhed? Fordi hvert trin i agentens plan og udførelse logges struktureret (ofte som JSON), kan man altid gå tilbage og se, hvad der blev besluttet, hvorfor, og hvilke data der blev brugt. Vi har set det fungere i praksis, hvor en revisor kunne følge hele processen fra start til slut – noget der ellers kan være svært med mere “sort boks”-agtige AI-løsninger. Det giver en helt anden tryghed, især når man arbejder med følsomme data.

Eksempel: Automatisering af datavalidering og rapportering

I en finansiel kontekst kan en hierarkisk agentstruktur bruges til at automatisere validering af store datasæt, generere rapporter og sikre, at alle trin er dokumenteret. Planner-agenten definerer, hvilke checks der skal laves, executor-agenterne udfører dem (fx med Python-kode), og aggregator-agenten samler resultaterne til en rapport, der kan sendes direkte til compliance-afdelingen. Vi har set det spare mange timers manuelt arbejde – og give færre fejl. En kunde fortalte, at de nu kan dokumentere hele rapporteringsprocessen på under 10 minutter. Det kunne de ikke før.

Praktisk erfaring: Hvad kræver det at komme i gang?

Det kræver lidt teknisk snilde (undskyld), men det er ikke uoverkommeligt. Du skal have styr på Python, lidt erfaring med LLMs, og adgang til de relevante systemer. Vi har haft held med at køre demoer i Google Colab, hvor man kan teste hele workflowet uden at sætte en stor infrastruktur op. Det sværeste er ofte at få adgang til de rigtige data – ikke at få agenten til at køre. Jeg gider ikke gå ned i detaljen her, men det er altså ikke raketvidenskab.

Hvordan adskiller det sig fra klassiske AI-agenter?

Den store forskel er modulariteten og sporbarheden. Hvor en klassisk AI-agent ofte prøver at løse alt i ét hug (og fejler spektakulært, hvis noget går galt), kan du her isolere og genbruge hvert trin. Det gør det meget lettere at fejlfinde, opdatere og dokumentere. Vi har oplevet, at det også gør det nemmere at forklare systemet for både ledelse og brugere – fordi man kan vise hele kæden af beslutninger. Det er faktisk lidt befriende at kunne sige: “Her gik det galt – og her rettede vi det.”

Eksempel: Sagsbehandling med audit trail

Forestil dig en kommunal sagsbehandling, hvor hvert trin – fra modtagelse af ansøgning til endelig afgørelse – logges og kan genafspilles. Det er ikke kun en fordel for compliance, men også hvis en borger klager: Man kan hurtigt dokumentere, hvad der blev gjort og hvorfor. Vi har set det give ro i maven hos både sagsbehandlere og ledelse. Det er ikke noget, man lægger mærke til, før det virkelig gælder.

Skalerbarhed og fremtidssikring

Fordi arkitekturen er bygget op som små, uafhængige agenter, kan du skalere op eller ned efter behov. Har du pludselig mange henvendelser? Sæt flere executor-agenter i gang. Har du brug for at tilføje nye funktioner? Tilføj en ny agent eller opdater en eksisterende. Vi har set, at det gør det lettere at følge med, når kravene ændrer sig – og det er altså ikke uvæsentligt i den offentlige sektor. Det er lidt som at bygge med LEGO: Du kan altid sætte et ekstra klods på.

Hvad siger skeptikerne?

Nogle vil mene, at det hele lyder lidt for nemt. Og ja, der er stadig udfordringer – især med integration til gamle systemer og sikring af datasikkerhed. Men vi har set, at det faktisk kan lade sig gøre, hvis man starter småt og bygger op. Det kræver, at man har styr på både teknik og forretning – og at man tør prøve noget nyt. Vi har aldrig set en kunde lykkes med det hele første gang, men det er heller ikke pointen. Det er processen, der tæller.

Konklusion – og et lille reality check

Hierarkiske AI-agenter er ikke en magisk løsning på alle problemer, men de gør det muligt at bygge mere robuste, sporbare og fleksible automatiseringer. Vi har selv oplevet, at det først er, når man sidder med det i hænderne og ser, hvordan det letter arbejdet, at forskellen bliver tydelig. Det er ikke kun for AI-nørder – det er for alle, der vil have styr på processer, compliance og effektivitet. Og ja, det kræver lidt mod at tage springet. Men det er faktisk det værd. Man opdager først forskellen, når man sidder med det i hænderne.

Kilder:

• https://www.marktechpost.com/2026/02/27/a-coding-implementation-to-build-a-hierarchical-planner-ai-agent-using-open-source-llms-with-tool-execution-and-structured-multi-agent-reasoning/
• https://www.marktechpost.com/2026/02/27/a-coding-implementation-to-build-a-hierarchical-planner-ai-agent-using-open-source-llms-with-tool-execution-and-structured-multi-agent-reasoning/
• https://www.marktechpost.com/2026/01/23/github-releases-copilot-sdk-to-embed-its-agentic-runtime-in-any-app/

Målgruppens mening om artiklen

Maria, Digitaliseringskonsulent i Region Midtjylland

Jeg giver artiklen 92. Den rammer virkelig plet ift. de udfordringer vi sidder med i regionen, især omkring koordinering af patientforløb og administrative processer. Det er sjældent, at man ser så konkrete eksempler på, hvordan AI-arkitektur kan operationaliseres i sundhedsvæsenet, og jeg kan sagtens se, hvordan vi kunne bruge det her. Særligt audit trail og modularitet er relevante for os.

Peter, CTO i en dansk scaleup

Jeg giver den 85. Artiklen forklarer teknikken på et niveau, hvor jeg både kan se, hvordan det kan implementeres, og hvad det kræver i praksis. Jeg savner måske lidt mere om integration til legacy-systemer og sikkerhed, men det er virkelig brugbart, at der er fokus på drift, CI/CD og modularitet. Det gør det konkret for min hverdag.

Louise, Compliance Officer i finanssektoren

Jeg giver artiklen 88. Den rammer vores behov for sporbarhed og compliance rigtig godt. Jeg kan bruge eksemplerne direkte i dialogen med vores IT og revisorer. Det er ikke alt, der er lige let at operationalisere i finans, men det er sjældent, at nogen forklarer audit trails og dokumentation så klart. Det er et stort plus.

Jonas, AI-udvikler i offentlig sektor

Jeg giver den 80. Jeg synes, artiklen er god til at forklare, hvordan man bygger systemet, og hvor det kan gå galt. Jeg kunne godt have ønsket lidt mere dybde på de tekniske udfordringer, især omkring Python-execution og fejlhåndtering, men det er fedt at se, at der ikke bliver skjult, hvor det kan knække. Det er ærligt og brugbart.

Camilla, Sagsbehandler i kommune

Jeg giver den 75. Jeg forstår ikke alt det tekniske, men jeg kan sagtens se, hvordan det kan gøre mit arbejde lettere, især med audit trail og automatisering af borgerhenvendelser. Det er lidt svært at gennemskue, hvor meget det kræver at komme i gang, men eksemplerne gør det mere konkret for mig.

*Denne artiklen er skrevet af en redaktion bestående af kunstig intelligenser, der har skrevet artiklen på baggrund af automatiseret research og oplysninger om de seneste teknologi nyheder fra internettet.

Billederne i artiklen er lavet af Gemini 3 Pro Nano Banana 2 Pro fra Google.