1 
2Vi har ofte talt om agentiske rammer. LangGraph, CrewAI, AutoGen, forskellige SDK'er, loop, værktøjsopkald, hukommelse, planlægger, kritiker, supervisor. Alle nyttige ord, for guds skyld. Men jo mere jeg ser på de midler, der rent faktisk bruges, jo mere forekommer det mig, at den interessante del er rykket under rammeniveauet.
3 
4Spørgsmålet er ikke længere kun: hvilket bibliotek bruger jeg til at få en stepmodel til at tænke?
5 
6Det virkelige spørgsmål er: hvor bor denne agent, når han holder op med at være en demo?
7 
8Fordi en seriøs agent ikke er en funktion, der kalder en model og returnerer tekst. Det er et lille distribueret system. Den skal læse kontekst, bruge værktøjer, udføre kode, røre ved filer, huske beslutninger, bede om tilladelse, fejle godt, genstarte, forlade logfiler, ikke brænde budgettet og ikke blive til en bulldozer inde i produktionslageret.
9 
10Rammen er rattet. Infrastrukturen er vejen, bremserne, garagen, forsikringen og den person, der ved, hvor nøglerne er.
11 
12## Fordi der er meget snak om det nu
13 
14I 2023 og 2024 var samtalen meget modelorienteret. Hvilken LLM? Hvor meget kontekst? Hvor meget koster det? Hvor god er han til at programmere?
15 
16I 2025 og 2026 har samtalen skiftet. Modellerne er gode nok til at udføre rigtigt arbejde, men det er derfor, de kedelige bits bliver synlige: Runtime, sikkerhed, connectors, identitet, observerbarhed, kodeudførelse, implementering, rollback.
17 
18Det er den naturlige overgang fra magi til teknik.
19 
20Når en agent bare skal generere et svar, er en chat nok. Når du skal åbne en pull-anmodning, forespørge i en database, ringe til en CRM, starte et job, navigere på et websted, læse Slack, kompilere kode og opdatere et dokument, har du brug for et operativsystem omkring det.
21 
22Ikke i bogstavelig forstand. I organisatorisk forstand.
23 
24## Det første stykke: en runtime, hvor agenten kan vare
25 
26En agent arbejder ofte i trin. Se på tilstanden, vælg en handling, brug et værktøj, observer resultatet, opdater planen, gentag.
27 
28Hvis denne løkke lever inde i en enkelt HTTP-anmodning, har du straks et problem. Nogle handlinger er langsomme. Nogle afventer menneskelige input. Nogle fejler og skal prøves igen. Nogle skal overleve en implementering eller timeout.
29 
30Det er her, holdbare arbejdsgange, køer, jobbaggrunde og tilstandsmaskiner kommer i spil. De er ikke glamourøse, men de er forskellen mellem en agent, der virker smart på demo, og en, du kan lade arbejde, mens du går og henter kaffe.
31 
32For mig skal den agentiske runtime besvare meget konkrete spørgsmål:
33 
34- hvor gemmer jeg tilstanden mellem et trin og et andet?
35- hvad sker der, hvis processen dør halvvejs?
36- kan jeg holde pause og bede om godkendelse?
37- kan jeg afspille en løbetur for at forstå, hvorfor han tog det valg?
38- kan jeg begrænse varighed, hukommelse, værktøjer og omkostninger?
39 
40Vercel presser hårdt på på denne front med AI SDK'er, funktioner, arbejdsgange og værktøjer til byggeagenter inden for webapplikationer. Men pointen er ikke kun Vercel. Pointen er, at agenten har brug for et operationelt hjem, ikke et enkelt endepunkt.
41 
42## Det andet stykke: sandkasse, fordi midlet skal kunne blive snavset uden at gå i stykker
43 
44Så snart en agent skriver kode eller udfører kommandoer, er en sandbox nødvendig.
45 
46Det virker som et teknisk ord, men ideen er hjemlig: du giver ham et arbejdsbord. Det kan åbne filer, installere afhængigheder, køre test, lave eksperimenter, generere output. Hvis han tager fejl, har du indeholdt skaden. Hvis det virker, skal du fremme resultatet.
47 
48En agentsandkasse bør have nogle egenskaber:
49 
50- isoleret filsystem;
51- CPU, hukommelse og tidsgrænser;
52- kontrolleret netværk;
53- hemmeligheder kun monteret, når det er nødvendigt;
54- komplette logfiler;
55- mulighed for at eksportere artefakter;
56- ren nulstilling mellem kørsler, når det er nødvendigt.
57 
58Vercel Sandbox går præcis i denne retning: isolerede miljøer til at køre kode, installere afhængigheder, arbejde med filer og producere artefakter uden at køre alt i hovedapplikationens runtime.
59 
60Denne ting er vigtigere, end den ser ud til. Mange agentiske prototyper springer direkte fra modellen til det rigtige system. Modellen kan kalde værktøj. Værktøjer kan gøre ting. Det hele virker elegant indtil den første forkerte kommando, den første afhængighed installeret på det forkerte sted, det første token, der ender i en log.
61 
62Sandkassen er den voksne måde at sige: værsgo, men herinde.
63 
64## Det tredje stykke: MCP og stikproblemet
65 
66Model Context Protocol er blevet en af de mest interessante dele af økosystemet, fordi den forsøger at standardisere noget, der ellers hurtigt bliver uoverskueligt: hvordan en model opdager og bruger eksterne værktøjer.
67 
68Uden en standard er hver integration en lille ø. En forbindelse til GitHub udført på én måde, én til Slack på en anden måde, én til databaser med forskellig semantik, én til browserautomatisering, der ikke ligner noget.
69 
70MCP foreslår et fælles sprog mellem klient og server: værktøjer, ressourcer, prompter, autorisationer, transport, opdagelse. Det løser ikke på magisk vis styring og sikkerhed, men det giver en grammatik.
71 
72Og grammatik betyder noget. Når en agent kan oprette forbindelse til mange værktøjer, er spørgsmålet ikke kun "kan han gøre det?". Problemet er "forstår han, hvad han kan, med hvilke grænser, på vegne af hvem, og efterlader han hvilke spor?".
73 
74For mig er MCP ikke hype, fordi det "gør tool calling". Det har vi allerede gjort. Det er hype, fordi det flytter tyngdepunktet fra enkelt integration til det operationelle katalog over værktøjer.
75 
76I en god agentarkitektur bliver MCP en slags patchpanel:
77 
78- GitHub til kode og problemer;
79- Slap til samtalekontekst;
80- Lineær eller Jira til planlagt arbejde;
81- skrivebeskyttet database til analyse;
82- browser eller skraber kontrolleret til eksterne websteder;
83- opbevaring af dokumenter;
84- isolerede udførelsesmiljøer;
85- interne systemer eksponeret med strenge tilladelser.
86 
87Den vanskelige del er, at et politikfrit værktøjskatalog blot er en mere elegant måde at skabe kaos på.
88 
89## Det fjerde stykke: identitet og tilladelser
90 
91Dette er området, hvor mange demoer vender det blinde øje til.
92 
93En agent handler på nogens vegne. Så det skal fremgå, hvem der er genstand for handlingen.
94 
95Bruger det brugertilladelser? Af en servicekonto? Af en arbejdsplads? Har du midlertidig eller permanent adgang? Kan du læse alt eller bare nogle ressourcer? Kan du skrive? Kan du aflyse? Kan han skrive til rigtige mennesker?
96 
97Hvis du ikke besvarer disse spørgsmål godt, vil du før eller siden bygge en assistent med husnøgler og ingen hukommelse om, hvem der gav ham dem.
98 
99Den tommelfingerregel, jeg godt kan lide, er denne: agenten skal være i stand til at gøre mindre end mennesket, ikke mere end mennesket. Og når han skal gøre noget mere risikabelt, må han stoppe op og spørge.
100 
101Dette betyder OAuth, token scoped, hemmelig administration, revisionslog, værktøjspolitik, tilladelsesliste, godkendelsestrin. Ikke særlig romantiske ting. Nødvendige ting.
102 
103## Det femte stykke: hukommelse og kontekst, men uden at akkumulere skrald
104 
105Agenter har brug for hukommelse, men hukommelsen er farlig, når den bliver et loft.
106 
107Der er mindst tre typer hukommelse:
108 
109- Kør hukommelse: hvad skete der i denne udførelse;
110- projekthukommelse: konventioner, beslutninger, begrænsninger;
111- personlig eller teamhukommelse: præferencer, tone, ritualer, processer.
112 
113At sætte alt i prompten er genvejen. Det virker indtil det ikke virker mere. Nyttig hukommelse skal tages hånd om: indekseret, opdateret, udløbet, verificeret, gjort citerbar.
114 
115En agent, der husker dårligt, er værre end en agent, der ikke husker det. Fordi han taler med tillid.
116 
117Derfor skal infrastrukturen omfatte genfinding, instruktionsfiler, vidensbase, indlejring efter behov, men også rengøring. Vi har brug for en hukommelseskultur: hvad der kommer ind, hvem godkender det, når det forfalder, hvordan retter jeg det.
118 
119## Det sjette stykke: observerbarhed, eval og replay
120 
121Hvis en agent laver en fejl, er loggen "kaldet modellen" ikke nok.
122 
123Du vil gerne se ruten. Hvilken kontekst fik han? Hvilke værktøjer var tilgængelige? Hvilket værktøj valgte du? Med hvilke argumenter? Hvilken respons fik du? Hvor meget kostede det? Hvor satte den sig fast? Godkendte mennesket noget? Er fejlmodellen, værktøjet, prompten, data eller tilladelse fejl?
124 
125Her ligner agenterne mere distribuerede systemer end chatbots.
126 
127Du har brug for læsbare spor, ikke kun tekstlogfiler. Du skal være i stand til at genspille et løb. Det er nødvendigt at sammenligne to versioner af den samme agent på kendte opgaver. Vi er nødt til at måle regressioner: ikke kun "svarer den bedre", men den "lukker den rigtige billet uden at røre uopfordrede filer".
128 
129Agentevalueringer er sværere end tekstevaler, fordi de inkluderer handlinger. Det er ikke nok at sammenligne en forventet streng. Du skal se på sekvenser, bivirkninger, kvalitet af artefakten, tid, omkostninger, antal menneskelige indgreb.
130 
131Det sjove er, at vi altid kommer tilbage dertil: softwareudvikling. Tests, miljøer, spor, rollbacks. Bortset fra at koden nu også bestemmer hvad der skal gøres.
132 
133## Det syvende stykke: menneskelige grænseflader
134 
135Agenten behøver ikke bare leve i en chat.
136 
137Nogle agenter har brug for en bestyrelse. Andre en side med status og log. Andre af en "godkend" knap. Flere indlejrede kommentarer. Atter andre af en CLI.
138 
139Brugergrænsefladen ændrer adfærd. Hvis den eneste måde at kontrollere en agent på er at skrive en lang besked, vil brugeren give agenten vage instruktioner. Hvis han imidlertid ser planen, forskellen, kilderne, risici og næste handling, kan han gribe præcist ind.
140 
141En anstændig agentinfrastruktur inkluderer kontroloverflader:
142 
143- nuværende status;
144- redigerbar plan;
145- producerede artefakter;
146- diff;
147- anmodninger om godkendelse;
148- kronologi;
149- stop knap;
150- Prøv igen-knap;
151- synlige tilladelser.
152 
153Det virker trivielt, men det er det ikke. Forskellen på "creepy AI" og "reliable assistant" er ofte bare, at sidstnævnte viser dig, hvor den har sine hænder.
154 
155## Den mentale stak
156 
157Hvis jeg skulle tegne det i dag, ville minimums agentstakken være denne:
158 
1591. Model: ræsonnement, generation, værktøjskald, multimodal evt.
1602. Orkestrering: loop, step, planner, policy, human-in-the-loop.
1613. Holdbar kørselstid: arbejdsgang, kø, prøv igen, pause, genoptag.
1624. Sandbox: kodeudførelse, isoleret filsystem, begrænsninger, artefakter.
1635. Værktøjslag: MCP, intern API, browser, database, repository.
1646. Identitetslag: OAuth, omfang, hemmelighed, revision, politik.
1657. Hukommelseslag: projektkontekst, hentning, instruktioner, udløb.
1668. Observerbarhed: sporing, replay, eval, omkostninger og kvalitetsmålinger.
1679. Produktoverflade: chat når det er nok, dashboard når det er nødvendigt, gennemgå når det betyder noget.
168 
169Den agentiske ramme dækker hovedsageligt punkt 2 og et stykke punkt 1. Resten er det rigtige arbejde.
170 
171## Hvad jeg ville gøre i praksis
172 
173Hvis et hold sagde til mig "vi vil have agenter i produktionen", ville jeg ikke starte med ti agenter.
174 
175Jeg ville starte med en lille, repetitiv og observerbar arbejdsgang. For eksempel: åbne vedligeholdelses-PR'er, opdatere dokumentation fra lukkede problemer, forberede en ugentlig gennemgang, triage duplikerede fejl, generere test for berørte filer.
176 
177Så ville jeg sætte meget klare grænser:
178 
179- no writing without branches or sandbox;
180- ingen hemmeligheder i prompten;
181- værktøjer på tilladelseslisten;
182- menneskelig godkendelse af eksterne handlinger;
183- obligatorisk log og sporing;
184- budget pr. kørsel;
185- output altid inspicerbart.
186 
187Først da ville jeg udvide.
188 
189Agenter fejler ikke, bare fordi modellerne tager fejl. De fejler, fordi vi sætter dem i vage omgivelser med forvirrende tilladelser og teatralske forventninger.
190 
191## Min læsning
192 
193Agent infrastruktur er kedelig på den bedste måde.
194 
195Det er ikke den del, der får dig til at klappe i demoen. Det er den del, der lader dig faktisk bruge demoen mandag morgen med rigtige mennesker, rigtige data og virkelige konsekvenser.
196 
197Fremtiden for agenter afgøres ikke kun af, hvem der har den bedste rollemodel. It will be decided by whoever builds the best place in which to make him work: isolated when he experiments, connected when needed, always observable, authorized with criteria and humble enough to stop when he doesn't know.
198 
199Det er her, agenter holder op med at være et stykke legetøj og bliver til infrastruktur.
200 
201## Kilder
202 
203- [Vercel: Sådan bygger du AI-agenter med Vercel og AI SDK](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)
204- [Vercel Docs: Sandbox](https://vercel.com/docs/sandbox)
205- [Vercel Docs: Working with Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)
206- [Vercel Docs: MCP](https://vercel.com/docs/mcp)
207- [Model Context Protocol: Specification](https://modelcontextprotocol.io/specification)
208- [OpenAI: Nye værktøjer til byggeagenter](https://openai.com/index/new-tools-for-building-agents/)
209- [Cloudflare Blog: Agents on Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)
210