🏭 Enterprise AI Infrastructure Brief — 14. September 2026

Kurzfazit — die drei wichtigsten Entwicklungen der Woche:

1. OpenAI macht den vollständigen Agenten-Harness zum Managed Service. Ein ernstzunehmender neuer Architekturbaustein — aber wegen Beta-Status, US-Data-Residency und fehlendem Zero-Data-Retention noch kein universeller Enterprise-Standard.
2. vLLM 0.29 verbessert Steuerbarkeit und Messbarkeit erheblich. Für hybride GDN-/Mamba-Modelle mit MTP bleibt der Produktionspfad in puncto Korrektheit allerdings kritisch.
3. Agenten-Evaluation wird CI/CD-fähig: AWS zeigt einen belastbaren Quality-Gate-Ansatz über OpenTelemetry-Trajektorien, Tool-Accuracy und deterministische Prüfungen.

1. OpenAI Agents API: Managed Harness statt nur Model-Endpoint

OpenAI hat am 10. September die Agents API als Public Beta veröffentlicht. Dabei wird der Codex-Harness als Managed Service betrieben — inklusive:

• langlebiger Sessions und Recovery
• automatischer Context-Compaction
• Tool-Search und programmatischer Toolausführung
• MCP-Anbindung
• paralleler Subagenten
• Streaming, Webhooks und Mid-Turn-Steuerung
• gehosteter oder selbst betriebener Sandboxes

Abgerechnet werden Modelle, Tools und gegebenenfalls Container; für den Harness selbst wird aktuell kein zusätzlicher Aufpreis ausgewiesen.

Entscheidende Einschränkung: Der Session-State wird gespeichert, doch es existiert derzeit nur US-Data-Residency — kein Zero-Data-Retention. Das bleibt selbst dann bestehen, wenn die Sandbox selbst betrieben wird.

Warum das relevant ist: Die Trennung von Harness und Execution Environment wird damit zu einem regulären Plattformmuster: Kontextverwaltung, Toolauswahl und Subagenten-Koordination können eingekauft werden, während Filesystem, Secrets und Compute in einer eigenen Umgebung bleiben.

Architektur-Nachwirkung: Die API ersetzt den inneren Agenten-Harness, aber nicht automatisch eine äußere Workflow-Engine: Idempotenz, fachliche Transaktionen, Side-Effect-Recovery und versionssichere Langzeitprozesse bleiben Domäne dedizierter Workflow-Engines.

Urteil: Hohe PoC-Priorität. Ein vorhandener Research- oder Incident-Workflow sollte gegen den eigenen Harness getestet werden — zu bewerten sind Erfolgsquote und Kosten pro abgeschlossener Aufgabe, Compaction-Verluste über mehrere Kontextfenster, Recovery nach Sandbox- oder Client-Abbruch, Tool- und Subagenten-Telemetrie sowie die Datenklassifizierung vor jeder produktiven Nutzung.

2. vLLM 0.29: bessere Betriebsmechanik, weiterhin kritische Correctness-Fragen

vLLM 0.29 ist am 9. September erschienen. Für Produktionssysteme besonders relevant:

• Model Runner V2 ist nun Standard; MRV1 soll mit v0.32 entfernt werden
• Qwen3.8-Flash-Next wird mit BF16, FP8, NVFP4 und MTP unterstützt
• Spekulative-Akzeptanz-Metriken können pro Request ausgegeben werden
• neue Queue-Grenzen erlauben Admission Control nach Request- und Tokenzahl
• Prefix-Cache-Hashes sind für verteilte KV-Caches deterministisch
• hybride Modelle mit EAGLE/MTP erhalten automatisch dichte Mamba-Cache-Retention
• FlashInfer All-Reduce ist für CUDA-TP-Gruppen standardmäßig aktiv
• der alte Einstieg python -m …api_server ist deprecated; der unterstützte Einstieg ist vllm serve

Nicht gelöst — oder zumindest nicht nachweislich gelöst:

