NAME
agentic-infrastructure-stack — Den agentiska infrastrukturen och den nya backend
SYNOPSIS
cat agentic-infrastructure-stack.md
DESCRIPTION
Vi har ofta pratat om agentiska ramverk. LangGraph, CrewAI, AutoGen, olika SDK:er, loop, verktygsanrop, minne, planerare, kritiker, handledare. Alla användbara ord, för guds skull. Men ju mer jag tittar på de agenter som faktiskt används, desto mer verkar det för mig som att den intressanta delen har flyttat under ramnivån.
Frågan är inte längre bara: vilket bibliotek använder jag för att få en stegmodell att tänka?
Den verkliga frågan är: var bor den här agenten när han slutar vara en demo?
Eftersom en seriös agent inte är en funktion som anropar en modell och returnerar text. Det är ett litet distribuerat system. Den måste läsa sammanhang, använda verktyg, exekvera kod, trycka på filer, komma ihåg beslut, be om tillstånd, misslyckas bra, starta om, lämna loggar, inte bränna budgeten och inte förvandlas till en bulldozer inne i produktionsförvaret.
Ramen är ratten. Infrastrukturen är vägen, bromsarna, garaget, försäkringen och personen som vet var nycklarna finns.
För det pratas mycket om det nu
Under 2023 och 2024 var samtalet väldigt modellcentrerat. Vilken LLM? Hur mycket sammanhang? Hur mycket kostar det? Hur bra är han på att programmera?
2025 och 2026 har samtalet skiftat. Modellerna är tillräckligt bra för att göra riktigt arbete, men det är därför de tråkiga bitarna blir synliga: körtid, säkerhet, kopplingar, identitet, observerbarhet, kodexekvering, distribution, rollback.
Det är den naturliga övergången från magi till ingenjörskonst.
När en agent bara behöver generera ett svar räcker det med en chatt. När du behöver öppna en pull-begäran, fråga efter en databas, ringa en CRM, starta ett jobb, navigera på en sida, läsa Slack, kompilera kod och uppdatera ett dokument, behöver du ett operativsystem runt det.
Inte i bokstavlig mening. I organisatorisk mening.
Den första biten: en körtid där agenten kan hålla
En agent arbetar ofta i steg. Titta på tillståndet, välj en åtgärd, använd ett verktyg, observera resultatet, uppdatera planen, upprepa.
Om den här slingan finns i en enda HTTP-förfrågan har du omedelbart ett problem. Vissa åtgärder är långsamma. Vissa väntar på mänsklig input. Vissa misslyckas och måste prövas igen. Vissa måste överleva en driftsättning eller timeout.
Det är här hållbara arbetsflöden, köer, jobbbakgrunder och tillståndsmaskiner kommer in i bilden. De är inte glamorösa, men de är skillnaden mellan en agent som verkar smart på demo och en som du kan låta jobba medan du går och hämtar kaffe.
För mig måste den agentiska körtiden svara på mycket konkreta frågor:
- var sparar jag tillståndet mellan ett steg och ett annat?
- vad händer om processen dör halvvägs?
- kan jag pausa och be om godkännande?
- kan jag spela om en löprunda för att förstå varför han gjorde det valet?
- kan jag begränsa varaktighet, minne, verktyg och kostnad?
Vercel driver hårt på denna front med AI SDK:er, funktioner, arbetsflöden och verktyg för att bygga agenter inom webbapplikationer. Men poängen är inte bara Vercel. Poängen är att agenten behöver ett operativt hem, inte en enda slutpunkt.
Den andra biten: sandlåda, eftersom agenten måste kunna bli smutsig utan att gå sönder
Så snart en agent skriver kod eller kör kommandon behövs en sandlåda.
Det verkar som ett tekniskt ord, men tanken är inhemsk: du ger honom en arbetsbänk. Det kan öppna filer, installera beroenden, köra tester, göra experiment, generera utdata. Om han gör fel har du hållit tillbaka skadan. Om det fungerar, främja resultatet.
En agentsandlåda bör ha några egenskaper:
- isolerat filsystem;
- CPU, minne och tidsgränser;
- kontrollerat nätverk;
- hemligheter monterade endast vid behov;
- kompletta loggar;
- Möjlighet att exportera artefakter;
- ren återställning mellan körningarna, vid behov.
Vercel Sandbox går exakt i den här riktningen: isolerade miljöer för att köra kod, installera beroenden, arbeta med filer och producera artefakter utan att köra allt i huvudapplikationens runtime.
Det här är viktigare än det verkar. Många agentiska prototyper hoppar direkt från modellen till det verkliga systemet. Modellen kan anropa verktyg. Verktyg kan göra saker. Det hela verkar elegant tills det första fel kommandot, det första beroendet installerat på fel plats, det första token som hamnar i en logg.
Sandlådan är det vuxna sättet att säga: varsågod, men här inne.
Den tredje delen: MCP och anslutningsproblemet
Model Context Protocol har blivit en av de mest intressanta delarna av ekosystemet eftersom det försöker standardisera något som annars snabbt blir ohanterligt: hur en modell upptäcker och använder externa verktyg.
Utan en standard är varje integration en liten ö. En anslutning för GitHub gjort på ett sätt, en för Slack på ett annat, en för databaser med olika semantik, en för webbläsarautomatisering som ser ut som ingenting.
MCP föreslår ett gemensamt språk mellan klient och server: verktyg, resurser, uppmaningar, auktoriseringar, transport, upptäckt. Det löser inte på ett magiskt sätt styrning och säkerhet, men det ger en grammatik.
Och grammatik spelar roll. När en agent kan ansluta till många verktyg är frågan inte bara "kan han göra det?". Problemet är "förstår han vad han kan göra, med vilka gränser, på uppdrag av vem, och lämnar vilka spår?".
För mig är MCP inte hype eftersom det "gör verktygsanrop". Det har vi redan gjort. Det är hype eftersom det flyttar tyngdpunkten från enkel integration till den operativa katalogen av verktyg.
I en bra agentarkitektur blir MCP en sorts patchpanel:
- GitHub för kod och problem;
- Slack för konversationssammanhang;
- Linjär eller Jira för planerat arbete;
- skrivskyddad databas för analys;
- webbläsare eller skrapa kontrollerad för externa webbplatser;
- lagring av dokument;
- isolerade exekveringsmiljöer;
- interna system exponerade med strikta behörigheter.
Den knepiga delen är att en policyfri verktygskatalog bara är ett mer elegant sätt att skapa kaos.
Den fjärde biten: identitet och behörigheter
Det här är området där många demos blundar.
En agent agerar för någons räkning. Så det måste framgå vem som är föremål för handlingen.
Använder det användarbehörigheter? Av ett tjänstekonto? Av en arbetsyta? Har du tillfällig eller permanent tillgång? Kan du läsa allt eller bara några resurser? Kan du skriva? Kan du avboka? Kan han sms:a riktiga människor?
Om du inte svarar bra på dessa frågor kommer du förr eller senare att bygga en assistent med husnycklar och inget minne om vem som gav dem till honom.
Den tumregel jag gillar är denna: agenten måste kunna göra mindre än människan, inte mer än människan. Och när han måste göra något mer riskabelt måste han stanna upp och fråga.
Detta innebär OAuth, token scoped, hemlig hantering, granskningslogg, verktygspolicy, godkännandelista, godkännandesteg. Inte särskilt romantiska saker. Nödvändiga grejer.
Det femte stycket: minne och sammanhang, men utan att samla på sig skräp
Agenter behöver minne, men minnet är farligt när det blir en vind.
Det finns minst tre typer av minne:
- körminne: vad som hände i denna körning;
- projektminne: konventioner, beslut, begränsningar;
- personligt eller teamminne: preferenser, ton, ritualer, processer.
Att lägga allt i prompten är genvägen. Det fungerar tills det inte fungerar längre. Användbart minne måste tas om hand: indexerat, uppdaterat, utgånget, verifierat, gjort citerbart.
En agent som minns dåligt är värre än en agent som inte minns. För att han talar med tillförsikt.
Därför måste infrastrukturen innehålla hämtning, instruktionsfiler, kunskapsbas, inbäddning vid behov, men även städning. Vi behöver en minneskultur: vad kommer in, vem godkänner det, när det förfaller, hur korrigerar jag det.
Det sjätte stycket: observerbarhet, eval och repris
Om en agent gör ett misstag räcker inte loggen "kallad modellen".
Du vill se rutten. Vilket sammanhang fick han? Vilka verktyg fanns tillgängliga? Vilket verktyg valde du? Med vilka argument? Vilken respons fick du? Hur mycket kostade det? Var har det fastnat? Godkände människan något? Är felmodellen, verktyget, prompten, data eller behörighet fel?
Här är agenterna mer som distribuerade system än chatbots.
Du behöver läsbara spår, inte bara textloggar. Du måste kunna spela om en löprunda. Det är nödvändigt att jämföra två versioner av samma agent på kända uppgifter. Vi måste mäta regressioner: inte bara "svarar den bättre", utan den "stänger rätt biljett utan att röra oönskade filer".
Agentevaler är svårare än textevaler eftersom de innehåller åtgärder. Det räcker inte att jämföra en förväntad sträng. Man måste titta på sekvenser, biverkningar, artefaktens kvalitet, tid, kostnad, antal mänskliga ingrepp.
Det roliga är att vi alltid kommer tillbaka dit: mjukvaruteknik. Tester, miljöer, spår, rollbacks. Förutom att koden nu också bestämmer vad som ska göras härnäst.
Det sjunde stycket: mänskliga gränssnitt
Agenten behöver inte bara leva i en chatt.
Vissa agenter behöver en styrelse. Andra en sida med status och logg. Andra av en "godkänn"-knapp. Fler inline-kommentarer. Ytterligare andra av en CLI.
Användargränssnittet ändrar beteende. Om det enda sättet att kontrollera en agent är att skriva ett långt meddelande, kommer användaren att ge agenten vaga instruktioner. Om han däremot ser planen, skillnaden, källorna, riskerna och nästa åtgärd kan han ingripa exakt.
En anständig agentinfrastruktur inkluderar kontrollytor:
- aktuell status;
- redigerbar plan;
- producerade artefakter;
- diff;
- godkännandeförfrågningar;
- kronologi;
- stoppknapp;
- Försök igen-knapp;
- synliga behörigheter.
Det verkar trivialt, men det är det inte. Skillnaden mellan "läskig AI" och "pålitlig assistent" är ofta bara att den senare visar dig var den har sina händer.
Den mentala stacken
Om jag skulle rita det idag, skulle den minsta agentstacken vara denna:
- Modell: resonemang, generering, verktygsanrop, multimodal vid behov.
- Orkestrering: slinga, steg, planerare, policy, människa-i-slingan.
- Hållbar körtid: arbetsflöde, kö, försök igen, pausa, återuppta.
- Sandlåda: kodexekvering, isolerat filsystem, begränsningar, artefakter.
- Verktygslager: MCP, internt API, webbläsare, databas, arkiv.
- Identitetslager: OAuth, scope, secret, audit, policy.
- Minneslager: projektkontext, hämtning, instruktioner, utgång.
- Observerbarhet: spårning, replay, eval, kostnad och kvalitetsmått.
- Produktyta: chatta när det räcker, instrumentpanelen när det behövs, granska när det är viktigt.
Det agentiska ramverket omfattar huvudsakligen punkt 2 och en del av punkt 1. Resten är det verkliga arbetet.
Vad jag skulle göra i praktiken
Om ett team sa till mig att "vi vill ha agenter i produktionen" skulle jag inte börja med tio agenter.
Jag skulle börja med ett litet, repetitivt och observerbart arbetsflöde. Till exempel: öppna underhålls-PR, uppdatera dokumentation från stängda frågor, förbereda en veckogranskning, triage dubbletter av buggar, generera tester för berörda filer.
Då skulle jag sätta mycket tydliga gränser:
- ingen skrift utan grenar eller sandlåda;
- inga hemligheter i prompten;
- verktyg i godkännandelistan;
- Mänskligt godkännande för yttre åtgärder.
- obligatorisk logg och spårning;
- budget per körning;
- utgång alltid inspekterbar.
Först då skulle jag expandera.
Agenter misslyckas inte bara för att modellerna har fel. De misslyckas för att vi sätter dem i vaga miljöer, med förvirrande behörigheter och teatraliska förväntningar.
Min läsning
Agent infrastruktur är tråkig på bästa sätt.
Det är inte delen som får dig att klappa i demot. Det är den del som låter dig faktiskt använda demon på måndag morgon, med riktiga människor, riktiga data och verkliga konsekvenser.
Agenternas framtid avgörs inte bara av vem som har den bästa förebilden. Det kommer att bestämmas av den som bygger den bästa platsen för att få honom att arbeta: isolerad när han experimenterar, uppkopplad när det behövs, alltid observerbar, auktoriserad med kriterier och ödmjuk nog att sluta när han inte vet.
Det är där agenter slutar vara en leksak och blir infrastruktur.
Källor
METADATA
- date: 2026-06-30
- reading: 9 min
- author: Filippo Spinella
- tags: AI, Agents, Infrastructure, Developer Tools, Vercel