Cross-cutting Concepts
Capabilities and Plugins Principle
The Agentic Layer architecture embraces a fundamental design principle of capabilities and plugins that enables flexible switching of implementations for various system aspects. This approach promotes modularity, extensibility, and vendor independence across all major components.
Core Principle
The capabilities and plugins pattern allows the system to define stable interfaces while supporting multiple implementations. Each capability represents a well-defined set of functionality that can be fulfilled by different plugins, enabling runtime or deployment-time selection of the most appropriate implementation.
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
Exemplary Agent Gateway Implementations
The Agent or AI Gateway capability could support multiple reverse proxy and API gateway implementations:
-
Nginx: Traditional reverse proxy for high-performance routing
-
Envoy: Modern service mesh proxy with advanced traffic management
-
Kong: API gateway with rich plugin ecosystem
-
Istio Gateway: Kubernetes-native gateway with service mesh integration
Implementation Guidelines
Kubernetes-Native Capabilities
The Agentic Layer leverages 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.
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: Leverage kubectl, operators, and existing K8s tooling
-
Version Control: Plugin configurations are stored as code alongside infrastructure definitions