• Der bekannte Ausfall sämtlicher Prefix-Cache-Hits mit Qwen3.8, APC und MTP/DFlash ist weiter offen (#54360).
• Die seltene Ausgabe-Korruption bei Prefix-Cache plus MTP ist ebenfalls weiter offen (#53912).
• Neu gemeldet wurde am 8. September ein zweiter MTP-Correctness-Fehler: Bei gemischtem Chunked-Prefill-/Decode-Traffic können Decode-Zeilen eines hybriden Mamba-Modells durch Prefill-Kernels laufen. Der Bericht nennt 0,2–1 % fehlerhafte Requests unter gemischter Last und bis zu 7 % im Trigger-Test (#55894).

Der letzte Bericht wurde mit v0.27.1 erstellt, nennt den betroffenen Codepfad aber als auf main unverändert. Das ist ein starkes Warnsignal — jedoch kein formaler Nachweis für jede v0.29-Konfiguration.

Warum das relevant ist: HTTP-Erfolg und ein normales finish_reason erkennen diese Fehler nicht. Herkömmliche Availability- und Latenztests reichen daher nicht; erforderlich sind semantische und deterministische Correctness-Gates.

Urteil: v0.29 nur gestuft freigeben. Für hybride Mamba-/GDN-Modelle (z. B. Qwen3.8 mit NVFP4) empfiehlt sich:

• Model Runner V2 gegen den bisherigen Runner vergleichen
• neue Defaults explizit pinnen
• lange und kurze Requests unter gleichzeitiger Chunked-Prefill-Last mischen
• APC-Hits, TTFT und Spec-Acceptance pro Request erfassen
• leere Antworten, Sondertoken-Loops und semantische Abweichungen automatisch erkennen
• APC, MTP und DFlash2 weiterhin einzeln sowie kombiniert testen

3. Agenten-Evaluation wird zum Merge-Gate

AWS hat am 8. September eine vollständige Referenzpipeline veröffentlicht: Sie bereitstellt einen Agenten und einen OAuth-geschützten MCP-Server, führt Testtrajektorien aus und blockt den Pull Request bei einer Regression.

AgentCore Evaluations verarbeitet OpenTelemetry-Spans und unterstützt dabei:

• On-Demand-, Batch- und kontinuierliche Online-Evaluation
• Goal Success und Correctness
• Tool Selection und Tool-Parameter-Accuracy
• exakte oder teilweise Tool-Trajektorien
• eigene LLM-Judges
• deterministische, Lambda-basierte Evaluatoren
• GitHub-OIDC statt langlebiger Cloud-Credentials

Operativer Haken: Im gezeigten M2M-Verfahren besitzen CI-Tokens keine Benutzerrollen und umgehen dadurch absichtlich die Tool-Rollenprüfung. Die Pipeline prüft dann die Agentenqualität, aber nicht die reale Benutzerautorisierung — dafür sind gesonderte Testidentitäten oder Security-Integrationstests notwendig.

Warum das relevant ist: Agententests können damit dieselbe Rolle übernehmen wie Contract- und Integrationstests:

• System-Prompt-Änderungen werden versionierbar
• Modell- und Gatewaywechsel erhalten einen messbaren Freigabepunkt
• Geprüft werden nicht nur Antworten, sondern auch Toolwahl und Aktionsreihenfolge
• Deterministische Security-Assertions können neben LLM-Judges laufen

Urteil: Das Muster sofort übernehmen — auch ohne AWS. OpenTelemetry-basierte Trajektorien plus ein kleines goldenes Eval-Set sind wichtiger als die konkrete Evaluationsplattform.

4. KServe 0.21 RC: Kubernetes-native Inferenz wird operativ vollständiger

Der am 10. September veröffentlichte KServe-0.21-Release-Candidate bringt unter anderem:

• resourceClaims für Kubernetes Dynamic Resource Allocation
• unabhängig installierbare CRDs
• direkte KEDA-Skalierung und echtes Scale-to-Zero
• Canary-Traffic-Splitting und konfigurierbare Rollout-Strategien
• rotierbare TLS-Zertifikate
• Tracing-Konfiguration für InferenceServices
• Signaturprüfung für Kernel-Caches
• lokales Caching von LoRA-Adaptern

Warum das relevant ist: GPU-Zuweisung, Rollouts, Routing, Skalierung und Artefaktintegrität wandern damit stärker in deklarative Kubernetes-Primitiven. Besonders interessant: die Signierung von Kernel-Caches. JIT- beziehungsweise vorkompilierte Kernel sind Teil der AI-Supply-Chain und dürfen nicht als harmlose Performance-Artefakte behandelt werden.

Urteil: Architektur beobachten, den RC nur im Lab. Sinnvollste isolierte Tests: Dynamic Resource Allocation, Scale-to-Zero und signierte Kernel-Artefakte. Eine produktive Migration auf einen Release Candidate wäre verfrüht.

5. Google ADK für Kotlin erreicht 1.0

Seit dem 9. September ist ADK for Kotlin 1.0 allgemein verfügbar. Enthalten sind hierarchische Agenten, Context-Compaction, Human-in-the-Loop, resumierbare Sessions, Vertex-RAG-/Memory-Anbindungen sowie zur Compile-Zeit generierte Tool-Schemas. Skills und ihre Ressourcen werden per Progressive Disclosure erst bei Bedarf geladen.

Warum das relevant ist: Java- und Kotlin-Organisationen müssen für Agenten nicht länger zwingend einen separaten Python-Stack betreiben. Compile-time-Tool-Contracts sind zudem robuster als reflektionsbasierte oder dynamisch erzeugte Schemas.

Urteil: Näher ansehen, wenn JVM- oder Android-Kunden im Scope sind. Als Referenzdesign interessant ist vor allem die Kombination aus typisierten Tools, Skills und persistierbaren Sessions.

MCP und A2A: keine neuen Ereignisse

Seit dem letzten Briefing gab es keinen neuen MCP-Spezifikationsstand und keinen maßgeblichen A2A-SDK-Release. Die Architekturentscheidung aus der Vorwoche bleibt daher unverändert: MCP für Tool- und Datenzugriff, A2A an echten Agenten- und Verantwortungsgrenzen, das Gateway für Policy und Telemetrie.

Marketingfilter

• Salesforce hat am 10. September den „Enterprise AI Harness“ vorgestellt. Das bestätigt die Richtung zu einer gemeinsamen Control-Plane für Context, Agenten und Governance — liefert aber noch zu wenig stabile Schnittstellen und verfügbare Artefakte für eine Architekturentscheidung.
• Die Leistungs- und Kostengewinne in der OpenAI-Ankündigung sind überwiegend Kundenaussagen. Sie eignen sich als Hypothesen für eigene Evals — nicht als übertragbare Benchmarks.

Die nächste Agenda: priorisierte Closer Looks

1. vLLM-0.29-Correctness-Matrix: APC × MTP/DFlash2 × gemischtes Chunked Prefill auf dem Ziel-Hardware-Setup.
2. OpenAI Agents API: A/B-Test von Harness-, Compaction- und Recovery-Verhalten; Data Residency als hartes Gate.
3. Agent-Evaluation in der CI: Toolwahl, Parameter, Trajektorie und deterministische Security-Assertions.
4. KServe DRA und signierter Kernel-Cache: isolierter Lab-Test.
5. Abgrenzung: Managed Agent Sessions innen, dauerhafte fachliche Orchestrierung außen.

Quellen

• OpenAI: Introducing the Agents API
• OpenAI: Agents API — technische Dokumentation
• vLLM: Release Notes
• Google: Announcing ADK for Kotlin 1.0
• AWS: Automated agent evaluation with AgentCore and GitHub Actions
• AWS: Evaluate any agent framework with AgentCore Evaluations
• KServe: Releases
• Salesforce: Enterprise AI Harness

Bildnachweise

• Kopf: „Artificial Neural Network with Chip“ — mikemacmarketing (Flickr), Wikimedia Commons, Lizenz CC BY 2.0
• vLLM: „NVIDIA H100“ — 极客湾Geekerwan, Wikimedia Commons, Lizenz CC BY 3.0
• Evaluation: „Programming code“ — Martin Vorel, Wikimedia Commons, Lizenz CC BY-SA 4.0
• KServe: „Circuit Board“ — Tobias Hanf, Wikimedia Commons, Lizenz CC BY-SA 3.0