Vom Manifest zur Produktion: Wie ADL, A2A und das Inference Gateway die Agenten-Infrastruktur revolutionieren

Vom Manifest zur Produktion: Wie ADL, A2A und das Inference Gateway die Agenten-Infrastruktur revolutionieren

KI-Agenten werden zum neuen Integrations-Layer in der Software-Architektur. Aber während das Ökosystem rasant wächst, bleibt die Entwicklererfahrung fragmentiert. Jedes Framework hat seine eigene Art, Tools zu beschreiben. Jeder Provider hat seine eigene Interpretation von „OpenAI-kompatibel". Jedes Team erfindet dieselben Boilerplate-Komponenten immer wieder neu. Genau dieses Problem löst das Agent Definition Language (ADL) – zusammen mit dem A2A-Protokoll und dem Inference Gateway.

Warum Agenten einen deklarativen Vertrag brauchen

Als wir HTTP-APIs bauten, haben wir schnell gelernt, dass wir einen Vertrag brauchen. Kein Client sollte raten müssen, wie sich ein Service verhält. OpenAPI wurde zum Standard, weil es einen verbindlichen Contract liefert: Endpunkte, Request-Bodies, Response-Schemata, Authentifizierung, Validierungsregeln.

KI-Agenten brauchen dasselbe – aber für eine andere Domäne. Ein guter Agent-Vertrag beantwortet Fragen wie:

• Welches Problem löst dieser Agent? Name, Beschreibung, Version
• Welches Modell oder welchen Provider nutzt er? Modell- und Provider-Angabe mit Fallback
• Welche Tools kann er aufrufen? JSON-Schema für jeden Tool-Input
• Welche Skills kennt er? Wiederverwendbare Instruktions-Sets als Markdown-Playbooks
• Welche Services braucht er? Dependency Injection für Tool-Implementierungen
• Wie wird er deployed? OCI-Image, Kubernetes-Manifeste, CI/CD-Pipeline

Ohne diesen Vertrag wird alles zu „tribal knowledge" – es lebt in READMEs, Prompts, Framework-Code, Umgebungsvariablen oder – schlimmer – in den Köpfen einzelner Entwickler. Das skaliert nicht. Und es funktioniert nicht mit GitOps.

ADL: OpenAPI für Agenten

ADL (Agent Definition Language) ist eine herstellerneutrale, deklarative Spezifikation für KI-Agenten – konzeptionell das, was OpenAPI für REST-Services ist. Entwickelt im Inference-Gateway-Ökosystem und auf dem Blog von Eden Reich ausführlich beschrieben, definiert ADL in einem YAML-Manifest alles, was einen Agenten ausmacht:

apiVersion: adl.inference-gateway.com/v1
kind: Agent
metadata:
  name: browser-agent
  description: Browser automation agent
  version: "0.4.18"
spec:
  capabilities:
    streaming: true
  tools:
    - id: navigate_to_url
      schema:
        type: object
        properties:
          url: { type: string }
        required: [url]
  skills:
    - id: webapp-testing
      bare: true
      name: webapp-testing
      description: End-to-end testing workflow
  agent:
    provider: ""
    model: ""
    systemPrompt: "You are a browser automation assistant..."
  server:
    port: 8080

Das Manifest wird zur Single Source of Truth. Daraus generiert der adl-cli vollständige, produktionsreife Projekte in Go, Rust und TypeScript – mit Server-Setup, typisierten Tool-Handlern, JSON-Schema-Validierung, Service Injection, Dockerfiles und Kubernetes-Manifesten. Und wer Java/Spring Boot bevorzugt, kann mit Spring AI A2A und LangChain4j ebenfalls A2A-kompatible Agenten bauen.

Tools vs. Skills – ein zentraler konzeptioneller Unterschied

ADL trennt sauber zwischen zwei Konzepten, die in anderen Frameworks oft vermischt werden:

Tools sind deterministische Function-Call-Entrypoints mit JSON-Schema. Sie werden aus dem Manifest als echter, typisierter Code in der Zielsprache generiert. Beispiele: Datei lesen, Command ausführen, Datenbank abfragen, E-Mail senden.

Skills sind wiederverwendbare Instruktions-Sets – Markdown-Playbooks, die dem Agenten beibringen, wie ein Workflow abläuft oder eine Policy befolgt wird. Sie werden nur lazy geladen: Metadaten landen initial im Prompt, das vollständige Playbook erst bei Bedarf. Beispiele: Incident Response, Kubernetes-Troubleshooting, Code-Review-Richtlinien.

„Ein Tool gibt dem Agenten eine Aktion. Ein Skill gibt dem Agenten eine Denk- oder Arbeitsweise." – Eden Reich

Reserved Tool IDs wie read, write, edit und bash sind vordefiniert und müssen nicht neu implementiert werden – ihre Konfiguration (Whitelist, Timeout, Limits) bleibt aber explizit im Manifest sichtbar.

A2A: Der externe Kommunikations-Contract

Während das Manifest den internen Aufbau eines Agenten beschreibt, definiert das A2A-Protokoll (Agent-to-Agent) die externe Kommunikation zwischen Agenten. Es ist bewusst minimal gehalten und LLM-agnostisch:

• Zwei Rollen: user (Client) und agent (Server). Kein system, kein assistant, kein tool – diese sind Implementierungsdetails der LLM-Runtime.
• Task-basiert: Ein Client-Agent sendet einen Task, der Server-Agent führt ihn aus und liefert Status-Updates (submitted → running → succeeded) und Ergebnisse.
• Agent Cards: Jeder Agent macht sich unter /.well-known/agent-card.json selbst beschreibend – Discovery ohne zentrales Register.
• Streaming: Tasks können synchron oder asynchron mit Streaming verarbeitet werden.

Das Revolutionäre: Weil A2A keine LLM-spezifischen Rollen kennt, kann ein A2A-„Agent" auch ein rein deterministischer Worker ohne LLM sein – ein Datenbank-Query-Service, ein Rechen-Backend oder ein Workflow-Engine. Die Gegenseite merkt keinen Unterschied. Das spart Tokens und Kosten, wo keine Reasoning-Fähigkeit benötigt wird.

Translation Layer: A2A trifft OpenAI

ADL-Agenten, die ein LLM nutzen wollen, sprechen nach außen A2A, intern aber das OpenAI-kompatible Chat-Format. Der generierte Code übersetzt automatisch zwischen beiden Welten:

• Tool-Calls und Tool-Ergebnisse werden in strukturierte Teile von agent-Nachrichten gefaltet.
• Vor dem Senden an den LLM-Provider werden sie zurück in system-, assistant- und tool-Messages expandiert.
• Der Provider ist über das Inference Gateway austauschbar (OpenAI, Anthropic, DeepSeek, Ollama, Groq, Mistral – 11+ Provider).

Der Entwickler schreibt diesen Translation-Layer nicht selbst – der Generator erzeugt ihn.

Inference Gateway & ADK: Das Runtime-Ökosystem

Das Inference Gateway ist ein schlanker (~10,8 MB) Drop-in-Proxy für /v1/chat/completions, der aus dem Model-Namen den Ziel-Provider ableitet. Es ist horizontal skalierbar für Kubernetes mit HPA, unterstützt OpenTelemetry, Prometheus und MCP-Integration.

Das ADK (Agent Development Kit) ist die Go-Bibliothek (auch Rust/TypeScript), die A2A-kompatible Agenten baut – mit Fluent Builder, Task-Delegation, Real-time-Streaming, OIDC/OAuth2-Auth und Artifact-Backends. Es ist die Runtime, die ADL-generierter Code nutzt.

Java, Spring Boot & A2A: Enterprise trifft Agenten

Das Java-Ökosystem ist 2026 produktionsreif für A2A – und das ist besonders relevant, wenn deterministische, typsichere Enterprise-Komponenten integriert werden müssen:

• Spring AI A2A (spring-ai-community) exponiert Spring-AI-Agenten als vollständige A2A-Server per Autoconfiguration. Ein @Bean AgentExecutor mit ChatClient und Tool-Registrierung genügt.
• LangChain4j bietet ein Submodul langchain4j-agentic mit MCP- und A2A-Unterstützung.
• a2a4j ist eine dedizierte Java-A2A-Implementierung mit Server, Client und Spring-Boot-Starter.
• Spring Dependency Injection ist das exakte Pendant zu ADLs inject-Mechanismus: Services werden in Tool-Handler injiziert statt auf globalen State zuzugreifen – das ermöglicht sauberes Testing und Wartbarkeit.

„Spring DI ≈ ADLs inject-Mechanismus: Services werden in Tool-Handler injiziert statt globalem State – dasselbe Prinzip, hier durch den Container erzwungen."

Für Unternehmen, die bereits auf JVM setzen, ist das der native Weg, LLM-gestützte und deterministische Agent-Komponenten unter einem einheitlichen A2A-Protokoll zu vereinen.

OCI Images, Kubernetes & GitOps: Deployment aus einer Hand

ADL-Manifest → Code-Generierung → OCI-Image → Kubernetes-Deployment: Die Pipeline ist vollständig automatisiert.

• OCI-Images: Der adl-cli generiert Multi-Arch-Dockerfiles (amd64 + arm64) mit Multi-Stage-Builds. Compilierte Sprachen (Go, Rust) erzeugen schlanke Static-Binaries für Scratch-Basis-Images. SBOMs, Signing und Provenance sind integrierbar.
• Kubernetes-Manifeste: adl generate --deployment kubernetes erzeugt vollständige Deployment-YAMLs mit Resource-Limits und Health-Checks, inklusive Agent Card unter /.well-known/.
• GitOps: Das ADL-Manifest ist per Design Single Source of Truth. Änderungen laufen als normaler Pull Request mit Review, die Generierung im CI, das Deployment via ArgoCD oder Flux. Rollback und Versionierung sind inklusive.

A2A vs. MCP: Komplementär, nicht konkurrierend

Viele Entwickler fragen sich, wie A2A und MCP (Model Context Protocol) zusammenhängen. Die Antwort: Sie lösen unterschiedliche Probleme.

	A2A	MCP
Löst	Agent ↔ Agent: Discovery, Delegation, Orchestrierung	Agent ↔ Tool/Kontext: Grounding, Integration
Merksatz	„Verbindet Agenten miteinander"	„Verbindet Agenten mit ihrer Umgebung"
Typischer Fluss	Planner-Agent delegiert per A2A an Spezialisten	Agent ruft per MCP Tools/Daten/APIs

Beide zusammen ergeben ein vollständiges Agent-System: A2A für die horizontale Kommunikation zwischen Peers, MCP für den vertikalen Zugriff auf Tools und Datenquellen.

Vendor-Neutralität als Architekturprinzip

Eines der größten Risiken im aktuellen KI-Ökosystem ist Vendor-Lock-in – nicht nur auf Modellebene, sondern auf Framework-Ebene, Tool-Definitionsebene, Runtime-Ebene und Deployment-Ebene.

ADL adressiert das konsequent:

• Der Provider ist austauschbar (11+ über das Inference Gateway)
• Das Framework ist austauschbar (Go, Rust, TypeScript, Java/Spring)
• Die Zielplattform ist austauschbar (Kubernetes, Cloud Run, Bare Metal)
• Der Code ist verständlich – die Generierung macht das Gerüst, der Entwickler schreibt die Business-Logik

Das Manifest bleibt der Vertrag. Alles andere ist Implementierungsdetail.

Fazit: Agenten als Infrastruktur

Wir sind noch früh in der Entwicklung. Es wird Breaking Changes geben, bessere Ideen, Neukonzeptionen. Aber die Richtung stimmt: Weg von fragmentierten Demo-Projekten, hin zu einer offenen, deklarativen und produktionsfreundlichen Art, Agenten zu bauen.

ADL gibt Agenten den Vertrag, den sie brauchen. A2A gibt ihnen die Sprache, miteinander zu kommunizieren. Das Inference Gateway sorgt für Provider-Neutralität. Und Kubernetes + GitOps geben ihnen die Infrastruktur, die sie verdienen.

Define first. Generate second. Implement what matters. Deploy like real software.

---

Quellen und weiterführende Links:

• ADL Repository (GitHub)
• ADL CLI (GitHub)
• Inference Gateway (GitHub)
• ADK – Agent Development Kit (GitHub)
• Eden Reich: Agent Definition Language – OpenAPI for AI Agents
• Spring AI A2A Integration
• Spring AI A2A (GitHub)