Most coding-agent products treat the agent as a chat session with a shell attached. You send a prompt, a VM somewhere does something, and eventually a PR appears. That works — until you need to answer questions like what is running right now, who approved it, why did it retry, and what exactly did it change?

Kubernetes solved those questions for deployments a decade ago. The answer was not a better script runner; it was the reconciliation model. We built nominos-core on the same idea, because code changes deserve the same treatment as infrastructure changes.

Reconciliation, applied to code changes

In Kubernetes you don’t tell the cluster how to start a container — you declare the state you want, and a controller drives reality toward it, retrying and reporting along the way.

An AgentJob works the same way. You declare the outcome:

apiVersion: nominos.io/v1
kind: AgentJob
metadata:
  name: fix-flaky-checkout-test
spec:
  task:
    description: "Fix the flaky retry logic in checkout_test.go"
  repository:
    url: https://github.com/org/shop
    createPR: true
  timeoutSeconds: 3600
  backoffLimit: 3

The controller reconciles that into a pod that clones the repo, runs the agent, pushes a branch, and opens a PR. If the pod dies, checkpoint state lets the job resume rather than start over. If the agent fails, the controller retries up to backoffLimit, then reports Failed with the logs preserved in status — not lost with the pod. Timeouts, cost caps (maxCostDollars), and priorities are spec fields, not conventions buried in a wrapper script.

This is the difference between “we run agents in CI” and “agents are a workload type.” CI jobs are fire-and-forget. Workloads have desired state, observed state, and a controller closing the gap.

CRDs are an audit trail you already know how to read

Because every task is a custom resource, the usual Kubernetes machinery applies for free:

  • kubectl get agentjobs shows every task, its phase, branch, and commit count — printer columns included.
  • status carries the full evidence trail: commits, changed files, PR URL, token usage, estimated dollars, retries, warnings.
  • RBAC decides who can create or cancel agent work, using the same roles your platform team already manages.
  • GitOps tools can manage agent tasks like any other manifest. An AgentPlan with ten ordered steps is a YAML file in a repo, reviewed like everything else.

For regulated teams, this matters more than any model benchmark. “Show me every automated change to the payments service in Q3, who triggered it, and what it cost” becomes a kubectl query, not an archaeology project across a vendor’s dashboard exports.

The ecosystem is converging on this

We’re not alone in thinking agents are a Kubernetes workload type. Kubernetes SIG Apps’ agent-sandbox work standardizes sandboxed agent runtimes on K8s — exactly the layer nominos-core schedules onto. Gartner projects that by the end of 2026, 40% of enterprise applications will embed task-specific agents, up from under 5% in 2025. When agent execution becomes a standard cluster workload, the interesting question shifts up a layer: who orchestrates the work, orders the dependencies, and lands the results safely? That layer is CRDs and controllers.

Pod isolation is real isolation

Every agent runs in its own pod: its own filesystem, its own resource limits, its own network policy, its own service account. That gives you properties that are awkward to bolt onto a VM-per-session product:

  • Blast radius: an agent working on repo A physically cannot touch repo B’s checkout.
  • Resource fairness: spec.resources is a normal requests/limits block; a runaway agent gets throttled by the kubelet, not by hope.
  • Egress control: your network policies decide whether an agent can reach anything beyond the model API. Your code never leaves the cluster — the only egress is the inference call, made with your key.
  • Scheduling: priorities, node selectors, and quotas all work, because these are just pods.

And when the work is done, the merge is governed too: the MergeQueue CRD rebases the PR, gates on CI, resolves conflicts with an agent (escalating to humans after bounded attempts), and auto-reverts within a monitoring window if the merge breaks the target branch.

None of this is exotic. That’s the point. Coding agents don’t need a new operational model — they need the one your cluster already has.

nominos-core is open source. If you’d rather your agents answer to your cluster than to someone else’s cloud, request early access.