Den agentiska infrastrukturen och den nya backend

spinny:~/writing $ vim agentic-infrastructure-stack.md

1~
2Vi 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.
3~
4Frågan är inte längre bara: vilket bibliotek använder jag för att få en stegmodell att tänka?
5~
6Den verkliga frågan är: var bor den här agenten när han slutar vara en demo?
7~
8Eftersom 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.
9~
10Ramen är ratten. Infrastrukturen är vägen, bromsarna, garaget, försäkringen och personen som vet var nycklarna finns.
11~
12## För det pratas mycket om det nu
13~
14Under 2023 och 2024 var samtalet väldigt modellcentrerat. Vilken LLM? Hur mycket sammanhang? Hur mycket kostar det? Hur bra är han på att programmera?
15~
162025 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.
17~
18Det är den naturliga övergången från magi till ingenjörskonst.
19~
20Nä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.
21~
22Inte i bokstavlig mening. I organisatorisk mening.
23~
24## Den första biten: en körtid där agenten kan hålla
25~
26En agent arbetar ofta i steg. Titta på tillståndet, välj en åtgärd, använd ett verktyg, observera resultatet, uppdatera planen, upprepa.
27~
28Om 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.
29~
30Det ä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.
31~
32För mig måste den agentiska körtiden svara på mycket konkreta frågor:
33~
34- var sparar jag tillståndet mellan ett steg och ett annat?
35- vad händer om processen dör halvvägs?
36- kan jag pausa och be om godkännande?
37- kan jag spela om en löprunda för att förstå varför han gjorde det valet?
38- kan jag begränsa varaktighet, minne, verktyg och kostnad?
39~
40Vercel 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.
41~
42## Den andra biten: sandlåda, eftersom agenten måste kunna bli smutsig utan att gå sönder
43~
44Så snart en agent skriver kod eller kör kommandon behövs en sandlåda.
45~
46Det 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.
47~
48En agentsandlåda bör ha några egenskaper:
49~
50- isolerat filsystem;
51- CPU, minne och tidsgränser;
52- kontrollerat nätverk;
53- hemligheter monterade endast vid behov;
54- kompletta loggar;
55- Möjlighet att exportera artefakter;
56- ren återställning mellan körningarna, vid behov.
57~
58Vercel 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.
59~
60Det 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.
61~
62Sandlådan är det vuxna sättet att säga: varsågod, men här inne.
63~
64## Den tredje delen: MCP och anslutningsproblemet
65~
66Model 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.
67~
68Utan 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.
69~
70MCP 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.
71~
72Och 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?".
73~
74Fö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.
75~
76I en bra agentarkitektur blir MCP en sorts patchpanel:
77~
78- GitHub för kod och problem;
79- Slack för konversationssammanhang;
80- Linjär eller Jira för planerat arbete;
81- skrivskyddad databas för analys;
82- webbläsare eller skrapa kontrollerad för externa webbplatser;
83- lagring av dokument;
84- isolerade exekveringsmiljöer;
85- interna system exponerade med strikta behörigheter.
86~
87Den knepiga delen är att en policyfri verktygskatalog bara är ett mer elegant sätt att skapa kaos.
88~
89## Den fjärde biten: identitet och behörigheter
90~
91Det här är området där många demos blundar.
92~
93En agent agerar för någons räkning. Så det måste framgå vem som är föremål för handlingen.
94~
95Anvä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?
96~
97Om 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.
98~
99Den 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.
100~
101Detta innebär OAuth, token scoped, hemlig hantering, granskningslogg, verktygspolicy, godkännandelista, godkännandesteg. Inte särskilt romantiska saker. Nödvändiga grejer.
102~
103## Det femte stycket: minne och sammanhang, men utan att samla på sig skräp
104~
105Agenter behöver minne, men minnet är farligt när det blir en vind.
106~
107Det finns minst tre typer av minne:
108~
109- körminne: vad som hände i denna körning;
110- projektminne: konventioner, beslut, begränsningar;
111- personligt eller teamminne: preferenser, ton, ritualer, processer.
112~
113Att 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.
114~
115En agent som minns dåligt är värre än en agent som inte minns. För att han talar med tillförsikt.
116~
117Dä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.
118~
119## Det sjätte stycket: observerbarhet, eval och repris
120~
121Om en agent gör ett misstag räcker inte loggen "kallad modellen".
122~
123Du 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?
124~
125Här är agenterna mer som distribuerade system än chatbots.
126~
127Du 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".
128~
129Agentevaler ä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.
130~
131Det 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.
132~
133## Det sjunde stycket: mänskliga gränssnitt
134~
135Agenten behöver inte bara leva i en chatt.
136~
137Vissa 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.
138~
139Anvä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.
140~
141En anständig agentinfrastruktur inkluderar kontrollytor:
142~
143- aktuell status;
144- redigerbar plan;
145- producerade artefakter;
146- diff;
147- godkännandeförfrågningar;
148- kronologi;
149- stoppknapp;
150- Försök igen-knapp;
151- synliga behörigheter.
152~
153Det 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.
154~
155## Den mentala stacken
156~
157Om jag skulle rita det idag, skulle den minsta agentstacken vara denna:
158~
1591. Modell: resonemang, generering, verktygsanrop, multimodal vid behov.
1602. Orkestrering: slinga, steg, planerare, policy, människa-i-slingan.
1613. Hållbar körtid: arbetsflöde, kö, försök igen, pausa, återuppta.
1624. Sandlåda: kodexekvering, isolerat filsystem, begränsningar, artefakter.
1635. Verktygslager: MCP, internt API, webbläsare, databas, arkiv.
1646. Identitetslager: OAuth, scope, secret, audit, policy.
1657. Minneslager: projektkontext, hämtning, instruktioner, utgång.
1668. Observerbarhet: spårning, replay, eval, kostnad och kvalitetsmått.
1679. Produktyta: chatta när det räcker, instrumentpanelen när det behövs, granska när det är viktigt.
168~
169Det agentiska ramverket omfattar huvudsakligen punkt 2 och en del av punkt 1. Resten är det verkliga arbetet.
170~
171## Vad jag skulle göra i praktiken
172~
173Om ett team sa till mig att "vi vill ha agenter i produktionen" skulle jag inte börja med tio agenter.
174~
175Jag 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.
176~
177Då skulle jag sätta mycket tydliga gränser:
178~
179- ingen skrift utan grenar eller sandlåda;
180- inga hemligheter i prompten;
181- verktyg i godkännandelistan;
182- Mänskligt godkännande för yttre åtgärder.
183- obligatorisk logg och spårning;
184- budget per körning;
185- utgång alltid inspekterbar.
186~
187Först då skulle jag expandera.
188~
189Agenter 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.
190~
191## Min läsning
192~
193Agent infrastruktur är tråkig på bästa sätt.
194~
195Det ä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.
196~
197Agenternas 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.
198~
199Det är där agenter slutar vara en leksak och blir infrastruktur.
200~
201## Källor
202~
203- [Vercel: Hur man bygger AI-agenter med Vercel och 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: Nya verktyg för byggagenter](https://openai.com/index/new-tools-for-building-agents/)
209- [Cloudflare Blog: Agents on Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)
210~

NORMAL · agentic-infrastructure-stack.md [readonly]210 lines · :q to close

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

4Frågan är inte längre bara: vilket bibliotek använder jag för att få en stegmodell att tänka?

6Den verkliga frågan är: var bor den här agenten när han slutar vara en demo?

8Eftersom 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.

10Ramen är ratten. Infrastrukturen är vägen, bromsarna, garaget, försäkringen och personen som vet var nycklarna finns.

11~

12## För det pratas mycket om det nu

13~

14Under 2023 och 2024 var samtalet väldigt modellcentrerat. Vilken LLM? Hur mycket sammanhang? Hur mycket kostar det? Hur bra är han på att programmera?

15~

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

17~

18Det är den naturliga övergången från magi till ingenjörskonst.

19~

20Nä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.

21~

22Inte i bokstavlig mening. I organisatorisk mening.

23~

24## Den första biten: en körtid där agenten kan hålla

25~

26En agent arbetar ofta i steg. Titta på tillståndet, välj en åtgärd, använd ett verktyg, observera resultatet, uppdatera planen, upprepa.

27~

28Om 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.

29~

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

31~

32För mig måste den agentiska körtiden svara på mycket konkreta frågor:

33~

34- var sparar jag tillståndet mellan ett steg och ett annat?

35- vad händer om processen dör halvvägs?

36- kan jag pausa och be om godkännande?

37- kan jag spela om en löprunda för att förstå varför han gjorde det valet?

38- kan jag begränsa varaktighet, minne, verktyg och kostnad?

39~

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

41~

42## Den andra biten: sandlåda, eftersom agenten måste kunna bli smutsig utan att gå sönder

43~

44Så snart en agent skriver kod eller kör kommandon behövs en sandlåda.

45~

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

47~

48En agentsandlåda bör ha några egenskaper:

49~

50- isolerat filsystem;

51- CPU, minne och tidsgränser;

52- kontrollerat nätverk;

53- hemligheter monterade endast vid behov;

54- kompletta loggar;

55- Möjlighet att exportera artefakter;

56- ren återställning mellan körningarna, vid behov.

57~

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

59~

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

61~

62Sandlådan är det vuxna sättet att säga: varsågod, men här inne.

63~

64## Den tredje delen: MCP och anslutningsproblemet

65~

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

67~

68Utan 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.

69~

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

71~

72Och 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?".

73~

74Fö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.

75~

76I en bra agentarkitektur blir MCP en sorts patchpanel:

77~

78- GitHub för kod och problem;

79- Slack för konversationssammanhang;

80- Linjär eller Jira för planerat arbete;

81- skrivskyddad databas för analys;

82- webbläsare eller skrapa kontrollerad för externa webbplatser;

83- lagring av dokument;

84- isolerade exekveringsmiljöer;

85- interna system exponerade med strikta behörigheter.

86~

87Den knepiga delen är att en policyfri verktygskatalog bara är ett mer elegant sätt att skapa kaos.

88~

89## Den fjärde biten: identitet och behörigheter

90~

91Det här är området där många demos blundar.

92~

93En agent agerar för någons räkning. Så det måste framgå vem som är föremål för handlingen.

94~

95Anvä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?

96~

97Om 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.

98~

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

100~

101Detta innebär OAuth, token scoped, hemlig hantering, granskningslogg, verktygspolicy, godkännandelista, godkännandesteg. Inte särskilt romantiska saker. Nödvändiga grejer.

102~

103## Det femte stycket: minne och sammanhang, men utan att samla på sig skräp

104~

105Agenter behöver minne, men minnet är farligt när det blir en vind.

106~

107Det finns minst tre typer av minne:

108~

109- körminne: vad som hände i denna körning;

110- projektminne: konventioner, beslut, begränsningar;

111- personligt eller teamminne: preferenser, ton, ritualer, processer.

112~

113Att 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.

114~

115En agent som minns dåligt är värre än en agent som inte minns. För att han talar med tillförsikt.

116~

117Dä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.

118~

119## Det sjätte stycket: observerbarhet, eval och repris

120~

121Om en agent gör ett misstag räcker inte loggen "kallad modellen".

122~

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

124~

125Här är agenterna mer som distribuerade system än chatbots.

126~

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

128~

129Agentevaler ä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.

130~

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

132~

133## Det sjunde stycket: mänskliga gränssnitt

134~

135Agenten behöver inte bara leva i en chatt.

136~

137Vissa 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.

138~

139Anvä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.

140~

141En anständig agentinfrastruktur inkluderar kontrollytor:

142~

143- aktuell status;

144- redigerbar plan;

145- producerade artefakter;

146- diff;

147- godkännandeförfrågningar;

148- kronologi;

149- stoppknapp;

150- Försök igen-knapp;

151- synliga behörigheter.

152~

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

154~

155## Den mentala stacken

156~

157Om jag skulle rita det idag, skulle den minsta agentstacken vara denna:

158~

1591. Modell: resonemang, generering, verktygsanrop, multimodal vid behov.

1602. Orkestrering: slinga, steg, planerare, policy, människa-i-slingan.

1613. Hållbar körtid: arbetsflöde, kö, försök igen, pausa, återuppta.

1624. Sandlåda: kodexekvering, isolerat filsystem, begränsningar, artefakter.

1635. Verktygslager: MCP, internt API, webbläsare, databas, arkiv.

1646. Identitetslager: OAuth, scope, secret, audit, policy.

1657. Minneslager: projektkontext, hämtning, instruktioner, utgång.

1668. Observerbarhet: spårning, replay, eval, kostnad och kvalitetsmått.

1679. Produktyta: chatta när det räcker, instrumentpanelen när det behövs, granska när det är viktigt.

168~

169Det agentiska ramverket omfattar huvudsakligen punkt 2 och en del av punkt 1. Resten är det verkliga arbetet.

170~

171## Vad jag skulle göra i praktiken

172~

173Om ett team sa till mig att "vi vill ha agenter i produktionen" skulle jag inte börja med tio agenter.

174~

175Jag 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.

176~

177Då skulle jag sätta mycket tydliga gränser:

178~

179- ingen skrift utan grenar eller sandlåda;

180- inga hemligheter i prompten;

181- verktyg i godkännandelistan;

182- Mänskligt godkännande för yttre åtgärder.

183- obligatorisk logg och spårning;

184- budget per körning;

185- utgång alltid inspekterbar.

186~

187Först då skulle jag expandera.

188~

189Agenter 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.

190~

191## Min läsning

192~

193Agent infrastruktur är tråkig på bästa sätt.

194~

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

196~

197Agenternas 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.

198~

199Det är där agenter slutar vara en leksak och blir infrastruktur.

200~

201## Källor

202~

203- [Vercel: Hur man bygger AI-agenter med Vercel och 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: Nya verktyg för byggagenter](https://openai.com/index/new-tools-for-building-agents/)

209- [Cloudflare Blog: Agents on Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)

210~