Investigation: Adopt Kagenti or Kagent for agent orchestration on OpenShift

[usize]

Overview

This demo aims to demonstrate that a Kubernetes CRD + Operator can define an Agent by its surface area (capabilities, health, metrics, identity) and enforce that contract and lifecycle. And to show how this may be largely achieved via interfacing with the Agent Card.

Kagenti and Kagent alread seem to provide a CRD and an Operator for agent/tool deployments. So, if possible, we should try to leverage one of them on OpenShift to realize this model in RHOAI, with minimal OpenShift-specific packaging and policy.

Goals

• Choose a framework that aligns most closely with the goals of 'Agent Orchestration'
• Run or chosen framework on OpenShift with reasonable defaults.
• Add OpenShift policy and packaging only (no new runtime).
• Preserve dynamic discovery and usage (e.g., Claude Code via MCP bridge).

Non-Goals

• No forking or re-inventing existing Kagent[i] CRDs/operator unless required.
• No framework-specific features.

Note

Kagenti should not be confused with Kagent. Though the names are, unfortunately, nearly identical they serve slightly different purposes.

Kagent targets running agents that operate Kubernetes itself for DevOps and platform work. It’s positioned as "Agentic AI for Kubernetes".

Kagenti is a framework-neutral middleware/operator. It focuses on lifecycle, identity (SPIRE), and production hardening for agents on Kubernetes. It is not restricted to Kubernetes ops use cases, which makes it aligned with our goal of supporting general Agentic workloads.

Open questions

• Protocol focus: These projects center on A2A. Do we need a protocol-class label (e.g., agent.class=A2A) to keep room for others, or is A2A sufficient for Dev Preview?
• OpenShift controls to integrate: SCC restricted-v2, NetworkPolicy, Routes, ServiceMonitor, Gatekeeper, ACS. Which are in-scope for Dev Preview vs later?
• Card trust: verify Agent Card signatures in-cluster? Require parity with image signer?
• Tool access: where does the MCP gateway sit in Dev Preview (mandatory vs optional)?
• Workload identity: do we require SPIFFE/SPIRE + OIDC now, or defer to Tech Preview?

Suggested Plan (todo: break down into sub-tasks)

Post-Framework Selection Tasks

• Sample agent: Adapt the existing demo to the chosen framework -> sample deployment, signed model card. Make use of existing features and identify any gaps for openshift.
• Agent MCP Bridge: adapt the existing MCP bridge concept to the chosen framework.

[usize]

@tumido @MichaelClifford cc'ing you in case you have any comments/suggestions as I dig in here. Tom, I did see your notes about the Kagenti operators and will take those into account. 🙏🏻

[zanetworker]

Protocol focus: These projects center on A2A. Do we need a protocol-class label (e.g., agent.class=A2A) to keep room for others, or is A2A sufficient for Dev Preview?

I feel designing for flexibility allows us to pivot easily as needed in the future. If we really extract the main functions we are using out of A2A (e.g., agent cards, discovery,...) and generalize to make other "implementations" fit as needed would that work? I.e., what if MCP builds in a discovery mechanism, what if we want to use something like NLIP, etc.

OpenShift controls to integrate: SCC restricted-v2, NetworkPolicy, Routes, ServiceMonitor, Gatekeeper, ACS. Which are in-scope for Dev Preview vs later?

If we are want to make this "upstream" later, a midstream/upstream approach would make sense (see the llama stack example: https://github.com/opendatahub-io/llama-stack-k8s-operator). Tradeoff here would be double maintainence. I'd be okay with focusing on deep integration with OCP/RHOAI now and generalizing to upstream at a later point.

Card trust: verify Agent Card signatures in-cluster? Require parity with image signer?

In-clutser or multi-cluster (future)?

Tool access: where does the MCP gateway sit in Dev Preview (mandatory vs optional)?

I would not make it mandatory here by design but I would ideally default to its existence for better integration in the stack.

Workload identity: do we require SPIFFE/SPIRE + OIDC now, or defer to Tech Preview?

Its a hot topic, but It could wait till Tech-preview. Also needs more syncs with other teams working on these topics.