How an agentic skill is formed

Stub.

Frontier models, given access to a cluster, will read the event log, walk every namespace, and recognise an error pattern when they see one. They do this without much prompting — the ability is built into the model. What they don’t have, out of the box, is incident- management context. They don’t track timelines, they don’t know whether an issue is ongoing or resolved, and they don’t remember whether the same pattern was seen and fixed last Tuesday.

That’s the gap a skill fills. Skills are formed by walking the following progression of questions, each of which is harder than the last to answer well:

1. Are there any incidents in the cluster? The lowest-friction question. The model lists what it sees. No memory required.
2. Are there any ongoing, unresolved incidents? Now we need state. What’s been resolved, what’s still alive, what was rolled back. The model has to track facts that span the conversation, not just what’s on the screen right now.
3. Have I seen this before, and how was it resolved? Now we need memory across sessions. The first time the agent meets a pattern, it has to invent a fix. The second time, it should recognise it. By the tenth, the resolution should be routine. This is where organisational knowledge starts to compound.
4. Should this be hot-patched in production, or should it go through GitOps? Now we’re choosing between a fast fix and a durable one. Whether the agent has access to your GitOps repositories — and whether making a change there is obvious enough to do under policy (think: secret propagation and rotation, environment promotion discipline, blast-radius reasoning) — determines which it can responsibly do.

The fourth question is where this booklet hands off to Kubenix. Strong GitOps primitives are what make the durable path safe enough to automate. If your GitOps repo is property-tested, an agent can change it the same way a CI pipeline would, with similar confidence. If it isn’t, every persistent change the agent proposes has to be reviewed by a human — and the value of automating it shrinks accordingly.

There’s a clean parallel between automating persistent changes and choosing strong GitOps primitives: you can’t have one without the other. Hot-patches are reversible by accident. GitOps changes are reversible by design.