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
- FA score
- 69/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API
- Cost
- Free, no paid service needed
- Setup effort
- High · needs real infrastructure
- You'll need
- 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/.
- Platform teams that need to deploy, scale, and monitor multiple AI agents as Kubernetes resources
- Teams building hierarchical multi-agent systems where a coordinator delegates to specialist agents
- Developers who want to attach custom Python tools to agents via the MCP standard
- Teams with an existing LLM gateway or Ollama that want agents consumable through an OpenAI-compatible endpoint
- Operators who need a visual dashboard to monitor agents, test chat, and debug memory and tools
- 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 installOption 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-namespaceRunning 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-testsHow 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-enabledOr 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
- analystComplete multi-agent examples are in operator/config/samples/.
What are this agent's strengths and limitations?
- 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
- 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?
Why each dimension lost points
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.
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.
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.
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.
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.
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.
- 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.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
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 ↗ -
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 ↗ -
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 ↗