CRD overview

Exo Operator is a real Kubernetes operator, so its primitives are CRDs. You author Agent and Tool objects with kubectl apply (or GitOps, or the exo CLI), and the agentkube-manager reconciles them into running workloads.

Group & version

All kinds live in the API group agentkube.io, version v1alpha1, and are namespaced — so an Agent in team-a and one in team-b are independent, and RBAC scopes naturally by namespace.

The kinds

1Kind         Short    Purpose
2─────        ─────    ───────
3Agent        ag       A coding/automation agent: runtime, goal, model, schedule
4Tool         tl       A managed connection (db, ssh, http, k8s) with a bastion pod

Installing the CRDs

Three equivalent ways to register the definitions:

1# Installer (recommended)
2exo-install crds
3 
4# Helm (CRDs ship in the chart's crds/ directory; install-time only)
5helm install agentkube ./agentkube/helm/agentkube --set crds.install=true
6 
7# Raw — apply the generated definitions
8kubectl apply -f agentkube/config/crd-generated/

Authoring resources

Apply a manifest with kubectl, or manage objects through the exo CLI (which proxies to the manager):

1kubectl apply -f agent.yaml
2kubectl get agents -n team-a
3kubectl describe agent triage-bot -n team-a
4 
5# CLI equivalents
6exo agent list -A
7exo agent get triage-bot -n team-a
8exo tool list -A

Sample manifests for every kind live in the repo under agentkube/samples/ — start from those.

Reading status

Each kind writes a .status with a phase and a set of conditions. After applying a manifest, read it back — the reconciler reports the resolved view (effective tools, schedule, errors) there. The per-kind pages that follow call out the fields that matter most when something doesn't come up.