kagent logo

[ AI tools · Frameworks and platforms ]

AI Agents That Run Like Your Other Services

kagent is an open-source CNCF project that makes an AI agent a Kubernetes resource. We set it up for platform teams so agents deploy through GitOps, follow your access rules and show up in your existing monitoring.

Talk to a Platform EngineerSee the Cluster Rules
incident-triage.yamlEditing
apiVersion: kagent.dev/v1alpha2kind: Agentmetadata:name: incident-triagenamespace: platformspec:type: Declarativedeclarative:modelConfig: default-modelsystemMessage: Triage alerts, propose fixestools: kubernetes-mcp, prometheus-mcpreplicas: 3
triage-7f9cPendingtriage-2b1dPendingtriage-a83ePending

Simplified example manifest. Field names follow the v1alpha2 API in outline.

Agents Described in YAML, Reconciled by a Controller

Started by Solo.io and accepted into the CNCF Sandbox in 2025, kagent adds a few custom resources to your cluster and speaks A2A. Run a command to see each one.

$ kubectl get agents -n platform

NAME              TYPE          READY   AGE
incident-triage   Declarative   3/3     12d
cost-watcher      Declarative   1/1     5d

Example output, simplified.

kind: Agent

Agent

The agent itself: instructions, model, tools and how many copies run. Declarative agents are pure YAML; bring-your-own agents run your container.

[ Cluster rules ]

Agents Get No Special Treatment

The point of kagent is that agents follow the rules your platform team already enforces. These are the six we set up first.

  1. 01

    Namespaces and RBAC

    Each agent runs in a namespace with a service account. It can only read and change what that account is allowed to.

    $ kubectl auth can-i delete pods \
    --as=system:serviceaccount:platform:incident-triage
no
  2. 02

    GitOps delivery

    Agents live in the same repository as your other manifests and roll out through Argo CD or Flux, with review on every change.

    $ argocd app get agents-platform
Sync Status:   Synced to main (4e1c2a9)
Health Status: Healthy
  3. 03

    Secrets stay in the cluster

    Model API keys and tool credentials come from Kubernetes Secrets or your secrets manager, never from prompts or code.

    $ kubectl get secret model-keys -n platform
NAME         TYPE     DATA   AGE
model-keys   Opaque   1      12d
  4. 04

    Traces in your monitoring

    OpenTelemetry traces show each model call and tool call, so agents appear in the dashboards your on-call team already reads.

    trace incident-triage  2.4s
  model.call        1.1s
  tool kubernetes   0.6s
  tool prometheus   0.4s
  5. 05

    Approval before risky actions

    Tools that change things can require a person to approve the call first; read-only tools run on their own.

    tool: scale_deployment  replicas 4 -> 8
status: waiting for approval
approver: on-call platform
  6. 06

    Scale like any workload

    Change the replica count, set resource limits and let the scheduler place agents across nodes.

    $ kubectl get agents -n platform
NAME              READY   AGE
incident-triage   3/3     12d
cost-watcher      1/1     5d
[ Example agents ]

Six Agents Platform Teams Ask Us For

Most start read-only and earn the right to act. Each is a few dozen lines of YAML plus the tools it needs.

  • agent/incident-triageIncident triageReads the alert, checks pod events, logs and recent deploys, then posts a likely cause and a suggested fix to the incident channel.KubernetesPrometheusSlack01
  • agent/cost-watcherCost watcherFlags idle workloads and oversized requests each week, with the saving if they were right-sized.KubernetesCloud billing02
  • agent/release-checkerRelease checkerCompares error rates and latency after a rollout and recommends rollback if they cross agreed limits.Argo CDGrafana03
  • agent/upgrade-helperUpgrade helperLists deprecated APIs and chart versions before a cluster or Helm upgrade and drafts the changes.HelmGit04
  • agent/policy-auditorPolicy auditorChecks manifests against your policies and explains each violation in plain words on the pull request.Kyverno or OPAGitHub05
  • agent/developer-help-deskDeveloper help deskAnswers how do I questions about your platform from the runbooks, with links to the source.DocsSlack06
Engineer wearing glasses working on a laptopOur platform engineers work in your repositories and clusters
[ Honest fit ]

Use It If You Already Run Kubernetes

A good fit

  • You run production on Kubernetes with GitOps
  • Security wants agents under existing RBAC and audit
  • Agents need to work on the cluster itself
  • You want open source with no runtime fees

Choose something simpler

  • You have no Kubernetes today
  • A managed runtime such as Bedrock or Foundry already fits
  • You need one chatbot, not a fleet of agents
  • Nobody on the team can own the cluster
[ How we roll it out ]

From Staging to a Production Agent in About a Month

A typical first rollout. Timing depends on your cluster setup and approvals.

  1. Week 1Install and wire upkagent in a staging cluster, model config, secrets and tracing connected.
  2. Week 2First agent, read-onlyOne agent with read-only tools, tested against past incidents or tickets.
  3. Week 3Approvals and GitOpsWrite tools behind approval, manifests in your repository, rollout through your pipeline.
  4. Week 4Production and handoverPromoted to production with dashboards, limits and a runbook your team owns.

A Cluster Review First

30 minutes with a platform engineer on your cluster, GitOps setup and the first agent worth running. You get a written rollout plan and a fixed quote.

Book the Review

Packages from $1,500; custom projects from $8,000. Developers and teams start within 48 hours.

  • AI Agent Integration$4,000 to $6,000One agent connected to your systems with clear permissions, deployed on kagent in your cluster.1 to 2 weeksDetails
  • Dedicated Developer Trial$3,000 to $5,000/moA platform engineer with Kubernetes and agent experience on your team for a month.1 monthDetails
  • Agent platformFrom $8,000Several agents, shared tools, approvals, tracing and GitOps across your clusters.Timeline set by scope

KAGENT(7)QuestionsKAGENT(7)

kagent Questions

What is kagent?

An open-source framework, in the CNCF Sandbox, that runs AI agents on Kubernetes. Agents, model settings and tool servers are custom resources that a controller keeps in the state you declare.

Do we need Kubernetes experience?

Yes, someone has to own the cluster. If you have no Kubernetes today, a managed agent runtime is usually simpler and we will say so.

Which models can kagent agents use?

Major providers such as OpenAI, Anthropic, Google and Azure OpenAI, as well as models you host yourself. The choice sits in a ModelConfig resource, so switching is a configuration change.

How do agents get tools?

Through MCP servers, either deployed in the cluster or reached remotely. kagent ships tools for Kubernetes and common cloud-native projects, and we add your own.

Can an agent change things in the cluster?

Only what its service account allows, and we put write tools behind human approval until the agent has a track record.

Is kagent ready for production?

It is young and its APIs still change, as with any Sandbox project. We pin versions, test upgrades in staging and keep agents simple enough to move if needed.

Running agents is half of AgenticOps. kagent tools speak the Model Context Protocol, agents talk over A2A, and the cluster itself is DevOps engineers’ work.

[ Contact ]

Let's build your next product together

Book a free strategy call and leave with a clear plan and estimate. No commitment.

  1. 01Pick a time that suits you
  2. 0230 minutes on scope, stack, timeline and budget
  3. 03Fixed-price proposal, NDA on request
Prefer email? contact@sajaltech.com