Agents that run on your cluster.
Cursor Cloud Agents plan in the cloud. The tools they run — shell, git, kubectl — should live next to the systems they change. This is a worker image and Helm chart so they do.
The problem
A managed sandbox is enough for a public repo and a unit test. It falls short when the job is a Helm bump, a kubectl rollout, or a git operation against infrastructure you already operate. The agent needs a long-lived worker on your cluster — not a disposable environment you cannot see.
The model
A container image with the Cursor worker and the tools a coding agent actually uses. A Helm chart that keeps that worker running as a cluster workload. Cursor still runs the agent loop. The worker executes the tools, outbound, on infrastructure you own.
Worker image
Cursor worker plus shell, git, kubectl. The same tools a human would use from a laptop.
Helm chart
Long-lived deployment. GitOps-friendly. Treat the worker like any other lab service.
Agent loop
Cursor plans and streams tool calls. The worker runs them. Nothing inbound.
Delivery
Same path as the rest of the lab. Image and chart ship through Git. GitOps syncs the worker onto the cluster. A commit is the change; a sync is the deploy. The worker stays up so a coding agent can claim it and run tools without a cold start.
Why this shape
Agents that cannot reach your cluster cannot operate it. Putting the worker on Kubernetes means the same RBAC, the same GitOps history, the same operating model as everything else. Long-lived, not spawned per prompt — so the tools stay warm and the change path stays boring.
← Projects