Was KI-Agenten wirklich von Infrastruktur brauchen: 7 Anforderungen und wo menschenzentriertes Hosting im Weg steht

Das meiste Hosting wurde für einen Menschen an der Tastatur entworfen: ein Registrierungsformular, eine Karte, ein Dashboard, eine E-Mail, wenn etwas schiefgeht. Ein KI-Agent, der Rechenleistung braucht, passt in keinen dieser Schritte. Er löst kein Captcha, unterscheidet eine Wartungsseite nicht von einer kaputten und bemerkt nicht, dass er denselben Server vierzigmal angelegt hat.

Es liegt nahe zu sagen: „Gib ihm einfach eine API.“ Das ist die erste Anforderung, nicht die letzte. Hier sind sieben, die uns wichtig erscheinen, aus dem Bau unseres eigenen MCP-Servers und unserer REST-API für Agenten. Für jede: was ohne sie schiefgeht.

1. Alles, was ein Agent braucht, ist programmierbar

Ressourcen anlegen, einsehen, skalieren und löschen muss ohne Browser funktionieren. Einschließlich der langweiligen Teile: den Preis vor dem Kauf herausfinden, prüfen, ob ein Standort Kapazität hat, das Passwort einer neuen Maschine auslesen, kündigen.

Ohne das: Der Agent schafft 80 % des Weges und bleibt an dem einen Schritt hängen, der einen Klick braucht, und ein Mensch muss die Arbeit doch zu Ende bringen. Eine halbe API ist oft schlimmer als keine, weil sie zu Automatisierung einlädt, die nicht fertig werden kann.

2. Fehler, auf die ein Programm reagieren kann

Ein Agent liest eine Antwort und entscheidet, was als Nächstes zu tun ist. Ein JSON-Body mit stabilem Code (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded mit dem Zeitpunkt des Zurücksetzens) ist etwas, worauf er verzweigen kann. Eine HTML-Fehlerseite oder ein 500 mit vager Meldung lässt ihn raten — oft wiederholt er etwas, das nie gelingen wird.

Ohne das: Wiederholungsschleifen. Die teuersten Agentenfehler sind meist keine falschen Entscheidungen, sondern derselbe fehlschlagende Aufruf, tausendfach wiederholt.

3. Bezahlen ohne Menschen in der Schleife

Kartenzahlungen sind voller Schritte, die die Anwesenheit eines Menschen bestätigen sollen: 3-D-Secure-Codes, Bestätigungen in der Banking-App, Identitätsprüfungen. Sie sind gut gegen Betrug und unmöglich für Software. Ein Prepaid-Guthaben, vorab aufgeladen (bei uns oft mit Stablecoins), lässt einen Agenten für Genutztes bezahlen, ohne dass ein Mensch jede Abbuchung freigibt.

Ohne das: Entweder gibt ein Mensch jeden Kauf frei, was den Zweck verfehlt, oder jemand gibt einem Agenten eine Karte, und dieses Risiko sollte niemand eingehen.

4. Harte Ausgabenlimits

Ein Prepaid-Guthaben begrenzt den schlimmsten Fall auf das, was darauf liegt. Das kann immer noch viel sein. Ein Tages- und Monatslimit in Dollar, durchgesetzt von der Plattform statt von den guten Absichten des Agenten, macht aus einem Agenten in einer Schleife einen kleinen Verlust. Das Limit sollte laut scheitern, mit einem Fehler, den der Agent erkennt, und anhalten oder pausieren, was läuft.

Ohne das: Sie erfahren von der Schleife über das Guthaben. Unsere Sandbox-Abrechnung hat aus diesem Grund Limits, und die Seite MCP-Schutzmaßnahmen schlägt vor, welche Aktionen überhaupt die Freigabe eines Menschen brauchen sollten.

5. Rechenleistung in der richtigen Körnung

Agenten erzeugen drei sehr verschiedene Arten von Arbeit:

• Sekunden: ein generiertes Snippet ausführen, eine Antwort prüfen, einen Fix ausprobieren.
• Stunden: eine Evaluierung, ein Scraping, ein langer Build.
• Dauerbetrieb: ein Bot, eine API, ein zeitgesteuerter Worker.

