−25%

på Windows ved årlig betaling, til 31/10. Se pakkerne

EQVPS
Kom i gang

Hvad AI-agenter virkelig har brug for fra infrastruktur: 7 krav, og hvor hosting bygget til mennesker står i vejen

10. okt. 2026 · 5 min. læsning · EQVPS Team

Det meste hosting er designet omkring et menneske ved tastaturet: en tilmeldingsformular, et kort, et kontrolpanel, en mail, når noget går galt. En AI-agent, der har brug for regnekraft, passer ikke ind i nogen af de trin. Den løser ikke en captcha, kan ikke skelne en vedligeholdelsesside fra en, der er gået i stykker, og opdager ikke, at den har oprettet den samme server fyrre gange.

Det er fristende at sige „bare giv den et API“. Det er det første krav, ikke det sidste. Her er syv, som vi mener betyder noget, ud fra arbejdet med vores egen MCP-server og vores REST-API til agenter. For hvert krav: hvad der går galt uden det.

1. Alt, hvad en agent har brug for, kan programmeres

At oprette, inspicere, ændre størrelse på og slette ressourcer skal virke uden browser. Også de kedelige dele: at kende prisen før købet, tjekke om en lokation har kapacitet, læse adgangskoden til en ny maskine, opsige.

Uden det: agenten kommer 80 % af vejen og går i stå ved det ene trin, der kræver et klik, og et menneske må gøre arbejdet færdigt alligevel. Et halvt API er ofte værre end intet, fordi det indbyder til automatisering, der ikke kan blive færdig.

2. Fejl, som et program kan handle på

En agent læser et svar og beslutter, hvad der skal ske nu. En JSON-krop med en stabil kode (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded med tidspunktet for nulstilling) er noget, den kan forgrene sig på. En HTML-fejlside, eller en 500 med en vag besked, efterlader den til at gætte — ofte ved at prøve igen med noget, der aldrig vil lykkes.

Uden det: genforsøgsløkker. De dyreste fejl hos agenter er som regel ikke forkerte beslutninger, men det samme mislykkede kald gentaget tusindvis af gange.

3. Betaling uden et menneske i løkken

Kortbetalinger er fulde af trin, der skal bekræfte, at et menneske er til stede: 3-D Secure-koder, bekræftelser i bankappen, identitetstjek. De er gode mod svindel og umulige for software. En forudbetalt saldo, fyldt op på forhånd (hos os ofte med stablecoins), lader en agent betale for det, den bruger, uden at et menneske godkender hvert træk.

Uden det: enten godkender et menneske hvert køb, hvilket ødelægger pointen, eller også giver nogen en agent et kort, en risiko, ingen bør løbe.

4. Hårde udgiftsgrænser

En forudbetalt saldo begrænser det værste tilfælde til det, der står på den. Det kan stadig være meget. En dags- og månedsgrænse i dollar, håndhævet af platformen i stedet for af agentens gode hensigter, gør en agent, der kører i ring, til et lille tab. Grænsen skal slå tydeligt til, med en fejl, som agenten genkender, og stoppe eller sætte det, der kører, på pause.

Uden det: du opdager løkken på saldoen. Vores afregning af sandboxe har grænser af netop den grund, og siden MCP-sikkerhedsforanstaltninger foreslår, hvilke handlinger der overhovedet bør kræve et menneskes godkendelse.

5. Regnekraft med den rette granularitet

Agenter producerer tre meget forskellige slags arbejde:

  • Sekunder: køre et genereret kodestykke, tjekke et svar, prøve en rettelse.
  • Timer: en evaluering, en skrabning, et langt build.
  • Altid tændt: en bot, et API, en planlagt worker.

En platform, der kun tilbyder månedsservere, gør den første slags absurd dyr; en, der kun tilbyder kortlivede sandboxe, gør den tredje skrøbelig. En opgave på 20 sekunder på en maskine, der afregnes pr. time, betaler for 59 minutter ingenting. Hvordan afregning pr. sekund fungerer viser, hvor hver model holder op med at give mening.

Uden det: agenter betaler enten for meget for kort arbejde eller kører langvarige tjenester på infrastruktur, der ikke var beregnet til at blive tændt.

6. Isolation som standard

