Vi 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.

Spørgsmålet er ikke længere kun: hvilket bibliotek bruger jeg til at få en stepmodel til at tænke?

Det virkelige spørgsmål er: hvor bor denne agent, når han holder op med at være en demo?

Fordi 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.

Rammen er rattet. Infrastrukturen er vejen, bremserne, garagen, forsikringen og den person, der ved, hvor nøglerne er.

Fordi der er meget snak om det nu

I 2023 og 2024 var samtalen meget modelorienteret. Hvilken LLM? Hvor meget kontekst? Hvor meget koster det? Hvor god er han til at programmere?

I 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.

Det er den naturlige overgang fra magi til teknik.

Nå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.

Ikke i bogstavelig forstand. I organisatorisk forstand.

Det første stykke: en runtime, hvor agenten kan vare

En agent arbejder ofte i trin. Se på tilstanden, vælg en handling, brug et værktøj, observer resultatet, opdater planen, gentag.

Hvis 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.

Det 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.

For mig skal den agentiske runtime besvare meget konkrete spørgsmål:

• hvor gemmer jeg tilstanden mellem et trin og et andet?
• hvad sker der, hvis processen dør halvvejs?
• kan jeg holde pause og bede om godkendelse?
• kan jeg afspille en løbetur for at forstå, hvorfor han tog det valg?
• kan jeg begrænse varighed, hukommelse, værktøjer og omkostninger?

Vercel 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.

Det andet stykke: sandkasse, fordi midlet skal kunne blive snavset uden at gå i stykker

Så snart en agent skriver kode eller udfører kommandoer, er en sandbox nødvendig.

Det 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.

En agentsandkasse bør have nogle egenskaber:

• isoleret filsystem;
• CPU, hukommelse og tidsgrænser;
• kontrolleret netværk;
• hemmeligheder kun monteret, når det er nødvendigt;
• komplette logfiler;
• mulighed for at eksportere artefakter;
• ren nulstilling mellem kørsler, når det er nødvendigt.

Vercel 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.

Denne 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.

Sandkassen er den voksne måde at sige: værsgo, men herinde.

Det tredje stykke: MCP og stikproblemet

Model 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.

Uden 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.

MCP 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.

Og 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?".

For 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.

I en god agentarkitektur bliver MCP en slags patchpanel:

• GitHub til kode og problemer;
• Slap til samtalekontekst;
• Lineær eller Jira til planlagt arbejde;
• skrivebeskyttet database til analyse;
• browser eller skraber kontrolleret til eksterne websteder;
• opbevaring af dokumenter;
• isolerede udførelsesmiljøer;
• interne systemer eksponeret med strenge tilladelser.

Den vanskelige del er, at et politikfrit værktøjskatalog blot er en mere elegant måde at skabe kaos på.

Det fjerde stykke: identitet og tilladelser

Dette er området, hvor mange demoer vender det blinde øje til.

En agent handler på nogens vegne. Så det skal fremgå, hvem der er genstand for handlingen.

Bruger 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?

Hvis 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.

Den 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.

Dette betyder OAuth, token scoped, hemmelig administration, revisionslog, værktøjspolitik, tilladelsesliste, godkendelsestrin. Ikke særlig romantiske ting. Nødvendige ting.

Det femte stykke: hukommelse og kontekst, men uden at akkumulere skrald

Agenter har brug for hukommelse, men hukommelsen er farlig, når den bliver et loft.

Der er mindst tre typer hukommelse:

• Kør hukommelse: hvad skete der i denne udførelse;
• projekthukommelse: konventioner, beslutninger, begrænsninger;
• personlig eller teamhukommelse: præferencer, tone, ritualer, processer.

At 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.

En agent, der husker dårligt, er værre end en agent, der ikke husker det. Fordi han taler med tillid.

Derfor 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.

Det sjette stykke: observerbarhed, eval og replay

Hvis en agent laver en fejl, er loggen "kaldet modellen" ikke nok.

Du 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?

Her ligner agenterne mere distribuerede systemer end chatbots.

Du 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".

Agentevalueringer 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.

Det 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.

Det syvende stykke: menneskelige grænseflader

Agenten behøver ikke bare leve i en chat.

Nogle 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.

Brugergræ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.

En anstændig agentinfrastruktur inkluderer kontroloverflader:

• nuværende status;
• redigerbar plan;
• producerede artefakter;
• diff;
• anmodninger om godkendelse;
• kronologi;
• stop knap;
• Prøv igen-knap;
• synlige tilladelser.

Det 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.

Den mentale stak

Hvis jeg skulle tegne det i dag, ville minimums agentstakken være denne:

1. Model: ræsonnement, generation, værktøjskald, multimodal evt.
2. Orkestrering: loop, step, planner, policy, human-in-the-loop.
3. Holdbar kørselstid: arbejdsgang, kø, prøv igen, pause, genoptag.
4. Sandbox: kodeudførelse, isoleret filsystem, begrænsninger, artefakter.
5. Værktøjslag: MCP, intern API, browser, database, repository.
6. Identitetslag: OAuth, omfang, hemmelighed, revision, politik.
7. Hukommelseslag: projektkontekst, hentning, instruktioner, udløb.
8. Observerbarhed: sporing, replay, eval, omkostninger og kvalitetsmålinger.
9. Produktoverflade: chat når det er nok, dashboard når det er nødvendigt, gennemgå når det betyder noget.

Den agentiske ramme dækker hovedsageligt punkt 2 og et stykke punkt 1. Resten er det rigtige arbejde.

Hvad jeg ville gøre i praksis

Hvis et hold sagde til mig "vi vil have agenter i produktionen", ville jeg ikke starte med ti agenter.

Jeg 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.

Så ville jeg sætte meget klare grænser:

• no writing without branches or sandbox;
• ingen hemmeligheder i prompten;
• værktøjer på tilladelseslisten;
• menneskelig godkendelse af eksterne handlinger;
• obligatorisk log og sporing;
• budget pr. kørsel;
• output altid inspicerbart.

Først da ville jeg udvide.

Agenter fejler ikke, bare fordi modellerne tager fejl. De fejler, fordi vi sætter dem i vage omgivelser med forvirrende tilladelser og teatralske forventninger.

Min læsning

Agent infrastruktur er kedelig på den bedste måde.

Det 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.

Fremtiden 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.

Det er her, agenter holder op med at være et stykke legetøj og bliver til infrastruktur.

Kilder

• Vercel: Sådan bygger du AI-agenter med Vercel og AI SDK
• Vercel Docs: Sandbox
• Vercel Docs: Working with Sandbox
• Vercel Docs: MCP
• Model Context Protocol: Specification
• OpenAI: Nye værktøjer til byggeagenter
• Cloudflare Blog: Agents on Cloudflare