Your Coding Agent Needs Production Discipline

Approving the feature leaves many decisions unresolved: Which credentials can the agent use? Where can it send source code? How much can it spend, and when should it stop trying? On a laptop, those decisions may be buried in local configuration and the engineer’s existing credentials.

An engineer who has to approve every command is still doing the supervision the agent was supposed to reduce. The company needs those decisions settled and enforced before the engineer steps away.

We already version and review our build pipelines and infrastructure definitions. Agent environments and operating rules need the same treatment. The runtime image, dependencies, access policies and limits should be defined in code, reviewed and applied consistently. That makes agent execution part of the software delivery process instead of another workflow that depends on one engineer’s laptop. Kubernetes gives platform teams a way to provision those environments and enforce their policies.

Give the Agent a Place to Work

The engineer reviews the plan, approves it and hands the session to a managed sandbox provisioned from the reviewed environment definition. The sandbox receives the required project files, and the agent can continue after the engineer disconnects.

For this assignment, the agent runs under a dedicated workload identity, separate from the engineer’s login. A Kubernetes service account provides its cluster identity; access to repositories and external tools requires scoped credentials or configured trust relationships. The platform grants only the permissions needed for the repository, test environment and tools, uses short-lived credentials where supported, and records which engineer approved the run.

Network policies restrict incoming and outgoing traffic, while additional egress controls can limit which external services the sandbox can reach. Runtime, retry and spending limits prevent an unattended assignment from consuming resources indefinitely.

Kubernetes NetworkPolicy depends on a networking implementation that enforces the rules. Spending limits need enforcement in the agent system or inference gateway; a CPU limit does not cap an external model bill.

The Kubernetes SIG Apps Agent Sandbox project gives platform teams a way to manage these environments and their lifecycles. It also supports configurations that use isolation runtimes such as gVisor and Kata Containers. Provisioning and cleanup become the platform team’s responsibility.

Within those limits, the agent can install approved dependencies, modify the code and run tests. The engineer does not need to supervise every shell command.

Decide Where the Code Goes

The agent now sends part of the repository to a model. Where did that code just go? The request may contain existing routes, test failures and details of internal services. Isolating the workspace does not determine who receives that information.

Open-weight models give enterprises a choice about where inference runs. When a model meets the quality requirements of the task, the enterprise can serve it on infrastructure it controls. It can decide where the code is processed and which services may access it. An external frontier model provider may still be appropriate for some work, provided the data and destination are approved.

The workspace and inference service are separate workloads. Tools, coding work and tests may run primarily on CPUs, while a shared model service uses GPU capacity. Kubernetes can operate both. Large models may need several GPUs with sufficient memory and a fast interconnect; each approved location must provide a suitable deployment rather than relying on spare GPUs scattered across providers.

An enterprise should be able to change models or infrastructure providers while keeping the same restrictions on where its code and data can be sent.

Logs, traces and metrics need the same treatment. Keeping inference private accomplishes little if prompts and tool outputs are then exported through a tracing service. The enterprise must decide where those records go and who can read them.

Decide What Happens When a Workflow Fails

Suppose the inference service becomes unavailable halfway through the assignment. The agent tries a fallback endpoint that has not been approved to receive source code.

The platform blocks the outgoing request. With no approved alternative available, the agent pauses and returns the failure, the work completed so far, and the decision it needs. The engineer can approve a suitable service or wait for the original one to recover. Completing the feature does not justify sending the repository somewhere the company has not authorized.

The same principle applies when tests fail repeatedly. The agent can investigate and retry within its limits. When it exhausts them, it should return the failure, what it tried, and the decision it needs. The engineer should not have to reconstruct an hour of activity to understand the problem.

The engineer is also interrupted when a decision exceeds the agent’s authority. Within that authority, the agent should keep working.

Bring the Result Back Through CI/CD

Once an approved inference service is available again, the agent finishes the endpoint and opens the pull request.

CI builds the changes and runs the required tests and security checks, including the new endpoint’s expected responses and error cases. The review includes the changes, the evidence, and any deviations from the approved plan. If the same model writes the implementation, generates its tests, and certifies its own work, we risk repeating the same mistake at every stage. Deterministic checks and independent review remain necessary.

A human reviews the evidence and approves the production handoff. The deployment pipeline promotes the approved artifacts using its own permissions. The agent does not need production credentials to implement a feature.

Now the engineer can judge whether the delegation was useful. How much did the completed assignment cost? How much attention did it require? Did the result meet the standard we would expect from another human contributor? Token consumption and GPU utilization help explain the cost, but verified delivery is what the organization is investing into.

The engineer returns to a pull request for the new endpoint, test results, and a release decision. The agent has done the work without someone approving every command. The enterprise has retained authority over what it could access, what it could spend, and whether the result reaches production. We need to make that repeatable across the engineering organization. As agents build more of our software, our ability to delegate the work will depend on retaining control of the software factory.

KubeCon + CloudNativeCon is taking place in Salt Lake City from November 9 to 12. Register Now!