Lad os være ærlige. Agent‑snakken har længe været varm luft og flotte demoer. I 2026 begynder det at rykke, og CopilotKit er en af årsagerne. Startup’et fra Seattle – grundlagt af Atai Barkai og Uli Barkai – har sat navn på et hul i stacken og sendt en protokol på gaden, AG‑UI, som vil gøre agenter til embedded kolleger, ikke bare en chat i hjørnet. Samtidig dumper Alibaba en opvisning i udholdenhed med Qwen3.7‑Max, som ifølge VentureBeat holdt en agent kørende i cirka 35 timer. Det viser spændvidden. Men udholdenhed alene er ikke drift.
Pointen nu er konkret: CopilotKit taler om en trelags agent‑stack og en 2026‑plan, der angriber tre kedelige problemer – videnhentning, testbarhed og runtime‑persistence. Kedelige som i absolut nødvendige. Vores oplevelse hos Snilld er, at netop de tre ting vælter POC’er, når man prøver at gå i produktion. Jeg blev faktisk i tvivl et øjeblik om, hvor meget der var hype, før vi læste kilde for kilde og kørte små interne forsøg. Det lugter af noget reelt.
Seattle, stifterne og hvorfor timingen tæller
CopilotKit er Seattle‑baseret og co‑stiftet af Atai og Uli Barkai. Det er ikke bare en biografifloskel – byen har en blanding af cloud‑tunge profiler og produktfolk, der tænker applikation først. Ifølge MarkTechPost har holdet de sidste to år insisteret på, at chat‑widgeten er en blindgyde, og at agenter skal leve inde i applikationen, se brugerens kontekst og vise grænseflader, ikke bare tekst. Det er en hård påstand, men den matcher, hvad vi ser hos kunder: Tekst ud, menneske oversætter, klikker videre – for langsomt.
Community‑vinklen er også værd at nævne. MarkTechPost beskriver et voksende økosystem omkring AG‑UI og CopilotKit med både vendor‑støtte og SDK’er. Jeg kan næsten høre støjen fra whiteboards hos cloud‑leverandørerne. Vores egen note: det er tit her, det knækker – support kan betyde alt fra en blogpost til en referenceimplementering. Det vender vi tilbage til.

Trelags‑stacken MCP, A2A og AG‑UI
Den tekniske ramme er enkel nok til at huske, men bred nok til at være brugbar: MCP til værktøj og databaseadgang, A2A til agent‑til‑agent koordinering, og AG‑UI til interaktionen mellem bruger, applikation og agent. MarkTechPost er tydelig: AG‑UI er det lag, der manglede. En analogi hjælper her, uden vi tager den for langt: tænk TCP til transport (MCP), HTTP til koordinering og kald (A2A), og HTML som præsentation og interaktion (AG‑UI). Ikke perfekt, men man ser konturerne.
Hvorfor betyder det noget? Fordi de fleste teams har bygget agenter, der enten kan kalde værktøjer eller koordinere sub‑agenter, men som falder til jorden, når de møder rigtig UI‑tilstand, real‑time opdateringer og menneskelige bekræftelser. Uden et eksplicit interaktionslag bliver fejlretning, test og governance op ad bakke. Vi har set præcis det ske i et forsikringsprojekt sidste kvartal; en kollega sagde det tørt: “Vi testede AG‑UI‑mønstre; komponent‑sync var det, der knækkede deployment, ikke NLP‑kvaliteten.”
Hvad AG‑UI lover i praksis
AG‑UI’s pakke ifølge MarkTechPost: real‑time streaming af svar, dynamisk generering af UI‑komponenter, tovejssynk af tilstand, og human‑in‑the‑loop pauser, hvor agenten venter på brugerens godkendelse. Det er ikke pynt. Det er forskellen på en demo og en sagsbehandler, der faktisk tør trykke godkend. I et CRM‑flow kan agenten fx foreslå at oprette en opportunity, vise en lille UI‑komponent med felter udfyldt fra notater, pause for accept, og først derefter kalde CRM‑API’et. Og vigtigere: holde UI og agenttilstand i sync, så der ikke sniger sig dobbeltoprettelser ind.

