Kai

Kai is the Platform Engineer on your team — part cartographer, part infrastructure critic. Show him a manifest, change plan, network design, or architecture and he maps the system under pressure: where it fails first, how far that failure travels, and whether the exit still works. His calls are spare and unmistakable: Clear. Contain. Hold. Redesign.

Who Kai is#

Kai owns the whole platform, not just the cluster: compute, orchestration, networking, infrastructure-as-code, and the operating evidence around them. In briefing gear he gives the verdict, first fracture, evidence, and decision question. In workbench gear he shows the topology, calculations, failure envelope, and reversible path. Platform code belongs with Kai; application behavior belongs with Cody, with both involved when the seam is the risk.

Working with Kai#

Share the thing and ask for the call. Paste manifests, a Helm values file, a terraform plan output, a network diagram, a deployment design, or just describe the situation. When Kai's missing context he asks one pointed question, not five.

Compute & orchestration review#

Share compute and orchestration work — manifests, Helm charts, a deployment design, an autoscaling or capacity plan across EC2, containers or serverless — and Kai reviews it for production-readiness, structured blockers-first:

Each point is one line — the missing PodDisruptionBudget that turns a node drain into an outage, the resource requests that will wreck bin-packing, the autoscaling floor that can't absorb a spike, the RBAC grant that's too broad. He tells you what to push your team toward and what to block.

Terraform & IaC review#

This is where Kai earns his keep for a leader. Give him actual Terraform plan JSON and review_platform_change structurally inventories every accepted resource within explicit caps: creates, updates, deletes, forced replacements and replacement paths, recognized stateful destruction, and conservative public-surface signals. Kubernetes YAML gets the same treatment across every accepted document, including declared routing surfaces and defensible workload gaps. For Pulumi, CloudFormation, CDK, or prose-only changes he can still pressure-test the stated design, but labels that weaker evidence boundary.

The analyzer is read-only. It does not execute Terraform, inspect state, contact a provider or cluster, render Helm/Kustomize, apply admission defaults, or prove backup and rollback viability. Its output is a reproducible READ + COMPUTED change pack—preflight, validation, and rollback—not permission to apply.

He also reviews module structure and provider/version pinning at the leader altitude, and pulls in teammates by lens: Cody on the module code structure, Daphne on the security lens of what a policy or resource exposes, and Finn on what the change costs to run.

Platform pressure review#

Kai uses two code-backed reviews. review_platform_change parses machine artifacts—Terraform plan JSON and Kubernetes YAML—and returns a versioned action inventory, findings, first fracture, verdict, limitations, and proposal-only change pack. review_platform_design handles architecture prose, scoring the evidence present across load and capacity, failure containment, rollout and reversibility, observability, security, networking, state recovery, and ownership. Both are repeatable evidence triage, not a live audit or proof that a change is safe.

Networking#

Kai owns the network the platform runs on — VPCs and subnets, CIDR planning, load balancers, DNS, ingress, and service mesh. Show him a network design or a subnet layout and he tells you where it breaks: the overlapping CIDR that will block a future peering, the subnet sized too small for the pods it has to hold, the security-group rule that's wider than it needs to be, the ingress path that skips the mesh. Subnet host counts and CIDR overlaps he computes rather than eyeballs.

Troubleshooting#

Describe an infrastructure issue — CrashLoopBackOff, pods that won't schedule, a scaling problem, a networking failure, a Terraform apply that errored halfway — and Kai helps you diagnose it: the likely cause, what to check, and the safest next move. With a cluster connected, k8s_triage reads degraded workloads, failing pods, node condition, Warning events, and optional usage into one bounded snapshot. It deliberately does not pull logs; Kai requests a targeted, bounded log tail only when the snapshot justifies it.

The live cluster#

Connect a read-only ServiceAccount token in Settings → Kubernetes and Kai reads the real cluster instead of reasoning from memory: Deployments, StatefulSets and DaemonSets with replica health, Running-but-unready pods as well as explicit failure states, node conditions and cordons, recent Warning events, optional CPU/memory usage, and bounded pod-log tails on request. Everything is read-only by construction: there is no scale, delete, or exec path. Pair it with Night Shift — “tell me if anything starts crashlooping” — and the team checks on a schedule.

Best practices#

Ask Kai about EC2 vs. serverless, autoscaling strategy, EKS upgrades, KEDA, Karpenter, GitOps, RBAC, Terraform module structure, or anything across the platform and you get a decisive, leader-framed answer — the trade-off, the recommendation given likely constraints, and what will bite you later if you skip it.

The infra toolbox#

Behind his answers Kai carries a toolbox of roughly a thousand deterministic infrastructure utilities — resource math, capacity and bin-packing, CIDR and subnet arithmetic, manifest and change-description linting, RBAC checks, failure diagnosis, version-skew lookups, generators, SLO math, and cost estimates. Computed arithmetic is exact for the supplied inputs; lint and version guidance is repeatable but heuristic and may be time-bounded. Kai keeps those evidence grades separate instead of making the whole verdict sound more certain than it is.

Watches, studios & lessons#

Kai shares the team's toolkit: put a data pull on the Night Shift watchlist to be alerted on a material change, jump into the right studio with a one-click chip, and correct him — "always flag a forced replace on a stateful resource", "keep it to three bullets" — and he files it as a durable lesson that changes how the team works from then on.