Agentic orkestration fra projektstart til drift

Branchen brugte 2026 på at opdage, at det svære ved AI-agenter ikke er agenterne. Gartner forudser, at over 40 % af alle agentiske AI-projekter aflyses inden udgangen af 2027 — ikke fordi modellerne er for dumme, men på grund af omkostninger, uklar værdi og utilstrækkelig risikostyring. IDC lægger tallet ved siden af: 60 % af AI-fejl stammer fra huller i styringen, ikke fra modellens ydeevne.

Det mest ubehagelige tal er dog et andet. Gartner forudser også, at 40 % af virksomhederne vil degradere eller helt nedlægge deres autonome agenter inden 2027 — og at hullerne, der får dem til det, først bliver fundet efter en hændelse i produktion.

Læs den sætning en gang til. Problemet er ikke, at systemerne fejler. Det er, at de ser ud til at virke lige indtil det øjeblik, hvor de ikke gør.

Agentic orkestration er ikke automatisering med en model på

Klassisk automatisering følger en fast rute. Trin A udløser trin B udløser trin C — hver gang, i samme rækkefølge. Det er forudsigeligt, og det er hele pointen.

Agentic orkestration må ændre ruten undervejs. Den vælger, hvad der skal ske som det næste, ud fra hvad der faktisk kom ud af det forrige. Det er en langt stærkere maskine — og det er præcis derfor, den skal have en bremse et sted.

Branchen er i år konvergeret mod fire grundmønstre: sekventielt (agenter i rækkefølge), parallelt (flere ad gangen), hierarkisk (en dirigent uddelegerer) og menneske-i-løkken. Næsten ethvert system i drift bruger mindst to af dem samtidig.

Og Deloitte beskriver det skifte, der er ved at ske i den fjerde: fra human-in-the-loop, hvor et menneske godkender hvert skridt, til human-on-the-loop, hvor mennesket fører tilsyn med helheden. Det er en ægte forbedring — og den er kun forsvarlig, hvis der findes noget at føre tilsyn med.

Den fejl alle laver: ensartet styring

Her er den skarpeste pointe fra årets research, og den er kontraintuitiv.

At give alle agenter samme styring er selv en fejlkilde. Gartners argument er, at det, der skal skelnes, ikke er, hvor "farlig" en agent er i almindelighed, men to helt forskellige ting: hvad den kan finde på at gøre og hvor langt dens adgang rækker.

En agent, der kan skrive en tekst, og en agent, der kan slette en database, er ikke samme risiko, selv om de kører på samme model. Sætter man samme godkendelseskrav på begge, sker der ét af to: enten drukner mennesket i godkendelser af det harmløse, eller også bliver kravet lempet — for alle på én gang.

Vores egen version af den regel er skrevet ned og gælder hver eneste session i flåden: en udrulning må en agent selv foretage, når porten er grøn. En sletning, en nøgle-ændring, en DNS-rettelse eller en force-push må den aldrig. Forskellen er ikke, hvor vigtigt det er. Forskellen er, om det kan fortrydes.

En udrulning er en dør, der går begge veje — den forrige udgave kan rulles tilbage. Et DROP TABLE er en dør, der kun går én vej. Vi behandlede dem ens i månedsvis, og prisen var ikke sikkerhed: prisen var, at færdigt, verificeret arbejde stod stille og ventede på et menneske, der allerede havde sagt ja én gang.

Kontrolplanet — og hvem der ejer hvert led hos os

Det, branchen nu kalder et kontrolplan, består af syv byggeklodser: integrationer, kontekst, et register over agenterne, måling, menneske-i-løkken, styring og selve orkestreringen. Pointen er ikke, at de findes. Pointen er, at de skal findes ét sted og styres samlet — ellers får man det, en analyse rammende kalder agentisk kaos: agenter koblet til alt, hvad de kan nå, som når frem til selvsikre forkerte konklusioner uden spor af, hvem der gjorde hvad med hvis adgang.

Vi har bygget vores i tre produkter, hver med sit led af kæden: Cardmem styrer arbejdet, Trail holder på begrundelserne, og HelpDesk møder kunden. Her er kæden, fra en idé opstår, til en kunde får svar.

1. Beslutningen — før nogen bygger noget

Hvert projekt har et beslutningsregister: de valg, ejeren allerede har truffet, leveret uopfordret til enhver ny agent-session ved opstart. En agent må foreslå en beslutning. Den må ikke selv skrive en ind.

Det lyder som en detalje. Det er den ikke: kunne en agent skrive i registret, kunne den skrive sin egen misforståelse ind som lov — og hver session derefter ville adlyde den, mens den stadig lignede ejerens beslutning.

Det vigtigste felt i en beslutning er ikke, hvad der blev valgt. Det er, hvad der blev valgt fra, og hvorfor det tabte. At genforeslå en allerede død tilgang er, hvor det meste spildte agent-arbejde faktisk går hen.

2. Planen — Cardmem

Ingen kode, før der findes et kort med testbare acceptkriterier. Ikke "gør søgningen bedre", men "en søgning på X returnerer Y, og fjerner man feltet, går prøven rød".

Det er den regel, der er sværest at holde og dyrest at bryde. Et epos med committet arbejde og nul kriterier er ikke bare uordentligt — det er umuligt at kontrollere bagefter, fordi der ikke findes en kontrakt at måle imod.

Én undtagelse, og kun én: opdager ejeren selv en fejl, mens han sidder i produktet, falder rækkefølgen væk — men kortet gør ikke. Det skrives i samme tur som rettelsen.

3. Bygningen — Cardmem

