Introduction and Goals

Purpose and Scope

The Agentic Layer is a Kubernetes-based control plane that runs and coordinates AI agents inside an enterprise. It exposes the agents to external consumers through gateways, routes their traffic to LLM providers and tool servers, and provides cross-cutting governance and observability.

The diagram below shows the top-level building blocks and how external consumers, agents, models, and tools connect through the layer:

  • External Frontends, External Agents, and Apps reach the layer through the Agent Gateway, using protocol-specific entry points: the OpenAI Chat Completion API, A2A, and AG-UI respectively.

  • Inside the layer, the Agent Runtime hosts Agentic Workforces — groups of agents that collaborate via A2A.

  • Agents reach LLM providers (for example OpenAI and Gemini, or a local LLM) through the AI Gateway, which acts as model facade and router.

  • Agents reach internal and external tool servers through the Tool Gateway over MCP.

  • Guardrails enforce content filtering and safety policies on traffic through the gateways.

  • Observability collects traces, metrics, and logs across the layer. Testbench drives the layer for validation. Compliance / Audit is planned.

Agentic Layer Architecture

Implementation Status

The diagram marks blocks that are not yet implemented with the literal label Planned. As of today, this label applies to:

  • Compliance / Audit

All other blocks shown in the diagram exist in an initial version.

Key Advantages

  • Data sovereignty: deployable on-premise or as bring-your-own-cloud, keeping data and models inside defined infrastructure boundaries.

  • Workflow orchestration: coordinates multiple agents and tools into end-to-end processes rather than isolated calls.

  • Open standards: built on A2A, MCP, OpenTelemetry, and Kubernetes, which reduces vendor lock-in.

  • Governance and audit hooks: provides the integration points needed for regulatory frameworks such as the EU AI Act and GDPR.

Pluggable Gateway Implementations

The Agentic Layer keeps its gateway capabilities — Agent Gateway, AI Gateway, Tool Gateway, and Guardrails — interchangeable on purpose. Each capability is split into two CRDs: an instance CRD that describes a deployed gateway (AgentGateway, AiGateway, ToolGateway, Guard) and a class CRD that names the implementation behind it (AgentGatewayClass, AiGatewayClass, ToolGatewayClass, GuardrailProvider).

Switching implementations is a class change, not a code change: the operator reconciles each gateway against the implementation its class points at. The same AgentGateway resource can run against a different implementation without touching the agents behind it, and new implementations can be contributed against the stable class contract.

For the general capability-and-plugin model see Cross-cutting Concepts; for the CRDs and how the operator reconciles them see Agent Runtime Operator.

Requirements Overview

The Agentic Layer is composed of a small set of top-level building blocks, each backed by one or more Kubernetes Custom Resource Definitions. See Building Blocks for the detailed view.

  • Agent Runtime — runs individual agents and groups of agents. CRDs: Agent, AgenticWorkforce.

  • Agent Gateway — north-south entry point for external frontends, agents, and apps. CRDs: AgentGateway, AgentGatewayClass.

  • AI Gateway — model facade and router in front of LLM providers. CRDs: AiGateway, AiGatewayClass.

  • Tool Gateway — egress to tool servers over MCP. CRDs: ToolGateway, ToolGatewayClass, ToolRoute.

  • Tool Servers — internal and external MCP servers exposing tools to agents. CRD: ToolServer.

  • Guardrails — content filtering and safety policy enforcement on gateway traffic. CRDs: Guard, GuardrailProvider.

  • Observability — traces, metrics, and logs across the layer.

  • Testbench — drives the layer for validation and regression.

  • Compliance / Audit — planned.