KAOS — K8s Agent Orchestration System

Deploy, manage, and orchestrate large-scale distributed multi-agent systems on Kubernetes as native CRDs, with every agent exposing an OpenAI-compatible API.

Source repo
axsaucedo/kaos
Stars
★ 282
Last updated
6d ago
License
Apache-2.0
Primary language
Python

At a glance

How it runs
CLISelf-hosted serviceFramework
Works with
Universal · cross-platformOpenAI API
Cost
Free, no paid service needed
Setup effort
High · needs real infrastructure
You'll need
Kubernetes cluster (>=1.28)kubectlHelmPython 3.11 (for kaos-cli)Go >=1.21 (for operator development)Shell / CLINetwork accessMCP Server
Typical use
Platform teams that need to deploy, scale, and monitor multiple AI agents as Kubernetes resources
Not a fit if
  • Teams without a Kubernetes cluster, which the project fundamentally requires
  • Users who just want to run a single agent locally on a laptop
  • Small teams unwilling to operate operators, CRDs, and related infrastructure
Source review
69/100 · Some gaps

What does this agent do, and when should you use it?

KAOS (K8s Agent Orchestration System) is a Kubernetes-native framework for deploying and orchestrating AI agents through custom resources: Agent, MCPServer, and ModelAPI. Its core is a Go operator with three controllers — Agent Controller, MCPServer Controller, and ModelAPI Controller — that manage Agent pods, MCP tool pods, and model-serving pods (Ollama/LiteLLM). Agents run on PAIS (Pydantic AI Server), an enterprise wrapper around Pydantic AI that adds an OpenAI-compatible /v1/chat/completions HTTP API, distributed memory, multi-agent delegation, A2A discovery, health probes, and OpenTelemetry instrumentation. Users can install and manage everything through the kaos CLI, deploy the operator directly with Helm, and monitor agents, test chat, and debug memory and tools in a web dashboard. The project is Apache-2.0 licensed and requires Kubernetes >=1.28.

The KAOS operator reconciles three CRDs: ModelAPI (runs model backends like Ollama/LiteLLM in Hosted mode), MCPServer (exposes tools via the Model Context Protocol, definable dynamically with a python-runtime type and tools.fromString embedded Python functions), and Agent (binds a modelAPI and mcpServers, with agentNetwork defining hierarchical multi-agent access). Once applied, each Agent runs as a pod with the PAIS runtime exposing /v1/chat/completions, callable via kubectl port-forward and curl. A coordinator agent can automatically delegate tasks to specialist agents such as researcher or analyst. The kaos CLI provides kaos system install, kaos modelapi deploy, kaos agent deploy, kaos agent invoke, and kaos ui (which opens the web UI and runs kubectl proxy, with optional --monitoring-enabled telemetry). Sample YAML lives in operator/config/samples/.

  1. Platform teams that need to deploy, scale, and monitor multiple AI agents as Kubernetes resources
  2. Teams building hierarchical multi-agent systems where a coordinator delegates to specialist agents
  3. Developers who want to attach custom Python tools to agents via the MCP standard
  4. Teams with an existing LLM gateway or Ollama that want agents consumable through an OpenAI-compatible endpoint
  5. Operators who need a visual dashboard to monitor agents, test chat, and debug memory and tools
  6. CI/CD pipelines running end-to-end tests against a kind cluster

How do you install or deploy this agent?

Option 1: install via the CLI (requires a configured Kubernetes cluster, kubectl, and Helm):

pip install kaos-cli
kaos system install

Option 2: install the operator directly with Helm:

helm repo add kaos https://axsaucedo.github.io/kaos/charts
helm repo update
helm install kaos kaos/kaos-operator -n kaos-system --create-namespace

Running tests in a development environment:

cd python && uv sync && uv run pytest tests/ -v
cd operator && make test
cd operator && make kind-create
cd operator && make kind-e2e-run-tests

How do you use this agent?

Deploy and invoke an agent with the CLI:

kaos modelapi deploy my-api --mode Hosted --model "smollm2:135m"
kaos agent deploy my-agent --modelapi my-api --model "smollm2:135m"
kaos agent invoke my-agent --message "Hello"
kaos ui
kaos ui --monitoring-enabled

Or deploy declaratively with YAML (simple-agent.yaml):

apiVersion: kaos.tools/v1alpha1
kind: ModelAPI
metadata:
  name: ollama
spec:
  mode: Hosted
  hostedConfig:
    model: "smollm2:135m"
---
apiVersion: kaos.tools/v1alpha1
kind: MCPServer
metadata:
  name: echo-tools
spec:
  type: python-runtime
  config:
    tools:
      fromString: |
        def echo(message: str) -> str:
            """Echo back the message."""
            return f"Echo: {message}"
---
apiVersion: kaos.tools/v1alpha1
kind: Agent
metadata:
  name: assistant
spec:
  modelAPI: ollama
  mcpServers:
    - echo-tools
  config:
    description: "AI assistant with echo tools"
    instructions: "You are a helpful assistant."
    env:
      - name: MODEL_NAME
        value: "ollama/smollm2:135m"
