Cross-cutting Concepts

Capabilities and Plugins Principle

The Agentic Layer architecture follows a design principle of capabilities and plugins that allows implementations to be swapped for various system aspects. This approach supports modularity, extensibility, and vendor independence across major components.

Core Principle

The capabilities and plugins pattern lets the system define stable interfaces while supporting multiple implementations. Each capability represents a defined set of functionality that can be fulfilled by different plugins, enabling runtime or deployment-time selection of an implementation.

capabilities-plugins-principle

Key Benefits

Implementation Independence: Components depend on capabilities rather than specific implementations, reducing coupling and increasing flexibility.

Vendor Neutrality: Avoid vendor lock-in by supporting multiple implementations of the same capability.

Runtime Flexibility: Switch between implementations based on operational requirements, performance characteristics, or cost considerations.

Extensibility: Add new implementations without modifying existing code or disrupting running systems.

Testing and Development: Use different implementations for testing, development, and production environments.

Application Areas

Capability Implementations Today

The Agentic Layer ships the following capability implementations:

  • AgentGatewayClass: KrakenD, via the agent-gateway-krakend-operator.

  • AiGatewayClass: LiteLLM, via the ai-gateway-litellm-operator.

  • ToolGatewayClass: agentgateway, via the tool-gateway-agentgateway operator.

  • GuardrailProvider: guardrail-adapter, the reference adapter for guardrail integrations.

agent-gateway-plugins

Implementation Guidelines

Kubernetes-Native Capabilities

The Agentic Layer uses Kubernetes Custom Resource Definitions (CRDs) as the interface definition mechanism for capabilities. Each capability is defined as a CRD that establishes the contract and configuration schema.

The *Class CRD pattern — AgentGatewayClass, AiGatewayClass, ToolGatewayClass, and the GuardrailProvider resource — is the concrete realization of the capability-plus-plugin principle on the cluster. Each *Class resource names an implementation; workload resources (AgentGateway, AiGateway, ToolGateway, Guard) reference a class to select that implementation. See Agent Gateways, AI Gateways, Tool Gateways, and Guardrails for the per-component CRD references.

Plugin Definition through Custom Resources

Plugins are defined and configured using Custom Resources (CRs) that correspond to their capability CRDs. This approach provides:

  • Declarative Configuration: Plugin instances are declared through Kubernetes manifests

  • Kubernetes-Native Management: kubectl, operators, and existing K8s tooling apply

  • Version Control: Plugin configurations are stored as code alongside infrastructure definitions

Standard Transport APIs

At the transport layer, the system uses standard APIs for compatibility and interoperability.