kprompt vs ARK: AI Runtime that operates the cluster vs Agentic Runtime that hosts agents

Both products use the word runtime next to Kubernetes. That is enough to confuse a search result. McKinsey’s open-source ARK calls itself an Agentic Runtime for Kubernetes. kprompt calls itself The AI Runtime for Kubernetes. The shared noun hides two different jobs.

Short answer: ARK extends Kubernetes so you can declaratively run agentic applications — Agents, Teams, Models, Tools, Memory, Queries as CRDs, similar to how Argo extends Kubernetes for workflows. kprompt is a reasoning layer for operating the cluster: observe signals, compile intent into a reviewable PlanResult, approve, then apply. ARK hosts agents on Kubernetes. kprompt reasons about Kubernetes.

Quick decision

Same metaphor, different Argo analogy

ARK’s own framing is the clearest differentiator. Docs describe Ark as extending Kubernetes with CRDs and services for agentic workloads — “in a similar way to how Argo extends Kubernetes to run workflows.” That is an application platform story: put agent systems onto the cluster as first-class citizens.

kprompt’s analogy is closer to a reasoning control loop for the existing control plane: Kubernetes schedules containers; Operators reconcile state; kprompt reasons about what is happening and proposes gated changes. We are not trying to be the Argo of agents. We are trying to be the approve-gated brain for day-2 cluster work — laptop CLI today, optional in-cluster Observe agent for always-on signals.

Side-by-side

What ARK is good at

• Declarative agents as Kubernetes resources — prompts, tools, model refs
• Provider-agnostic model configs (swap OpenAI / Anthropic / Azure / Ollama without rewriting app code)
• Multi-agent team strategies and dashboard-driven authoring
• MCP servers, A2A interoperability, and a marketplace-shaped extension story
• Running the agent stack where you already run distributed systems — including local kind/minikube and multi-cloud

If your product is an agentic application and Kubernetes is the host, ARK is solving your problem. That is a real, valuable category — just not the category kprompt is in.

What kprompt is good at

• Natural language → typed plan with diffs, risk, and hard denies before apply
• CI-stable PlanResult JSON so pipelines can refuse a mutate
• Day-2 backends (Helm, metrics, GitOps, …) under the same approval loop
• Investigation-shaped prompts (explain / investigate / why / timeline) without silent apply
• Optional Observe agent: namespace watch → Incident → gated Slack/webhook — notify, not self-heal

$ kprompt "scale api to 10" -n payments
# shows Intent / Plan / Risk / Blast radius
Apply? [y/N]

$ kprompt agent run -n payments --health --heuristic
# Observe path: correlate + score; Autopilot stays propose-only

Naming collision — how to read “runtime”

When you see “runtime for Kubernetes,” ask one question: runtime for what?

• ARK — runtime for agentic workloads (your agents run on the cluster)
• kprompt — runtime-shaped loop for cluster intelligence (reasoning about the cluster’s workloads)

We are not claiming ARK is wrong or that the names must be unique forever. We are claiming the jobs should not be collapsed in a buyer’s head. Hosting agents ≠ operating the cluster under an approve gate.

Can they coexist?

Yes. A platform team can run ARK to host internal agent products while operators use kprompt (or kubectl + K9s) to change Deployments safely. An ARK agent could even call out to operational tools — but kprompt’s differentiator remains the PlanResult approval boundary for cluster mutates, not a general agent framework.

We do not ship a Kagent/ARK-class multi-agent application platform. Our optional in-cluster path is Observe-first and propose-first for Autopilot. If you need Agents as CRDs, MCP/A2A, and a mesh-native agent control plane, that is kagent’s lane (or ARK’s).

Honest limits (both sides)

• kprompt is experimental — read every plan; prefer non-prod; never treat Autopilot as silent heal
• kprompt is not a declarative multi-agent app framework
• ARK is not a plan-before-apply cluster ops CLI; cluster safety is whatever you build into agent tools and RBAC
• Neither replaces kubectl for precise API scripting or K9s for live terminal navigation

Try kprompt

curl -fsSL https://kprompt.ai/install | bash
# or: brew install kprompt/tap/kprompt

kprompt "list deployments" -n staging
kprompt "scale api to 3" -n staging   # review → y/N

For ARK’s own quickstart (cluster + ark install + dashboard), start at their docs. For how we think about category without hype, read the AI Runtime essay next.