Eine Plattform, die nur Monatsserver anbietet, macht die erste Art absurd teuer; eine, die nur kurzlebige Sandboxes anbietet, macht die dritte fragil. Eine 20-Sekunden-Aufgabe auf einer stundenweise abgerechneten Maschine bezahlt 59 Minuten Nichts. Wie sekundengenaue Abrechnung funktioniert zeigt, wo jedes Modell keinen Sinn mehr ergibt.

Ohne das: Agenten zahlen entweder zu viel für kurze Arbeit oder betreiben langlebige Dienste auf Infrastruktur, die nicht zum Durchlaufen gedacht war.

6. Isolation als Standard

Von einem Agenten geschriebener Code ist Code, den niemand geprüft hat. Er sollte dort laufen, wo nichts von Wert liegt: nicht auf dem Host des Agenten, nicht auf einem Server mit Ihren Schlüsseln, nicht auf der Maschine, die Ihre Mails versendet. Praktisch heißt das: eine eigene VM oder microVM pro Aufgabe, danach gelöscht. Isolationsstufen für nicht vertrauenswürdigen Code vergleicht die Optionen; Firecracker-microVMs einfach erklärt zeigt, warum ein eigener Kernel zählt.

Ohne das: Die erste Prompt Injection, die es in generierten Code schafft, hat Zugriff auf alles, was der Host des Agenten erreichen kann.

7. Sichtbarkeit und ein Ausschalter

Der Mensch, der für einen Agenten verantwortlich ist, muss sehen können, was er getan hat, und ihn schnell stoppen. Das heißt: Nutzung und Kosten pro Ressource, eine Liste von allem, was der Agent angelegt hat, und eine Möglichkeit, alles davon zu löschen. Zugangsdaten sollten widerrufbar und kurzlebig genug sein, dass ein geleaktes Token nicht ewig gilt, mit einer Erneuerung, die keinen Menschen braucht.

Ohne das: Aufräumen wird zur Archäologie. Vergessene Ressourcen laufen weiter auf die Rechnung; ein geleaktes Token funktioniert weiter.

Was Agenten nicht brauchen

Ebenso aufschlussreich ist, was nicht hilft: Dashboards fürs Upselling, Onboarding-Mails, Tarife, deren echte Grenzen in einer Fußnote stehen, Preise, die erst nach der Registrierung erscheinen. Nichts davon ist für Software lesbar, und manches führt ein Modell, das Text wörtlich nimmt, aktiv in die Irre.

Was noch ungelöst ist

Nicht alles hier ist ein gelöstes Ingenieursproblem.

• Verantwortlichkeit. Jemand ist verantwortlich für das, was ein Agent mit einem Konto tut. Plattformen brauchen eine Möglichkeit, automatisierte Aktivität einer verantwortlichen Person zuzuordnen, ohne diese Person durch jeden Schritt zu schicken.
• Missbrauch. Offene, vollautomatische Registrierung ist genau das, was auch Missbraucher wollen. Jede Plattform für Agenten balanciert reibungslosen Zugang gegen Farming und Mining aus, und keine hat eine perfekte Antwort.
• Lange Abläufe. Agenten scheitern an zehnstufigen Prozessen noch häufiger als an einzelnen Aufrufen. Infrastruktur kann helfen, indem jeder Schritt idempotent und sein Zustand leicht abfragbar ist, sodass eine Wiederholung fortsetzt statt verdoppelt.

Wo wir gelandet sind

Wir haben versucht, für diese Anforderungen zu bauen statt um sie herum: ein MCP-Server und eine REST-API für den ganzen Lebenszyklus, maschinenlesbare Fehler, ein Prepaid-Guthaben, Ausgabenlimits, sekundengenau abgerechnete Code-Sandboxes für kurze Arbeit und Monatsserver wie der Tarif AI agent für lange. Ein Durchgang durch die Sandbox-Seite steht in Sandbox für KI-Agenten. Beurteilen Sie die Liste aber gern für sich; sie ist eine nützliche Checkliste für jede Plattform, auf die Sie einen Agenten loslassen.