kubectl apply -f simple-agent.yaml
kubectl wait --for=condition=ready pod -l agent=assistant --timeout=120s
kubectl port-forward svc/agent-assistant 8000:8000
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "assistant", "messages": [{"role": "user", "content": "Hello!"}]}'

In multi-agent systems, a coordinator agent lists the specialists it can delegate to via agentNetwork.access:

apiVersion: kaos.tools/v1alpha1
kind: Agent
metadata:
  name: coordinator
spec:
  modelAPI: ollama
  config:
    description: "Coordinator that delegates to specialists"
    instructions: "Delegate research to researcher, calculations to analyst."
  agentNetwork:
    access:
      - researcher
      - analyst

Complete multi-agent examples are in operator/config/samples/.

What are this agent's strengths and limitations?

Pros
  • Every agent automatically exposes an OpenAI-compatible /v1/chat/completions endpoint, so existing OpenAI client code works unchanged
  • Agents, tools, and model services are managed declaratively as Kubernetes CRDs, reusing your existing GitOps, Helm, and monitoring stack
  • Native support for hierarchical multi-agent networks with automatic task delegation, and MCP tools can be defined dynamically with embedded Python functions
  • A built-in web UI lets you monitor agents, test chat, and debug memory and tools, with OpenTelemetry telemetry via SigNoz
Limitations
  • Requires owning and operating a Kubernetes cluster (>=1.28) plus kubectl and Helm — unusable without Kubernetes
  • The project is early-stage (CRDs are v1alpha1, docs versioned at v0.1.4), so APIs may change and production adoption carries migration risk
  • The multi-component architecture (operator, Agent pods, MCP Server pods, ModelAPI pods) adds resource overhead and debugging complexity compared to single-process agent frameworks
  • README examples use the small local model smollm2:135m and give no guidance on hosted LLM providers or pricing — model integration must be evaluated yourself

How does this agent compare with similar options?

The README names no direct competitors, but its agent runtime PAIS (pydantic-ai-server) is an enterprise server wrapper around Pydantic AI that adds an OpenAI-compatible API, distributed memory, multi-agent delegation, A2A discovery, health probes, and OpenTelemetry; compared to using the Pydantic AI library directly, KAOS additionally provides Kubernetes-level deployment and orchestration.

Key facts side by side with the most closely related agents.

Agent Source review Form / cost Stars Updated Language Full support on
KAOS — K8s Agent Orchestration System This agent 69 · Some gaps CLIFree ★ 282 6d ago Python OpenAI API
kagent - Kubernetes-Native AI Agent Framework 43 · Major gaps FrameworkFree + model costs ★ 4.2k today Go —
nanobot 62 · Some gaps CLIFree + model costs ★ 50k today Python OpenAI API
Tares 43 · Major gaps — ★ 44 today Python Codex · Claude Code · OpenAI API · Claude API

How does FollowAgents rate this agent?

FollowAgents source review · FARS-2.1
Some gaps
69/ 100 5-point scale 3.5 / 5
Trust 16/29
Reliability 11/14
Adaptability 14/18
Convention 14/18
Effectiveness 9/13
Verifiability 5/8
Why each dimension lost points
Trust16 / 29 · 2.8/5

Evidence shows strong least-privilege-by-default design ('the declaration is the authorization', default deny, fail-closed PDP, AccessGrants for user/group/agent), earning full marks. Deductions: sensitive-data handling is weak — CLI tests show login tokens stored in plaintext .kaos-config.yaml and a hardcoded kaos-dev-secret; dependency images mostly use :latest tags with no scanning evidence; user confirmation appears only as AIB consent for third-party token exchange, no general confirmation flow; publisher is an unverified personal repo with copyright only to 'KAOS Contributors', so attribution support is thin.

Reliability11 / 14 · 3.9/5

Failure messaging is excellent: troubleshooting sections plus CLI mapping of 403 headers to plain-English denial reasons, backed by unit tests (fail-closed, no identity, ungranted group) — full marks. Self-consistency deductions: README badge says k8s>=1.28 while installation doc says v1.24+; MCPServer spec fields differ between README (type/config.tools.fromString) and quickstart (runtime/params); the install doc contains a your-org placeholder clone URL. Dependency availability offers Hosted/Proxy modes and multiple install paths, but first model pull takes minutes and the runtime depends on an external PAIS repo.

Adaptability14 / 18 · 3.9/5

Audience (platform teams/users), dual CLI/Helm paths, and Docker Desktop/kind/minikube/cloud with arm64 builds are covered — 2. The explicit 'Does not support' section (no per-user downstream authz, ~90s propagation, RS256 only) is thorough — full marks. Autonomous triggers (interval/goal) are declarative but lack finer trigger constraints, deducting 1.

Convention14 / 18 · 3.9/5

Information architecture is excellent (Docs Nav, mermaid architecture, sectioned docs, sample index) — full marks. Install notes cover four install methods, verification, uninstall, troubleshooting — full marks. Known limitations are explicit — full marks. Apache-2.0 LICENSE text matches the badge — full marks. Deductions: no CHANGELOG; images default to :latest; versioning is only implicit (VERSION file, v0.1.4 doc links); MCPServer field naming drifts between docs; maintenance/governance info is limited to 'KAOS Contributors' with no maintainer commitment or update path, and the publisher is unverified.