Agenten samler et kort op fra tavlen, bygger det og afleverer til review. Tavlen er opgavelisten — ikke agentens egen, private huskeliste, som ejeren aldrig ser.

Det er her, human-on-the-loop bliver konkret frem for et ord i en analyse. Christian godkender ikke hvert skridt. Han ser tavlen.

4. Verifikationen — Cardmem Lens

Og her ligger den regel, jeg vil fremhæve mest, fordi den koster mest at lære:

En 200-statuskode beviser ikke, at noget virker.

Det lærte vi igen i denne uge. En ny produktside svarede 200 længe før tegningen på den var udrullet, fordi ruten var generisk, og teksten kom ind ad en anden vej end koden. Havde vi taget de 200 som bevis, havde vi meldt en side færdig, som manglede præcis det, der var bestilt.

Derfor kører al visuel verifikation gennem Lens: en rigtig browser, der klikker på tingene og tager billedet. Og derfor gælder reglen om læs-tilbage: et gemmefelt er ikke færdigt, når det siger "Gemt". Det er færdigt, når værdien er læst tilbage fra en frisk indlæsning og sammenlignet ord for ord — plus en negativ kontrol, der beviser, at feltet også kan være tomt.

En grøn besked er UI'ets rapport om, hvad det forsøgte. Ikke om, hvad databasen indeholder.

5. Porten — CI

En agent må udrulle selv, når porten er grøn. Så porten skal kunne blive rød.

Vores kunne ikke. Prøverne kørte i udrulningen med "fejl ignoreres" slået til, og de tunge browser-prøver kørte slet ikke der. Resultatet: suiten stod rød i over 100 kørsler i træk uden at stoppe én eneste udrulning, og den samme fejl blev diagnosticeret tre gange af tre forskellige sessioner, uden at nogen mærkede noget.

Det er den samme fejlform som Gartners: hullet var der hele tiden, og det så grønt ud. Porten er armet nu, og prisen er sagt højt — en udrulning venter tre gange så længe. Er det for dyrt, gør man suiten hurtigere. Man slukker ikke porten igen.

6. Hukommelsen — Trail

Her rammer researchen en formulering, jeg ville ønske, vi selv havde fundet på:

Uden proveniens bliver hukommelse til et selvsikkert rygte.

En agents kontekst forsvinder, når samtalen komprimeres. Det, der overlever, er det, nogen skrev ned. Trail er dét lag: ikke hvad der blev bygget — det står på kortet — men hvorfor. Hvilken tilgang blev forkastet og af hvilken grund. Hvad var den egentlige årsag til en fejl, der ikke var åbenlys.

Sondringen er skarp og værd at kopiere: et kort siger "byg X". En hukommelse siger "vi valgte X frem for Y, fordi Z." Uden det andet genopfinder næste session begrundelsen — eller genopfinder den forkert.

7. Driften — Upmetrics

Fejl i drift samles i ét sted, og reglen er, at hvert repo lukker sine egne. Ikke fordi det er pænt, men fordi alternativet er en liste, ingen ejer, og som derfor holder op med at betyde noget. En fejl må kun lukkes, når den er rettet eller bevist harmløs. Ægte, uløste fejl skal stå åbne, så signalet bevares.

8. Supporten — HelpDesk

Og så det sidste led, hvor kunden faktisk står.

Benchmarktallene for 2026 er nøgterne: median-deflektion på niveau 1 ligger på 41,2 %, øverste kvartil på 58,7 %. Men gennemsnittet skjuler det interessante. Kodeskift og refusioner klares i over 70 % af tilfældene, mens nuancerede klager sjældent kommer over 25 %. Og selv om 64 % af CX-teams kørte en pilot i 2026, havde kun 27 % én kanal i fuld drift.

Den sætning fra researchen, der betyder mest, er dog denne:

Et system, der lukker, omdirigerer eller deflekterer en sag, har ikke nødvendigvis løst kundens problem.

Det er hele grunden til, at HelpDesk har fem niveauer med en defineret grænse hvert sted — og at niveau 3 er brugerens egen bekræftelse, på kundens eget site. Ikke et klik i en mail: mailscannere forklikker links, og så ville vi tælle løsninger, ingen har bekræftet. Tallet ville ligne succes, mens det var forkert.

Autonomien er optjent, ikke tildelt. Hver ny kunde starter i afvent: udkastet skrives, et menneske godkender det. Automatisk afsendelse låses op ét emne ad gangen, når tallene viser, at netop de svar løste noget — og låses automatisk tilbage, når de holder op med det.

Den anden halvdel er den, der plejer at mangle. En oplåsning uden en automatisk vej tilbage er en beslutning, ingen tør tage, fordi den reelt er permanent.

HelpDesk bygges nu. Første kunde er FysioDanmark Aalborg — rigtige brugere, deres eget design, deres eget repo.

Hvad man kan tage med

Hvis der er ét mønster i de tal, forskningen leverede i år, er det dette: de agentiske projekter, der dør, dør ikke af for svage modeller. De dør af, at ingen kunne se, hvad der gik galt, før det var gået galt.

Fire ting, vi ville gøre igen:

1. Skeln på, om en handling kan fortrydes — ikke på, hvor vigtig den føles. Det er den skelnen, der afgør, hvad en agent må selv.
2. Skriv acceptkriterierne, før koden. En kontrakt, der ikke findes, kan ikke kontrolleres.
3. Bevis det, du påstår. En statuskode, en grøn besked og en bestået prøve, der ikke kan gå rød, er tre forskellige måder ikke at vide noget på.
4. Gem begrundelsen, ikke kun resultatet. Det er den, der forsvinder først, og den, der koster mest at genopfinde.

Ingen af de fire handler om modeller. Det er nok pointen.