Det mesta av all hosting är utformat kring en människa vid tangentbordet: ett registreringsformulär, ett kort, en panel, ett mejl när något går fel. En AI-agent som behöver beräkningskraft passar inte in i något av de stegen. Den löser ingen captcha, skiljer inte en underhållssida från en trasig och märker inte att den har skapat samma server fyrtio gånger.
Det är frestande att säga ”ge den bara ett API”. Det är det första kravet, inte det sista. Här är sju som vi tycker spelar roll, utifrån arbetet med vår egen MCP-server och vårt REST-API för agenter. För varje krav: vad som går fel utan det.
1. Allt en agent behöver går att programmera
Att skapa, inspektera, ändra storlek på och radera resurser måste fungera utan webbläsare. Inklusive de tråkiga delarna: ta reda på priset före köpet, kontrollera om en plats har kapacitet, läsa lösenordet till en ny maskin, säga upp.
Utan det: agenten tar sig 80 % av vägen och fastnar på det enda steget som kräver ett klick, och en människa måste slutföra jobbet ändå. Ett halvt API är ofta värre än inget alls, eftersom det inbjuder till automatisering som inte kan bli klar.
2. Fel som ett program kan agera på
En agent läser ett svar och avgör vad som ska hända härnäst. En JSON-kropp med en stabil kod (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded med tidpunkten då gränsen nollställs) är något den kan förgrena sig på. En HTML-felsida, eller en 500 med ett vagt meddelande, lämnar den att gissa — ofta genom att försöka igen med något som aldrig kommer att lyckas.
Utan det: omförsöksloopar. De dyraste misslyckandena för agenter är oftast inte felaktiga beslut, utan samma misslyckade anrop upprepat tusentals gånger.
3. Betalning utan en människa i loopen
Kortbetalningar är fulla av steg som ska bekräfta att en människa är närvarande: 3-D Secure-koder, bekräftelser i bankappen, identitetskontroller. De är bra mot bedrägerier och omöjliga för programvara. Ett förbetalt saldo, påfyllt i förväg (hos oss ofta med stablecoins), låter en agent betala för det den använder utan att en människa godkänner varje debitering.
Utan det: antingen godkänner en människa varje köp, vilket gör det hela meningslöst, eller så ger någon en agent ett kort, en risk ingen borde ta.
4. Hårda utgiftsgränser
Ett förbetalt saldo begränsar det värsta fallet till det som finns på det. Det kan fortfarande vara mycket. En dags- och månadsgräns i dollar, upprätthållen av plattformen i stället för av agentens goda avsikter, gör en agent i en loop till en liten förlust. Gränsen ska slå till tydligt, med ett fel som agenten känner igen, och stoppa eller pausa det som körs.
Utan det: du upptäcker loopen via saldot. Vår debitering av sandboxar har gränser av just det skälet, och sidan MCP-skydd föreslår vilka åtgärder som över huvud taget borde kräva en människas godkännande.
5. Beräkningskraft med rätt granularitet
Agenter producerar tre väldigt olika sorters arbete:
- Sekunder: köra ett genererat kodstycke, kontrollera ett svar, prova en fix.
- Timmar: en utvärdering, en skrapning, ett långt bygge.
- Alltid igång: en bot, ett API, en schemalagd worker.
En plattform som bara erbjuder månadsservrar gör den första sorten absurt dyr; en som bara erbjuder kortlivade sandboxar gör den tredje bräcklig. En uppgift på 20 sekunder på en maskin som debiteras per timme betalar för 59 minuter ingenting. Hur debitering per sekund fungerar visar var varje modell slutar vara rimlig.
Utan det: agenter betalar antingen för mycket för kort arbete eller kör långlivade tjänster på infrastruktur som inte var tänkt att vara igång.
6. Isolering som standard
Kod som en agent skriver är kod som ingen har granskat. Den bör köras där inget av värde finns: inte på agentens egen värd, inte på en server med dina nycklar, inte på maskinen som skickar din e-post. I praktiken betyder det en separat VM eller microVM per uppgift, raderad efteråt. Isoleringsnivåer för opålitlig kod jämför alternativen; Firecracker-microVM:er på ren svenska förklarar varför en egen kärna spelar roll.
Utan det: den första prompt injection som tar sig in i genererad kod får tillgång till allt som agentens värd kan nå.
7. Insyn och en avstängningsknapp
Människan som ansvarar för en agent måste kunna se vad den gjort och stoppa den snabbt. Det innebär användning och kostnad per resurs, en lista över allt agenten skapat och ett sätt att radera allt. Inloggningsuppgifter bör kunna återkallas och vara tillräckligt kortlivade för att en läckt token inte ska gälla för evigt, med ett sätt att förnya dem som inte kräver en människa.
Utan det: städningen blir arkeologi. Bortglömda resurser fortsätter att debiteras; en läckt token fortsätter att fungera.
Vad agenter inte behöver
Lika talande är det som inte hjälper: paneler byggda för merförsäljning, välkomstmejl, tariffer vars verkliga gränser står i en fotnot, priser som syns först efter registrering. Inget av det går att läsa för programvara, och en del av det vilseleder aktivt en modell som tar text bokstavligt.
Vad som fortfarande är olöst
Allt här är inte lösta tekniska problem.
- Ansvar. Någon är ansvarig för vad en agent gör med ett konto. Plattformar behöver ett sätt att koppla automatiserad aktivitet till en ansvarig person utan att tvinga den personen genom varje steg.
- Missbruk. Öppen, helt automatiserad registrering är precis vad missbrukare också vill ha. Varje plattform som tjänar agenter väger friktionsfri åtkomst mot kontofarmar och mining, och ingen har ett perfekt svar.
- Långa flöden. Agenter misslyckas fortfarande oftare med processer i tio steg än med enskilda anrop. Infrastruktur kan hjälpa till genom att göra varje steg idempotent och dess tillstånd lätt att fråga efter, så att ett omförsök fortsätter i stället för att duplicera.
Var vi har landat
Vi har försökt bygga för de här kraven i stället för runt dem: en MCP-server och ett REST-API som täcker hela livscykeln, maskinläsbara fel, ett förbetalt saldo, utgiftsgränser, kodsandboxar per sekund för kort arbete och månadsservrar som tariffen AI agent för långt arbete. En genomgång av sandboxsidan finns i sandbox för AI-agenter. Bedöm ändå listan på egna meriter: den är en användbar checklista för varje plattform som du släpper lös en agent på.
Kommentarer
Inga kommentarer än. Bli först.