Effectiveness9 / 13 · 3.5/5

Output usability is good: OpenAI-compatible /v1/chat/completions, CLI JSON/human outputs with tests — 2. Marginal value comes from integrating agent orchestration, MCP tools, authorization, and observability as K8s-native resources — real differentiation but comparable solutions exist — 2. Cost-benefit: requires a full cluster plus optional Gateway/Keycloak/AIB components; the full authorization stack carries significant operational cost — 2.

Verifiability5 / 8 · 3.1/5

Most claims trace to operator/config/samples/ and CLI unit tests (denial-reason mapping, AccessGrant YAML shape, session header forwarding) — 2. Cross-source corroboration mostly holds but doc-vs-doc inconsistencies (k8s version, MCPServer fields, your-org URL) reduce the score. Fact/inference separation is largely clean, though unqualified marketing phrasing ('enterprise server wrapper') appears; security docs are highly specific and credible — 2. All scores are from static source reading without execution; confidence is low.

Risks and how to mitigate them
  • The CLI stores login tokens in plaintext in a local .kaos-config.yaml (confirmed by test code), posing token-exposure risk on shared machines; use disk encryption or caution.
  • Default images and the LiteLLM dependency use latest/main-latest tags; reproducibility and supply-chain safety are not guaranteed — pin digests for production.
  • Documents are inconsistent: K8s version requirement (1.28 vs 1.24+), MCPServer spec fields (config.tools.fromString vs params), and a your-org placeholder clone URL — verify against code before use.
  • Authorization policy and revocation propagation takes ~90 seconds, only RS256 signature verification is supported, and the operator must be restarted after credential rotation.
  • This is a static review with no commands executed; actual behavior of install commands, samples, and tests is not independently verified.
  • Publisher is an unverified personal GitHub account with no maintenance commitment or governance info; assess long-term maintenance risk before production adoption.
Evidence confidence: Low Reviewed Oct 31, 2026 Reviewed revision 4befbbed85c8
See the full review method →

Recent releases

Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.

  1. v0.8.5
    Release notes excerpt
    What's Changed * chore: bump version to 0.8.5-dev by @github-actions[bot] in https://github.com/axsaucedo/kaos/pull/381 * chore(deps): bump the all group across 1 directory with 41 updates by @dependabot[bot] in https://github.com/axsaucedo/kaos/pull/384 * chore(deps-dev): bump brace-expansion from 5.0.8 to 5.0.12 in /kaos-ui in the all-security group across 1 directory by @dependabot[bot] in https://github.com/axsaucedo/kaos/pull/378 * chore(deps): bump the uv group across 3 directories with 2 updates by @dependabot[bot] in https://github.com/axsaucedo/kaos/pull/382 …
    View on GitHub ↗
  2. v0.8.4
    Release notes excerpt
    Overview KAOS v0.8.4 is a dependency-maintenance release. It carries three grouped Dependabot updates — the Go control-plane modules, the Python lock set across all four Python directories, and 36 npm packages in kaos-ui — together with a change to how Dependabot proposes major versions in the first place. There are no changes to KAOS's own runtime code. There are no CRD, API, wire-format or Helm chart changes, and no behavioural changes to the operator, agent runtime, memory service, CLI or UI. Upgrading from v0.8.3 requires no migration. Highlights Control plane …
    View on GitHub ↗
  3. v0.8.3
    Release notes excerpt
    Overview KAOS v0.8.3 is a maintenance release. It carries one grouped Dependabot update of eight npm packages in kaos-ui, all minor or patch, together with a fix to the memory-service test environment in CI. There are no changes to KAOS's own runtime code. There are no CRD, API or wire-format changes, and no behavioural changes to the operator, agent runtime, memory service or CLI. Upgrading from v0.8.2 requires no migration. Highlights UI - One grouped update of eight dependencies, all minor or patch: lucide-react …
    View on GitHub ↗

FAQ

Can I use KAOS without a Kubernetes cluster?
No. KAOS fundamentally runs as a K8s operator with CRDs, and the README requires a configured Kubernetes cluster with kubectl; for local testing you can create a kind cluster and run the E2E tests.
Do I need to pay for model API usage?
The software itself is free and Apache-2.0 licensed. README examples run the small local model smollm2:135m via a Hosted-mode Ollama ModelAPI; you can also connect hosted models through LiteLLM, which would incur the corresponding API costs.
Can my existing OpenAI SDK code call a KAOS agent?
Yes. Every agent exposes a /v1/chat/completions endpoint — after kubectl port-forward you can call it with curl or any OpenAI-compatible client.
How do I add custom tools to an agent?
Create an MCPServer resource. With type python-runtime you can define tools inline via tools.fromString as Python functions, or reference external MCP tool servers.
How do I monitor my agents?
Run kaos ui to open the visual dashboard for monitoring agents, testing chat, and debugging memory and tools; kaos ui --monitoring-enabled enables telemetry, which requires configuring observability such as SigNoz per the docs.
View on GitHub ↗ Install ↓

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents