Die meisten Agenten-Demos sehen großartig aus, bis sie den Laptop der Entwickler verlassen. Die UX bricht ein, die Kosten steigen sprunghaft, und niemand kann erklären, warum ein Agent am Freitag um 17 Uhr einen fehlerhaften Change gepusht hat. Mit Cloudflares neuer KI-Plattform für Agenten in den Schlagzeilen und Desktop-Kontrolle auf dem Niveau aktueller, Codex-ähnlicher Features, die wieder auftauchen, bekommen Sie zu Recht die Frage: Wie sieht unsere Produktionsarchitektur für Agenten aus?
Hier ist die Antwort, die wir ausliefern: Behandeln Sie Agenten als verteilte, ereignisgesteuerte Systeme am Edge—nicht als monolithische Chatbots. Im Folgenden eine pragmatische Referenzarchitektur, die Sie Ihrer Mannschaft heute vorlegen können. Sie ist anbieterneutral, fokussiert auf messbare Latenz, durchsetzbare Richtlinien und vorhersagbare Kosten. Sie skaliert zudem von einem einzelnen Produktteam bis hin zur unternehmensweiten Automatisierung—ohne einen Plattform-Neuaufbau.
Von Laptop-Bots zu edge-nativen Agenten
Zwei Dinge haben sich 2026 geändert:
- Edge-Runtimes wurden agentenbewusst. Cloudflare hat eine Inferenzschicht speziell für Agenten angekündigt (denken Sie an Workers + Queues + Durable Objects + Vectorize + KI-Inferenz), wodurch sich Zustand und Tools realistisch in der Nähe der Nutzer halten lassen. Vercel, Fly.io und die Hyperscaler folgten mit ihren Varianten.
- Desktop-Agenten sind zurück. Die aufgerüsteten, Codex-ähnlichen Features von OpenAI können Ihren Computer im Hintergrund steuern. Das ist mächtig—und gefährlich—ohne Richtlinien, Audit und sauberen Scope. Sie brauchen serverseitige Guardrails, selbst wenn Ihr UI auf einem Laptop läuft.
Ihre Aufgabe als CTO ist nicht, das schillerndste Demo zu wählen—sondern ein System zu entwerfen, in dem die Entscheidungen eines Agenten beobachtbar, rücknehmbar und kostengünstig genug für den Betrieb im großen Maßstab sind.
Produktionsanforderungen (die Messlatte, die Sie setzen sollten)
- Latenz: Unter 1 s wahrgenommene Latenz für gängige Turns in Nordamerika; Edge-Compute sollte <100 ms pro Funktion bleiben, Retrieval <150 ms in-region, Reasoning mit kleinem Modell 300–800 ms, mit großem Modell 1,5–4 s. Lassen Sie Nutzer nur warten, wenn es zählt.
- Safety: Explizite Richtlinie, welche Tools der Agent aufrufen darf, mit Ressourcenscope und menschlicher Freigabe bei risikoreichen Aktionen.
- Observability: OpenTelemetry-Traces und strukturierte Events für jede Aktion—mit Replay. Wenn Sie einen Vorfall nicht reproduzieren können, haben Sie keine Plattform gebaut, sondern ein Demo.
- Kostenkontrolle: Harte Token-Budgets pro Turn/Sitzung, Admission Control für lange Prompts und Backpressure bei burstigen Workloads. Gehen Sie von knapper KI-Rechenkapazität aus; entwerfen Sie dafür.
- Portabilität: Modelle und Tool-Hosts austauschbar machen, ohne die Agentenlogik umzuschreiben. Vermeiden Sie Glue-Code, der die Eigenheiten eines einzelnen LLM-Anbieters einbrennt.
Eine edge-native Referenzarchitektur
Übertragen Sie diese Konzepte auf Ihren bevorzugten Stack. Ich nutze Cloudflare-Begriffe (in Klammern) und nenne gleichwertige Komponenten auf AWS/GCP, um es greifbar zu machen.
1) Front Door und Identity
- Edge-API: Ein schlankes Gateway am Edge (Workers, API Gateway + CloudFront oder Fastly Compute@Edge) terminiert TLS, authentifiziert Anfragen (OIDC/JWT) und normalisiert Payloads.
- Session-Metadaten: Hängen Sie User-/Org-IDs, Risikostufe und ein Token-Budget pro Session an. Speichern Sie kurzlebigen Sitzungszustand in einem Edge-Key-Value- oder Session-Objekt (Durable Objects; AWS: DynamoDB + Lambda@Edge).
2) Orchestrator und Scratchpad
- Event-Bus: Jeder Nutzerschritt emittiert ein Event in eine Queue (Cloudflare Queues; AWS SQS; GCP Pub/Sub). Das entkoppelt die UI-Latenz von nachgelagerten Arbeiten.
- Orchestrator: Ein zustandsloser Worker konsumiert Events, führt die Steuerschleife aus (Function Calling, Planning) und persistiert einen Action Graph—einen DAG aus Toolaufrufen mit Ein-/Ausgaben—in ein Session-Objekt (Durable Objects; oder Redis/DynamoDB + Step Functions).
- Scratchpad: Speichern Sie chain-of-thought-ähnliche Daten und Pläne als privaten Agentenzustand, der Nutzern nicht exponiert wird, und redigieren Sie ihn aus Logs. Das Modell erhält den Plan; die Logs erhalten Ergebnis und eine Zusammenfassung der Begründung.
3) Reasoning-Engine (Modellabstraktion)
- Model Router: Eine dünne Abstraktion, die je nach Policy auf Closed Models (OpenAI/Anthropic), Edge-gehostete Inferenz (Cloudflare AI) oder Open-Weights (z. B. Qwen 35B/A3B, Llama 3.x) auf Serverless-GPUs (Fireworks, Modal) zielt—abhängig von Datensensitivität, Kosten-, Geschwindigkeits- und Genauigkeitsanforderungen.
- Nur-JSON-Schnittstellen: Nutzen Sie strukturierte Outputs (JSON Schema) für Toolauswahl, Argumente und Zusammenfassungen. Weisen Sie fehlerhafte Antworten am Router ab und reprompten Sie mit kleinerem Budget, statt Müll downstream durchzulassen.
4) Toolausführung und Sandboxing
- WASM-Sandbox: Führen Sie schnelle, untrusted Tools in WASI/WASM mit Zeit- und Speicherkappen aus. Für längere Aktionen dispatchen Sie zu Serverless Functions oder kurzlebigen Jobs (Workers/Pages Functions; AWS Lambda/Fargate Jobs; GCP Cloud Run Jobs).
- Credential Policy: Geben Sie pro Toolaufruf ephemere, gescopte Credentials via OIDC und einen Secret Manager aus (Vault, AWS STS + Secrets Manager). Keine langlebigen Tokens in Prompts einbetten.
- Desktop-Aktionen: Wenn Sie einem Agenten erlauben, einen Computer zu „benutzen“, leiten Sie über einen Broker, der eine eingeschränkte Tooloberfläche bereitstellt (z. B. URL in einem sandboxed Browser öffnen, Text des ausgewählten Fensters lesen, Klick innerhalb einer Bounding Box simulieren) und jede Aktion mit Screenshots für Audits protokolliert. Geben Sie niemals das volle OS frei.
5) Speicherebenen
- Kurzfristig: Sitzungsbezogener Zustand (Durable Objects; DynamoDB/Redis). TTL Minuten bis Stunden.
- Langfristig: RAG-Korpora in einem Vektor-Store nahe am Agenten (Cloudflare Vectorize; pgvector auf Neon; Pinecone; Weaviate). Halten Sie Embeddings dort, wo die Inferenz läuft, um Egress-Latenz und -Kosten zu vermeiden.
- Transaktional: Eine relationale Datenbank (Postgres/PlanetScale) für Berechtigungen, Freigaben und dauerhafte Audits.
6) Richtlinien und Freigaben
- Policy-Engine: Bewerten Sie jeden geplanten Toolaufruf gegen die Policy (OPA/Rego oder Amazon Cedar). Inputs: Nutzerrolle, Umgebung (prod/stage), Datensensitivität, Tool-Risikostufe, verbleibendes Token-Budget.
- Human-in-the-Loop: Bei risikoreichen Aktionen (Merge nach main, Berührung von PII, Ausgaben >$X) blockieren und eine Benachrichtigung an Slack/E-Mail mit One-Click-Freigabe senden. Zeichnen Sie Freigeber und Begründung auf.
7) Beobachtbarkeit und Replay
- Traces: Emittieren Sie OpenTelemetry-Spans für jeden Schritt: Prompt-Build, Modellaufruf, Retrieval, Toolaufruf, Policy-Check. Korrelation mit Session und Nutzer.
- Event-Log: Persistieren Sie einen kompakten, redigierten Event-Stream (Queue → Object Storage). Speichern Sie Inputs/Outputs, Modellversion, Kosten und Latenz. Das ist Ihre Quelle der Wahrheit für Replays.
- Redaktion: PII-Scrubbing, bevor irgendetwas die Edge-Runtime verlässt. Bewahren Sie einen nicht redigierten, zugriffsgeschützten Vault nur auf, wenn rechtlich erforderlich.
8) Kostensteuerung
- Budgets: Harte Kappen pro Turn und pro Session. Beispiel: 8K Input- + 2K Output-Tokens pro Turn, 40K Session-Cap, mit Backoff-Strategie ab 80% Auslastung.
- Admission Control: Prompts >N KB ablehnen, Chunking vorschlagen oder mit expliziter Nutzerzustimmung auf ein günstigeres/kleineres Modell wechseln.
- Backpressure: Wenn Queues sich aufstauen, elegant degradieren: kleinere Modelle, weniger Tools oder Retrievals bündeln.
Konkretes Beispiel: ein PR-Prep-Agent für Ihr Monorepo
Ziel: Der Agent entwirft einen Pull Request, der ein Jira-Ticket schließt—inklusive Gerüst für Codeänderungen, Tests und Migrationsplan—ohne jemals ohne Freigabe auf main zu pushen.
- Der Nutzer postet einen Ticket-Link. Die Edge-API authentifiziert, weist ein Token-Budget von 40K für die Session zu und schreibt ein Session-Objekt.
- Der Orchestrator holt das Ticket, führt RAG über relevante Codepfade mittels eines Vektorindex (nächste Edge-Region) aus. Ziel-Latenz: 80–150 ms für Retrieval.
- Die Reasoning-Engine (offenes 14B oder geschlossenes Premium-Modell) plant: Dateien A/B lesen, Patch generieren, Tests ausführen, DB-Migration vorschlagen, Freigabe zum Öffnen eines PR anfordern.
- Die Toolschicht führt der Reihe nach aus: Dateien lesen (WASM), Patch entwerfen (Modell), Tests ausführen (Serverless-Job) und einen PR vorbereiten. Jeder Toolaufruf trägt ein gescoptes Token mit 5 Minuten Gültigkeit.
- Die Policy-Engine blockiert git push und sendet eine Approval-Karte an Slack mit Diff-Zusammenfassung sowie bisherigen Kosten/Latenzen. Der Freigeber klickt „Allow“ oder „Revise“.
- Nach Freigabe öffnet der Agent den PR und postet einen Trace-Link. Alle Aktionen werden in einem replayfähigen Event-Log erfasst.
Latenzbudget (Median):
- Edge-Request + Auth: 30–60 ms
- RAG: 80–150 ms
- Planungs-LLM (kleines Modell): 300–600 ms
- Patch-Generierung (Modell): 700–2.000 ms, abhängig von Größe/Modell
- Tests (Serverless-Job): parallelisiert; der Nutzer sieht Streaming-Updates
- Gesamtzeit bis zum nutzbaren Output: <1 s für Planvorschau; 2–5 s für den ersten Patch-Entwurf
Kostenskizze (mit Ihren Anbieterpreisen aktualisieren):
- Definieren Sie die Kosten pro 1.000.000 Tokens für jede Modellstufe. Pro Turn berechnen: (Input + Output Tokens) / 1.000.000 × Preis.
- Turns mit kleinen Open-Weight-Modellen können um eine Größenordnung günstiger sein als mit Frontier-Modellen. Nutzen Sie sie für Planung und Toolauswahl; reservieren Sie Frontier-Modelle für Codesynthese oder schwieriges Reasoning.
- Egress zählt weiterhin. Public-Cloud-Egress liegt oft bei etwa $0,05–$0,09/GB. Wenn Ihr Agent große Artefakte (Logs, Binaries) verschiebt, kollokieren Sie Compute und Daten oder verlagern Sie Artefakte in Edge Storage.
Build vs. Buy: Was an die Plattform auslagern
Sie müssen nicht alles selbst bauen. Hier ist ein pragmatischer Split.
- Kaufen/Nutzen: Edge-Runtime, Queues, Object Storage; Model Hosting für mindestens zwei Tiers (schnell/günstig und genau/teuer); Vektor-DB mit regionaler Platzierung; OTel-kompatibles Logging; Secret Management.
- Bauen: Orchestrator (Ihre Steuerschleife), Policy-Integration (Ihr Risiko), Toolkatalog und Sandbox-Policy, Redaktion, Replay-UI und Kostenkontrollen. Diese kodifizieren Ihre Geschäftsregeln und sind Ihr Moat.
Cloudflares integrierter Agent-Stack reduziert Glue-Work; AWS/GCP geben Ihnen granulare Kontrolle bei höherem Montageaufwand. In jedem Fall sollten Model Router und Policy-Schicht Ihnen gehören, um Vendor Lock-in zu vermeiden.
Teamzuschnitt und Timeline (nearshore-freundlich)
- Kernteam: 1 Platform Engineer (Edge/Runtime/Queues), 1 AI Engineer (Prompting, Router, Evals), 1 Application Engineer (Tools, Domainlogik), 0,5 SRE/Observability. Fügen Sie für Desktop-Agenten einen Security Engineer hinzu.
- Zeitplan: Ein gesteuerter Pilot in 4 Wochen ist mit einem fokussierten Scope realistisch:
- Woche 1: Front Door, Identity, Tracing und ein gestubbter Orchestrator. Zwei Modelle wählen und einen Router verdrahten.
- Woche 2: Drei Tools in WASM (read-only) implementieren, Vector Search hinzufügen und die Policy-Engine im „Report-only“-Modus.
- Woche 3: Blocking-Policy für eine riskante Aktion aktivieren, Slack-Approval und Redaktion hinzufügen. Mit Kostendashboards starten.
- Woche 4: Den PR-Prep-Agent an ein Squad ausliefern. SLOs definieren: p95 Agentenantwort <2,5 s, Kosten pro Turn <$X, null Policy-Umgehungen.
Brazilian Nearshore-Teams können Build-Stunden mit 6–8 Stunden Überlappung zu US-Zeitzonen abdecken und die Integrationsarbeit vorantreiben, während sich Ihr Kernteam auf Policy und Modellauswahl fokussiert.
Risikomanagement und Trade-offs
- Genauigkeit vs. Kosten: Nutzen Sie kleine Modelle für Planung und Tool-Routing; eskalieren Sie selektiv. So reduzieren Sie die Ausgaben um 30–70%, ohne die Ergebnisse zu verschlechtern.
- Latenz vs. Portabilität: Edge-gehostete Inferenz beschleunigt die UX, kann aber die Modellauswahl einschränken. Halten Sie einen Backdoor-Pfad zu einem zweiten Provider für Failover und Regressionschecks.
- Safety vs. Autonomie: Mehr Freigaben reduzieren Vorfälle, schmälern aber den Durchsatz. Starten Sie strikt und lockern Sie mit Vertrauensmetriken und nachgelagerten Audits.
- Desktop-Agenten-Scope: Es ist verlockend, Agenten „einfach machen zu lassen“. Tun Sie es nicht. Vermitteln Sie jede Desktop-Aktion über eine schmale Tooloberfläche und zeichnen Sie alles auf.
So entscheiden Sie, wo jede Komponente läuft
Schieben Sie nicht blind alles an den Edge. Nutzen Sie diese einfache Daumenregel:
- Edge: Authentifizierung, Request-Shaping, leichtgewichtiges Planning, Retrieval, wenn der Korpus bereits gecacht oder repliziert ist. Faustregel: Arbeit <100 ms und <256 KB I/O.
- Regional: Schwergewichtiges RAG gegen transaktionale Daten, lange Kontextfenster und alles, was bei Ausführung am Edge Cross-Region-Egress verursachen würde.
- Background: Tools, die >2 s laufen oder Isolation benötigen (Tests, Compiles, Indexing). Immer ins Event-Log checkpointen; Partials ins UI streamen.
Evaluation: Funktionsnachweis, bevor Sie skalieren
- Golden Tasks: 20–50 echte Aufgaben, repräsentativ für Produktion. Verfolgen Sie Erfolgsrate, durchschnittliche Turns, Kosten pro Erfolg und Time-to-First-Useful-Output.
- Guardrail-Tests: Riskante Prompts simulieren und sicherstellen, dass die Policy-Engine blockiert. Prompt-Injection-Szenarien und Versuche der Datenexfiltration einschließen.
- Load: Soak-Tests mit realistischer Concurrency. Queue-Tiefe und Backpressure-Verhalten beobachten; Verifizierung, dass Degradierungs-Policies greifen.
Was als Nächstes kommt: Auf Knappheit vorbereiten
Die Nachfrage nach Agenten übersteigt das Angebot. Rechnen Sie mit periodischer Rechenknappheit und Modell-Drosselungen. Entwerfen Sie jetzt für Multi-Model-Routing, budgetbewusste Fallbacks und grobe SLAs („schnell-und-gut-genug“ vs. „langsam-aber-genau“). Wenn es eng wird, liefern die Teams mit Kostenschaltern und Observability weiter aus—während andere Rollouts pausieren.
Kernpunkte
- Hören Sie auf, Agenten wie Chatbots zu behandeln; betrachten Sie sie als Edge-first, ereignisgesteuerte Systeme.
- Bauen Sie Orchestrator, Policy-Schicht, Model Router und Replay selbst; kaufen Sie die Basis-Infrastruktur.
- Erreichen Sie Subsekunden-UX, indem Sie Planning und Retrieval am Edge halten; lange Arbeiten in Jobs auslagern.
- Nutzen Sie kleine Modelle für Planung und eskalieren Sie selektiv, um die Ausgaben zu steuern.
- Setzen Sie gescopte, ephemere Credentials und menschliche Freigaben für risikoreiche Aktionen durch.
- Instrumentieren Sie alles mit OpenTelemetry und führen Sie ein redigiertes, replayfähiges Event-Log.
- Entwerfen Sie von Tag eins an Multi-Model und Multi-Provider, um KI-Knappheit zu überstehen.