Et andet eksempel, kortere: en returvare i e‑handel. Agenten identificerer ordren, genererer en return‑label‑komponent og foreslår en kreditering. Brugeren godkender, agenten fortsætter, logger handlingen, og UI’et skifter til “færdig” uden at miste state ved en sideskift. Det lyder banalt, men hvis du har prøvet at få en LLM‑agent, en ordredatabase og et frontend‑framework til at danse synkront, ved du, hvorfor tovejssynk er nøglen – og hvorfor pauserne er jeres forsikring mod utilsigtede handlinger.
Adoption i økosystemet og hvad “support” egentlig betyder
MarkTechPost skriver, at AG‑UI i dag er støttet af Google, Microsoft, Amazon og Oracle, og at rammer som LangChain, Mastra, PydanticAI og Agno er med. Der nævnes førsteparts‑SDK’er til bl.a. LangGraph, CrewAI, Mastra, Agno og Pydantic AI. På community‑siden listes Kotlin, Go, Dart, Java, Rust, Ruby og C++, med .NET, Nim, Flowise og Langflow på vej. Det er en usædvanlig bred overflade for en protokol i den her modenhed.
Men lad os holde fødderne på jorden. “Support” varierer. Kilderne peger på alt fra eksempelkode til integrationer, inklusive at AWS har foldet AG‑UI ind i FAST‑skabeloner og Bedrock AgentCore. Det er stærkt, hvis man faktisk kan starte et produktionsnært forløb derfra. Vi har dog ikke set en officiel, versioneret AG‑UI‑spec fra CopilotKit som primær kilde i vores gennemgang. Så konklusionen er: signalerne er gode, men læs dokumentationen nøje, og test reelt. Blogposts deployer ikke jeres system.

De tre 2026‑prioriteter der ligner housekeeping men afgør alt
CopilotKits 2026‑releaseplan rammer tre hverdagsproblemer, som ofte er overset: knowledge retrieval, testing reliability og runtime persistence. MarkTechPost bruger faktisk ret skarpe formuleringer her. Og det er essensen af at gøre agenter driftbare. Retrieval‑augmented generation (RAG) er mere end et buzzord – det afgør, om agenten bruger jeres data korrekt, versionsstyret og reproducerbart. Testing handler om at gøre uforudsigelige kæder testbare uden teater. Persistence er evnen til at dø og genopstå uden at miste hukommelsen.
Vi hæfter os ved værktøjer som AIMock, som MarkTechPost beskriver som en direkte reaktion på, at agentiske tests ofte er skuespil. En agent rammer mange ydre services per kald; hvis bare én er mock’et og de andre er live, tester man ikke det, man tror. Uanset om I bruger CopilotKits værktøj eller ruller jeres eget, bør I adressere hele kæden. Vores praktiske råd: byg et test‑harness, der kan mocke LLM, vektorbase, værktøjsserver, søgning og A2A‑undermotorer i ét skud – og tydeligt slår over til live i trin.
Sikkerhed, governance og brugerens hånd på bremsen
AG‑UI’s human‑in‑the‑loop pauser og transparens er ikke en “nice to have”. De er governance i UI‑tøj. Når agenten foreslår en handling, viser komponenten, hvad der sker, og venter på accept. Det reducerer risikoen for tavse fejl og hjælper audit. Men der er åbne flanker. Kilderne beskriver ikke detaljeret, hvordan autorisation på tværs af værktøjer håndteres, eller hvordan action‑level logs forenes med dataminimering og retention‑politikker. Her skal sikkerhedsarkitekten ind tidligt, ellers sidder supporten om tre måneder og samler stumper op.
Vi anbefaler som minimum: rollebaseret godkendelse på kritiske actions, action‑scoped logging med revisionsspor, dataklassifikation i retrieval‑laget, og klare timeouts for pauser, så agenter ikke hænger i limbo. Og, en lille ting vi lærte på den hårde måde, lav særskilt alerting for “gentagne afviste forslag”. Det lugter tit af prompt‑fejl, forældede værktøjs‑skemaer eller en autorisationsnøgle, der er udløbet.
Konkurrencebilledet og hvorfor modelkraft ikke redder jer alene
Alibaba’s Qwen3.7‑Max er et godt reality‑check. VentureBeat refererer cirka 35 timers autonom kørsel og understreger samtidig, at modellen er proprietær. Dygtigt, uden tvivl. Men en udholdende motor uden styret interaktion, testbarhed og persistence er bare en stærk motor på et stativ. CopilotKits AG‑UI adresserer netop, hvordan motoren lægges ned i bilen, hvor rattet sidder, og hvor bremserne er.
Andre stacks sigter ren A2A‑koordinering eller model‑centrisk orchestration. Det er nyttigt, men hvis UI‑laget ikke har en protokol, får I en rodebunke af specialkomponenter, der ikke kan testes ensartet eller auditeres. Vores holdning er ikke neutral her: protokol på interaktion er en praktisk nødvendighed, uanset om den hedder AG‑UI eller noget andet. Det kan diskuteres, hvor hurtigt standardisering sker, men retningen virker rigtig.


Konsekvenser for CTO, Head of Automation og DevOps
Arkitektur: planlæg for bidirektionel state‑sync i frontend fra dag ét. Det ændrer jeres API‑kontrakter, fordi actions ikke bare er POST‑kald, men også UI‑ændringer og agent‑tjekpunkter, der skal gemmes. Vælg SDK’er i frontend (React, Kotlin m.fl.) ud fra modenhed i AG‑UI‑understøttelse og jeres teams kompetencer – ikke kun features på slidedecks.
Teststrategi: byg en agent‑harness, der kan køre timelange integrationstests med fault‑injection. Tving retries, drop netværk, og tjek state‑reconciliation. Ja, det er dyrt og lidt kedeligt. Det er også forskellen på en POC og noget, der kan få en vagtordning til at sove trygt. Drift: indfør runtime‑persistence med checkpointing, så agenter kan genstarte uden at miste sagskontekst. Det kræver state stores, versionerede RAG‑indeks og runbooks for recovery, så SRE kan måle MTTD\/MTTR på agentniveau.
Hvad vi har set gå galt i felten
Vi har set POC’er løbe tør på tre måneder, fordi ingen planlagde for persistens. Sessions døde, sager hang, og supporten lappede manuelt. Vi har set dataforurening i RAG, fordi ingen versionerede indeks og kørte smoke‑tests efter opdateringer. Og vi har set UI‑komponenter, som agenten troede fandtes, men som frontend‑teamet refaktoriserede i sprintet inden – uden kontrakt.
Vores korte checkliste, som vi nu altid bruger: frys et minimalt AG‑UI‑komponentsæt pr. flow, versioner RAG‑kilder og indeks, mock hele kæden i test, og log alle agent‑actions med en kort begrundelse. Det tager to uger at sætte op ordentligt. Det sparer to måneder senere. En lidt skæv detalje herfra: i et kundelokale i Skejby kunne man høre ventilationsanlægget overdøve vores egne “hvorfor fejler den nu igen?” – det var dagen, vi indførte action‑scoped logging.
Tradeoffs og leverandørbinding
Når store clouds melder “support”, går ting hurtigere, men I betaler med lock‑in, især hvis særlige runtime‑features kun findes på én platform. Overvej bevidst, hvor I vil være proprietære, og hvor I kræver portabilitet. AG‑UI’s brede SDK‑overflade kan hjælpe, men den er ikke en tryllestav. Der kan også komme fragmentering, hvis flere protokoller konkurrerer om samme lag, før en de‑facto standard lander.
På omkostninger: længere autonome forløb som Qwen3.7‑Max demonstrerer teknisk mulighed, men også regningen. Budgetter for modelkørsel, state stores og udvidet monitorering er ikke småpenge. ROI findes i de arbejdsgange, hvor agenter fjerner manuelle oversættelser mellem systemer – fx sagsbehandling og compliance‑tjek – ikke i brede, generelle assistenter, der “kan lidt af alt”.
Rapportering, huller og hvad vi stadig mangler at se
Vi har krydschecket påstandene med MarkTechPost som primær kilde for CopilotKit og AG‑UI, og VentureBeat for Qwen3.7‑Max. Der er dog huller. Vi mangler en officiel, versioneret AG‑UI‑spec eller whitepaper som entydig reference. “Support” fra clouds kan dække alt fra eksempler til dyb integration; uden officiel cloud‑dokumentation er det klogt at antage, at nogle dele er i “eksempel‑stadiet”.
Vi har heller ikke set uafhængige benchmarks for AG‑UI’s påvirkning af reliabilitet eller persistence i produktion. Og vi mangler kommercielle referencecases i drift på AG‑UI. Det ændrer ikke ved, at retningen giver mening. Men det kræver, at tekniske ledere stiller krav om testbare kontrakter og versionering, ikke bare demoer og GitHub‑stjerner.
Hvad man kan gøre i morgen uden store armbevægelser
Start med jeres vigtigste agent‑flow og tegn det som en tilstandsmaskine med pauser, godkendelser og forventede UI‑komponenter. Indfør versioneret RAG for de datakilder, flowet kræver. Skriv tre integrationstests, som løber i mindst 30 minutter, med bevidste fejl injiceret i én ekstern service ad gangen. Og vælg en persistence‑strategi: hvor ligger state, hvordan tages checkpoints, hvordan rehydrerer I efter nedbrud.
Udpeg en ansvarlig for human‑in‑the‑loop og auditsporet. Ikke en komité, én person. Sæt et mål for “mean time to safe‑stop” når en agent tvivler, og mål på det. Det lyder småt, men det er her, modenheden starter. Vi tror adoption kan gå hurtigt i 2026 – men kun for teams, der accepterer, at det hårde arbejde ligger i test, persistence og UI‑kontrakter, ikke i den næste model med flere parametre.