CHAPTER 02 · 3 MIN READ

How far one prompt takes you

What a frontier model with kubectl access already does, before you write a single line of skill or playbook.

Author Jōkamachi Systems

Stub.

If you’ve never tried this: open a terminal against a cluster you have admin on, start whichever agentic CLI your team already trusts (Claude Code, Aider with a shell tool, an in-house equivalent), and type the following prompt — exactly the following prompt, with no system message, no playbook, no pre-defined toolbelt:

❯ Are there any incidents in the Kubernetes cluster? Use kubectl, it's already authenticated.

A typical frontier model, in a typical agentic CLI, will respond with something close to this:

● Bash(kubectl get events --all-namespaces --sort-by='.lastTimestamp' --field-selector type!=Normal 2>&1 | tail -50)
  ⎿  NAMESPACE            LAST SEEN   TYPE      REASON                    OBJECT                                        MESSAGE
     zeroclaw             30m         Warning   FailedScheduling          pod/zeroclaw-6859cb68f6-7z58x                 0/6 nodes are available: persistentvolumeclaim "zeroclaw-data" not found. not found
     … +30 lines (ctrl+o to expand)

● Bash(kubectl get pods --all-namespaces 2>&1 | grep -vE 'Running|Completed' | head -50)
  ⎿  NAMESPACE            NAME                                                         READY   STATUS             RESTARTS  AGE
     local-path-storage   local-path-provisioner-848656b4b8-96sx9                      0/1     CrashLoopBackOff   5891 (2m29s ago)
     … +5 lines (ctrl+o to expand)

● Bash(kubectl get nodes 2>&1)
  ⎿  NAME      STATUS   ROLES           AGE   VERSION
     cp-fsn1   Ready    control-plane   29d   v1.35.2
     cp-hel1   Ready    control-plane   29d   v1.35.2
     … +4 lines (ctrl+o to expand)

● Yes, several incidents. Summary:

  Critical:
  - local-path-storage/local-path-provisioner — CrashLoopBackOff (5891 restarts over 12d). Liveness/readiness probes failing on :8080.
  - zeroclaw/zeroclaw-* (2 replicas) — Pending for 12d; PVC zeroclaw-data not found.

  Warnings:
  - istio-system/istio-cni-node DaemonSet — Pods forbidden by PodSecurity baseline:latest (AppArmor unconfined, NET_ADMIN/SYS_ADMIN caps, hostPath volumes). Namespace needs privileged PSA label.
  - istio-system HPAs (istio-gateway, istiod) — Can't fetch CPU metrics; metrics.k8s.io API not registered (no metrics-server).
  - monitoring/loki-read — Readiness 503 (likely transient/startup).

  Healthy: All 6 nodes Ready (3 control-plane, 3 workers) on v1.35.2.

  Want me to investigate any of these further?

What just happened, in one paragraph: the model picked three kubectl commands appropriate to the question — the warning event log, the pods that aren’t Running or Completed, and the node list — read each output, and synthesised a triage report that distinguishes critical from warnings and even calls out what’s healthy. Three commands, no skill, no context, no special prompting. That is a competent first-line operator’s report from a starting state of zero prompting. It is the bar to clear before investing in anything more elaborate.

You do not need KAOS for any of this. You need a frontier model and kubectl.

So the interesting question isn’t can a model do this — it manifestly can. The interesting question is what the report doesn’t say: whether anyone’s already been paged for these incidents, whether they’ve been investigated before, whether the five-thousand-restart provisioner has been a known issue for the last twelve days or whether this is the first time anyone has noticed. The model knows the symptoms; it doesn’t know the history. That’s the gap, and the next chapter walks it.