From Manifest to Production: How ADL, A2A and the Inference Gateway Are Revolutionizing Agent Infrastructure

From Manifest to Production: How ADL, A2A and the Inference Gateway Are Revolutionizing Agent Infrastructure

AI agents are becoming the new integration layer in software architecture. But while the ecosystem is growing rapidly, the developer experience remains fragmented. Every framework has its own way to describe tools. Every provider has its own interpretation of what "OpenAI compatible" means. Every team reinvents the same boilerplate components over and over. This is exactly the problem Agent Definition Language (ADL) solves – together with the A2A protocol and the Inference Gateway.

Why Agents Need a Declarative Contract

When we built HTTP APIs, we quickly learned that a contract was essential. No client should have to guess how a service behaves. OpenAPI became the standard because it provides a binding contract: endpoints, request bodies, response schemas, authentication, validation rules.

AI agents need the same – but for a different domain. A good agent contract answers questions like:

• What problem does this agent solve? Name, description, version
• Which model or provider does it use? Model and provider specification with fallback
• What tools can it call? JSON schema for every tool input
• Which skills does it know? Reusable markdown instruction sets as playbooks
• Which services does it need? Dependency injection for tool implementations
• How is it deployed? OCI image, Kubernetes manifests, CI/CD pipeline

Without this contract, everything becomes "tribal knowledge" – living in READMEs, prompts, framework-specific code, environment variables, or – worse – in individual developers' heads. That doesn't scale. And it doesn't work with GitOps.

ADL: OpenAPI for Agents

ADL (Agent Definition Language) is a vendor-neutral, declarative specification for AI agents – conceptually what OpenAPI is for REST services. Developed within the Inference Gateway ecosystem and extensively described in Eden Reich's engineering blog, ADL defines everything about an agent in a single YAML manifest:

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

The manifest becomes the single source of truth. From it, the adl-cli generates complete, production-ready projects in Go, Rust, and TypeScript – with server setup, typed tool handlers, JSON schema validation, service injection, Dockerfiles, and Kubernetes manifests. And for teams that prefer Java/Spring Boot, Spring AI A2A and LangChain4j provide equally capable A2A-compatible agent frameworks.

Tools vs. Skills – A Fundamental Distinction

ADL cleanly separates two concepts that are often conflated in other frameworks:

Tools are deterministic function-call entrypoints with JSON schemas. They are generated from the manifest as real, typed code in the target language. Examples: read a file, execute a command, query a database, send an email.

Skills are reusable instruction sets – markdown playbooks that teach the agent how to perform a workflow or follow a policy. They are loaded lazily: metadata goes into the initial prompt, the full playbook is loaded on demand. Examples: incident response, Kubernetes troubleshooting, code review guidelines.

"A tool gives the agent an action. A skill gives the agent a way of thinking or working." – Eden Reich

Reserved Tool IDs like read, write, edit, and bash are pre-defined and don't need reimplementation – their configuration (whitelist, timeout, limits) remains explicitly visible in the manifest.

A2A: The External Communication Contract

While the manifest describes an agent's internal structure, the A2A protocol (Agent-to-Agent) defines external communication between agents. It is deliberately minimal and LLM-agnostic:

• Two roles: user (client) and agent (server). No system, no assistant, no tool – these are LLM runtime implementation details.
• Task-based: A client agent sends a task, the server agent executes it and provides status updates (submitted → running → succeeded) and results.
• Agent Cards: Every agent describes itself at /.well-known/agent-card.json – discovery without a central registry.
• Streaming: Tasks can be processed synchronously or asynchronously with streaming.

The revolutionary aspect: because A2A has no LLM-specific roles, an A2A "agent" can also be a purely deterministic worker without any LLM – a database query service, a computation backend, or a workflow engine. The counterpart doesn't notice the difference. This saves tokens and costs where no reasoning capability is needed.

Translation Layer: A2A Meets OpenAI

ADL agents that want to use an LLM speak A2A on the outside but use the OpenAI-compatible chat format internally. The generated code automatically translates between both worlds:

• Tool calls and tool results are folded into structured parts of agent messages.
• Before being sent to the LLM provider, they are expanded back into system, assistant, and tool messages.
• The provider is swappable via the Inference Gateway (OpenAI, Anthropic, DeepSeek, Ollama, Groq, Mistral – 11+ providers).

Developers don't write this translation layer themselves – the generator creates it.

Inference Gateway & ADK: The Runtime Ecosystem

The Inference Gateway is a lightweight (~10.8 MB) drop-in proxy for /v1/chat/completions that derives the target provider from the model name. It is horizontally scalable for Kubernetes with HPA and supports OpenTelemetry, Prometheus, and MCP integration.

The ADK (Agent Development Kit) is the Go library (also available in Rust/TypeScript) that builds A2A-compatible agents – with fluent builder, task delegation, real-time streaming, OIDC/OAuth2 auth, and artifact backends. It's the runtime that ADL-generated code uses.

Java, Spring Boot & A2A: Enterprise Meets Agents

The Java ecosystem is production-ready for A2A in 2026 – and this matters especially when deterministic, type-safe enterprise components need to be integrated:

• Spring AI A2A (spring-ai-community) exposes Spring AI agents as full A2A servers via autoconfiguration. A single @Bean AgentExecutor with ChatClient and tool registration suffices.
• LangChain4j provides a langchain4j-agentic submodule with MCP and A2A support.
• a2a4j is a dedicated Java A2A implementation with server, client, and Spring Boot starter.
• Spring Dependency Injection is the exact counterpart to ADL's inject mechanism: services are injected into tool handlers instead of accessing global state – enabling clean testing and maintainability.

"Spring DI ≈ ADL's inject mechanism: services are injected into tool handlers instead of global state – the same principle, enforced by the container."

For organizations already invested in the JVM ecosystem, this is the natural path to unite LLM-powered and deterministic agent components under a unified A2A protocol.

OCI Images, Kubernetes & GitOps: End-to-End Deployment

ADL manifest → code generation → OCI image → Kubernetes deployment: the pipeline is fully automated.

• OCI Images: The adl-cli generates multi-architecture Dockerfiles (amd64 + arm64) with multi-stage builds. Compiled languages (Go, Rust) produce lean static binaries for scratch-based images. SBOMs, signing, and provenance are integrable.
• Kubernetes Manifests: adl generate --deployment kubernetes generates complete deployment YAMLs with resource limits and health checks, including the agent card at /.well-known/.
• GitOps: The ADL manifest is by design a single source of truth. Changes go through a normal pull request with review, generation happens in CI, deployment via ArgoCD or Flux. Rollback and versioning are built-in.

A2A vs. MCP: Complementary, Not Competitive

Many developers wonder how A2A and MCP (Model Context Protocol) relate. The answer: they solve different problems.

	A2A	MCP
Solves	Agent ↔ Agent: discovery, delegation, orchestration	Agent ↔ Tool/Context: grounding, integration
Motto	"Connects agents to each other"	"Connects agents to their environments"
Typical flow	Planner agent delegates via A2A to specialists	Agent calls tools/data/APIs via MCP

Together, they form a complete agent system: A2A for horizontal communication between peers, MCP for vertical access to tools and data sources.

Vendor Neutrality as an Architectural Principle

One of the biggest risks in the current AI ecosystem is vendor lock-in – not just at the model level, but at the framework, tool definition, runtime, and deployment levels.

ADL addresses this consistently:

• The provider is swappable (11+ via the Inference Gateway)
• The framework is swappable (Go, Rust, TypeScript, Java/Spring)
• The target platform is swappable (Kubernetes, Cloud Run, Bare Metal)
• The code is understandable – generation scaffolds the boilerplate, developers write the business logic

The manifest remains the contract. Everything else is implementation detail.

Conclusion: Agents as Infrastructure

We are still early in the journey. There will be breaking changes, better ideas, redesigns. But the direction is right: away from fragmented demo projects, toward an open, declarative, and production-friendly way of building agents.

ADL gives agents the contract they need. A2A gives them the language to communicate with each other. The Inference Gateway ensures provider neutrality. And Kubernetes + GitOps give them the infrastructure they deserve.

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

---

Sources and further reading:

• 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)