All posts
Muhtalip Dede profile photoMuhtalip Dede · Founder of kprompt5 min read

kprompt vs kagent: PlanResult ops CLI vs Kubernetes-native agent platform

kagent (CNCF Sandbox) is a Kubernetes-native agent runtime — Agents as CRDs, MCP, A2A, mesh. kprompt is an AI Runtime for cluster ops: PlanResult → approve, plus Observe notify. Overlapping SRE demos, different products. Decision guide.

kagent markets itself as a Kubernetes-native agent runtime: bring AI agents to every cluster, deploy them as CRDs, wire MCP tools, govern traffic with the mesh, observe every prompt with OpenTelemetry. kprompt markets itself as The AI Runtime for Kubernetes: observe the cluster, reason, emit a reviewable PlanResult, approve, then apply. Both say “runtime.” Both talk about incidents and platform engineering. They are still different products.

Short answer: choose kagent when you need an in-cluster agent platform — Agents, tools, sessions, A2A, GitOps rollouts, BYO LangGraph/CrewAI/ADK. Choose kprompt when you need a plan-before-apply ops contract on a laptop CLI (and an optional Observe agent that notifies without silent mutate). kagent hosts and governs agents on Kubernetes. kprompt compiles cluster intent into a refuse-able plan.

Quick decision

You care about…PreferWhy
Agents as CRDs + GitOps + mesh policykagentCNCF Sandbox agent platform; kubectl apply -f agent.yaml
Reviewable PlanResult before every mutatekpromptPlan → safety → y/N; wipe-class hard denies; CI JSON
MCP tool servers / A2A multi-agent compositionkagentFirst-class MCP + A2A + BYO frameworks
Laptop NL CLI for day-2 (Helm, explain, scale)kpromptOne binary, BYOK, kubeconfig-local; no required control plane
Always-on namespace alerts → Slack (notify-only)kprompt ObserveWatch → Incident → gated webhook; Autopilot propose-only
Build custom SRE agents with Istio mTLS + OTel spans per tool callkagentAgent substrate + mesh + full prompt/tool observability

Why the overlap feels real

Unlike a pure “host any chatbot on K8s” pitch, kagent’s public use cases lean into platform ops: incident response agents, observability copilots, self-service that opens GitOps PRs, multi-agent triage → investigate → remediate. It also ships MCP servers for kubectl, Prometheus, Argo, Istio, and friends. That is exactly the demo vocabulary AI SRE products use.

So a buyer can honestly ask: “Isn’t that what kprompt does?” Only if you collapse “agent that can call kubectl tools” with “product whose primary artifact is a gated PlanResult.” They share a problem space. They do not share a product contract.

Side-by-side

Dimensionkagentkprompt
Category claimKubernetes-native agent runtime / frameworkAI Runtime for Kubernetes (cluster ops / AI SRE)
Maturity signalCNCF Sandbox; Solo.io heritageExperimental Apache-2.0 CLI + optional Observe
Primary artifactsAgent / Session / ToolServer CRDs + tracesPlanResult (+ Incident / AgentAlert for Observe)
Default surfaceIn-cluster control plane + UI/CLILaptop Go binary; Observe via Helm when you opt in
How agents runController provisions runtimes (ADK / substrate)No general agent CRD platform — Observe is a fixed pipeline
Mutate contractTool calls + HITL gates you configure on agentsAlways plan → safety → human approve for CLI mutates
CI gateBring your own around agent outputs / PRsStable PlanResult JSON on stdout
InteropMCP, A2A, LangGraph, CrewAI, Google ADK, meshkubectl-shaped ops + Helm / Prom / GitOps under one plan loop
Who owns blast radiusPlatform team (SA, mesh egress, agent RBAC)Operator at the keyboard (+ Role-scoped Observe SA)

What kagent is good at

  • Treating agents like any other Kubernetes workload — GitOps, RBAC, admission, rollouts
  • Standards stack: MCP tools, A2A delegation, OpenTelemetry on every prompt/tool/token
  • BYO frameworks and multi-LLM providers without rewriting the control plane
  • Mesh-native security story (Istio / Ambient) for agent egress and identity
  • Building bespoke ops agents (k8s-agent, istio-agent, observability) as composable CRDs

If your platform team’s job is “agents are a product we run next to apps,” kagent is in the right category. Human-in-the-loop is a platform feature of those agents — not the same thing as kprompt’s PlanResult-first CLI contract.

What kprompt is good at

  • Natural language → typed plan with diffs, risk, and hard denies before apply
  • CI-stable PlanResult so pipelines can refuse a mutate without scraping chat
  • Day-2 backends under one approval loop (Helm, metrics, GitOps, …)
  • Investigation-shaped prompts without requiring an agent control plane
  • Optional Observe: namespace watch → correlate → gated Slack/webhook — never silent Autopilot apply by default

kprompt’s default mutate path

$ kprompt "rollback payment-api" -n payments

Intent: rollback
Plan: rollout undo Deployment/payment-api
Risk: medium
Apply? [y/N]

Observe agent vs “install an SRE agent CRD”

This is the sharpest confusion point. kagent can run a declarative agent with Kubernetes MCP tools that watches and acts (within HITL). kprompt’s Observe agent is a narrower, kprompt-native pipeline: Events/Pods → Incident → optional LLM → Slack/webhook. It reuses investigation DNA. It does not expose a general Agent CRD API, Teams graph, or A2A marketplace.

Choose kagent when you want to author many agents and tools as cluster resources. Choose kprompt Observe when you want threaded, gated alerts with Incident artifacts — and keep the laptop CLI for plan → approve → apply.

kagent vs ARK vs kprompt (one glance)

ProductJob in one line
kagentCloud-native agent platform on Kubernetes (CNCF; MCP/A2A/mesh)
ARKDeclarative agentic app host on Kubernetes (McKinsey agents-at-scale)
kpromptPlan-gated cluster ops + optional Observe notify (AI Runtime for ops)

kagent and ARK share the “agents as workloads” lane with different ecosystem bets. kprompt shares some SRE demos with kagent but not the platform. For the ARK-specific naming collision (“Agentic Runtime”), see the ARK comparison.

Can they coexist?

Yes. A platform team can run kagent to host internal agents (docs RAG, ticket triage, mesh-aware helpers) while operators use kprompt for gated day-2 mutates and Observe for namespace paging. An ambitious setup could even have a kagent agent propose changes that a human still applies via kprompt’s PlanResult — but that composition is yours to build; we do not claim it ships today.

Honest limits

  • kprompt is experimental — read every plan; prefer non-prod first
  • kprompt is not a CNCF agent framework, not A2A/MCP control plane, not Istio-native agent mesh
  • kagent is not a PlanResult-first laptop CLI; cluster safety depends on how you configure agent tools, HITL, and RBAC
  • Neither replaces kubectl precision or K9s live navigation
  • Marketing overlap on “incident agent” does not erase the artifact difference

Try kprompt

Install + gated plan

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

kprompt "explain why api is crashing" -n payments
kprompt "scale api to 3" -n staging   # review → y/N

For kagent’s own quickstart (kind + Helm + Agent CRD), start at kagent.dev. For category without hype, read the AI Runtime essay. For the other “runtime” naming cousin, read vs ARK.

Related posts