Kode, som en agent skriver, er kode, som ingen har gennemgået. Den bør køre der, hvor intet af værdi findes: ikke på agentens egen vært, ikke på en server med dine nøgler, ikke på maskinen, der sender din mail. I praksis betyder det en separat VM eller microVM pr. opgave, slettet bagefter. Isolationsniveauer for upålidelig kode sammenligner mulighederne; Firecracker-microVM'er på almindeligt dansk forklarer, hvorfor en egen kerne betyder noget.

Uden det: den første prompt injection, der når ind i genereret kode, får adgang til alt, hvad agentens vært kan nå.

7. Indsigt og en afbryder

Mennesket, der har ansvaret for en agent, skal kunne se, hvad den har gjort, og stoppe den hurtigt. Det betyder forbrug og omkostning pr. ressource, en liste over alt, hvad agenten har oprettet, og en måde at slette det hele på. Loginoplysninger bør kunne tilbagekaldes og være kortlivede nok til, at en lækket token ikke gælder for evigt, med en måde at forny dem på, der ikke kræver et menneske.

Uden det: oprydning bliver til arkæologi. Glemte ressourcer bliver ved med at blive afregnet; en lækket token bliver ved med at virke.

Hvad agenter ikke har brug for

Lige så sigende er det, der ikke hjælper: kontrolpaneler bygget til mersalg, velkomstmails, tariffer hvis reelle grænser står i en fodnote, priser der først vises efter tilmelding. Intet af det kan læses af software, og noget af det vildleder aktivt en model, der tager tekst bogstaveligt.

Hvad der stadig er uløst

Ikke alt her er løste tekniske problemer.

  • Ansvar. Nogen er ansvarlig for, hvad en agent gør med en konto. Platforme har brug for en måde at knytte automatiseret aktivitet til en ansvarlig person på uden at tvinge den person gennem hvert trin.
  • Misbrug. Åben, fuldt automatiseret tilmelding er præcis, hvad misbrugere også vil have. Hver platform, der betjener agenter, balancerer gnidningsfri adgang mod kontofarme og mining, og ingen har et perfekt svar.
  • Lange forløb. Agenter fejler stadig oftere i processer med ti trin end i enkelte kald. Infrastruktur kan hjælpe ved at gøre hvert trin idempotent og dets tilstand let at forespørge, så et genforsøg fortsætter i stedet for at duplikere.

Hvor vi er landet

Vi har forsøgt at bygge til disse krav i stedet for udenom dem: en MCP-server og et REST-API, der dækker hele livscyklussen, maskinlæsbare fejl, en forudbetalt saldo, udgiftsgrænser, kodesandboxe pr. sekund til kort arbejde og månedsservere som tariffen AI agent til langt arbejde. En gennemgang af sandbox-siden findes i sandbox til AI-agenter. Bedøm alligevel listen på dens egne præmisser: den er en nyttig tjekliste til enhver platform, du slipper en agent løs på.

FAQ

Er et API ikke nok til, at en agent kan bruge en hostingtjeneste?

Det er nødvendigt, men ikke tilstrækkeligt. Agenten skal også kunne betale uden et menneskeligt trin, forstå fejl uden at læse en webside, arbejde inden for en hård udgiftsgrænse og køre upålidelig kode et isoleret sted. Hvert af dem er et særskilt krav.

Hvorfor har agenter brug for udgiftsgrænser, hvis de betaler fra en forudbetalt saldo?

En forudbetalt saldo begrænser det værste tilfælde til det, der står på den, og det kan stadig være meget. En dags- eller månedsgrænse gør en agent, der kører i ring, til en dårlig eftermiddag i stedet for en tom saldo og returnerer en fejl, som agenten genkender.

Hvad er den rigtige beregningsenhed for en agent?

Det afhænger af opgaven. At køre et stykke genereret kode tager sekunder og passer til en sandbox pr. sekund. Et job på et par timer passer til det samme eller til en maskin pr. time. En tjeneste, der kører hele tiden, hører hjemme på en månedsserver. Agenter gør alle tre ting, så de har brug for alle tre.

Hvad er stadig uløst?

Mest identitet og ansvar. Nogen er stadig ansvarlig for, hvad en agent gør med en konto, og at forhindre misbrug ved fuldt automatiserede tilmeldinger er et åbent problem. Lange forløb med mange trin fejler også stadig oftere end enkelte kald.

Kommentarer

Ingen kommentarer endnu. Vær den første.

Skriv en kommentar

Kommentarer modereres, før de vises.