While agents generate increasingly higher-quality code, it is still up to us to provide crucial judgment and exert control. Since we are the slowest link, there’s always a temptation to leave more to autonomous agents so that our performance may actually increase. The more autonomy we give agents, the more important it becomes to understand and contain the risk they introduce. 

The key component of a modern autonomous engineering system is therefore not blind trust but infrastructure: a system in which human judgment is applied deliberately and precisely where it matters, and in which agents operate within clear guardrails to maintain control over the outcome.

TL;DR

The article explains how CTOs and AI leaders can scale agentic software engineering safely using five control planes: Context, Containment, Validation, Rollout, and Accountability.

What you’ll learn:

• How to classify AI-generated changes by production risk
• Identify high-risk areas like auth, billing, permissions, migrations and how to manage the risk
• How specialist agents can support architecture-aware planning and review
• Why feature flags, behavioral tests, and rollback plans are essential for safe deployment
• How to organize safer agentic infrastructure in a team around high-risk areas
• Where human judgment must remain in the loop when agents touch critical systems

How To Classify Risk in AI-Generated Code Changes

This should make us drop the old question: “human or autonomous?” Instead, we should be asking ourselves a very different question: “How do we know what to trust?”

The risk autonomous changes bring is not distributed equally. From what we already know about agentic generation, not all places expose the system to the same level of damage on failure. There are low-risk areas and high-risk areas, and the way we build around them differs greatly:

And finally, high-risk areas live in components that are crucial to operation: authentication and authorization systems, permission models, billing, key business logic, latency-sensitive or high-throughput systems, data migrations, data integrity, or anything involving data deletion.

• The low-risk areas are where low-impact changes live: documentation, small fixes, isolated code changes, small refactors, and non-production code, such as internal tools.
• Medium-risk areas involve production paths with real user impact: frequently used features, scoped service changes, continuously rolled-out functionality, or changes that would have an immediate but containable impact if they failed.
• And finally, high-risk areas live in components that are crucial to operation: authentication and authorization systems, permission models, billing, key business logic, latency-sensitive or high-throughput systems, data migrations, data integrity, or anything involving data deletion.

It is worth noting that as we advance on the risk ladder, our context gets larger, more complex, and more nuanced. It is not a coincidence that as context grows, the reliability of generations weakens, the need for human judgment increases, and better guardrails must be imposed.

The Five Control Planes for Safe Agentic Infrastructure

Finally, we’re arriving at the key point: how do we build a system in which both humans and agents work together to manage risk and generate output faster and more reliably?

The principles I will discuss here are based on our experiences working in highly agentic environments and are entirely practical. There are five key components that we’ve identified as necessary for safe AI infrastructure. These planes are Context, Containment, Validation, Rollout, and Accountability. We’ll go through all of them with examples.

Context. Give AI agents the architecture knowledge they need

Agents need context to work properly. That applies to all risk levels, but the higher the risk level, the greater the complexity and, therefore, the greater the need for proper context. Agents can acquire context themselves, and that’s fine for low-risk areas, and maybe some medium-risk areas, but in high-risk components we need to help them.

For example, authorization and authentication systems are usually very complex. They encompass the entire platform, multiple components, and usually more than one authentication and authorization method. A system can support programmatic access with API keys as well as standard credential-based authentication. It may issue and validate JWTs, manage API keys, handle sessions and secrets, and connect authentication events to billing and usage tracking. This is a very complex environment that requires careful context management for agents to understand. These agents should know every deployment mode your platform uses, possible configurations, permission matrices, auth modes, and known failure modes.

To handle that, we need to build a high-level context that is readable by both humans and agents. The best-suited platform might be Notion or Confluence or even a dedicated repository on GitHub. The point is to use an internal knowledge system that agents can reliably access via approved integrations, while remaining easy for human reviewers to read and maintain. Each comes with its own set of advantages and drawbacks. When choosing a solution, take into consideration the ecosystem you’re already using, what all business actors are accustomed to, what links well to agentic tools, what provides good enough versioning, and, honestly, what can render a nice diagram. Mermaid diagram support is a good-to-have feature as LLMs can generate diagrams as code for your documentation.

Context documentation should be a component-level, highly abstract, architecture-focused document. Following our auth example, such a document should contain all possible auth paths, all possible authorization flows, all token and API key flows, and all components that play a part in it or depend on it. It needs flow diagrams and a clear description of the intent.

Then, such a document requires specialized agents configured to retrieve, reason over, and apply that context. Build them for your system: an agent that knows the entire auth architecture and is therefore able to scrutinize code changes on that basis alone. Every complex component needs a dedicated specialist agent. These agents are not primarily for writing code. Their role is to detect architectural drift between the real codebase and the documented context, review whether existing code still conforms to the desired architecture, and support planning to ensure that new functionality adheres to the correct guidelines from the start.

Containment. Limit what AI agents can change in production systems

Any change you make in high-risk areas and in some medium-risk areas requires a level of containment. Specialized context agents provide the right guidelines and review generations for architectural drift, enforce conformity, and spot errors early, but quite often, we need to make actual changes in these areas that cause the drift. This is where additional containment comes in.

If your critical code sections are not yet guarded by feature flags, this is the best time to add them. Feature-flagging all breaking changes to high-risk areas is a must. That helps regulate your deployments and eases rollback. You should have at least one, but preferably more, especially if you have different deployment modes and types, staging environments, or testing environments. Make sure all breaking changes are behavior-tested on the exact deployment type to which they need to be applied. Feature gating enables a smooth rollout without breaking the deployments that don’t need the feature just yet.

When introducing complex changes to your deployment via agents, make sure you control and contain what they can change on your clusters. Create roles and permissions intended for agents to assume, designed for a safe rollout with minimal impact. Agents can participate in cluster-level changes, but only through tightly scoped roles, explicit permissions, and well-defined rollout workflows. The goal is not to give agents broad operational access, but to let them operate safely inside constrained boundaries. Similar to programmers using the “constrain yourself” methodology, the best way to avoid problems is not to allow yourself to create them. Agent cluster roles and permissions are exactly that.

Another practical way to strengthen containment is to run agents inside sandbox execution environments: isolated workspaces where an agent can read and write files, install dependencies, and execute code without direct access to production clusters or secrets. Modern platforms such as the OpenAI Agents SDK and managed sandboxes from providers like Daytona or Modal make it easier to scale many agents safely while keeping all agent-side operations constrained to these environments. Be careful, however, as many existing solutions are not hard guardrails, and often agents can escape a sandbox to execute things outside of it unless the gating is system-enforced. 

Validation. Test AI-generated code against real system behavior

In high-risk systems, line-by-line code review is not enough, and it should not be the only control. Agentic reviews, plus human high-level architectural oversight, can get you halfway there. The other half is behavior.

Agents do generate tests; however, they’re often very incomplete. Tests that cover only the happy path or simply confirm the agent’s own implementation assumptions are very common. This is an area where human judgment must be applied thoroughly. Humans specify the behavior they want to achieve and guide agents in writing tests that cover that behavior.

A very useful tool for doing that is behavioral tests supported by Gherkin or something similar. Below is a sample of a parameterized Gherkin scenario – as you can see, it’s easily understandable by both agents (codified enough) and humans (in plain English). Writing desired behaviors in a codified way is a good way to guide the agent to test the correct thing. After automated tests, humans should always manually validate the behavior in a dedicated testing environment. 

Another must-have set of tests is the feature flag test. We need to test the behavior in various system-level states. Test the feature flag on and off. Try enabling different system state switches and see whether the behavior remains correct. Where migrations are reversible, test them forwards and backward. Where they are not, explicitly identify the point of no return and the operational safeguards required before crossing it. Mark the potential points of no return or irreversible data loss that may result.

Rollout. Deploy agentic code changes with feature flags and rollback plans

Areas of higher risk need special care during the rollout phase.

Rollback should be designed before deployment, not improvised during an incident. In fact, all major changes in these areas should be designed with rollback in mind, not as an afterthought. If you paid attention to all previous phases, at this point, all migrations should be tested back and forth, all points of no return identified, and all feature flags present and tested. Rollbacks should also be tested to the extent possible.

This phase is mostly a human responsibility: flip the flags, run migrations, judge behavior, and the end result. If possible, structure rollout around an explicit checkpoint before the point of no return. Validate the system state, confirm rollback readiness, and proceed with the irreversible step only then.

Agents can also help during rollout phases. If you’ve correctly identified and prepared all previous phases, you likely have specialized agents that know the deployment type they need to roll the changes out to, the feature flag setup, and the interactions between related flags. In lower-risk functionalities or less complex environments, this can even be a simple CD workflow. You need to be ready to execute the rollback plan and monitor the deployment.

Accountability. Keep human ownership over high-risk AI decisions

Finally, we arrive at what may be a somewhat obvious section, but not an unimportant one. Specialist agents can reduce blind spots, but they do not remove accountability. An auth reviewer agent can inspect a PR against permission documentation, deployment modes, and known invariants. A deployment composer can verify that risky behavior is correctly gated. A migration reviewer can inspect reversibility and data safety.

But for high-risk systems, humans still own the decision. If you built your pipeline correctly, your agentic environment can help you make better decisions, focus on the most important things, and be much more informed, not less. Build it poorly, and the final decision point becomes a gamble rather than a controlled judgment. All this work not only improves performance but also helps you mitigate risk and gives you a better chance of avoiding damage to high-value components.

Running Example: Safely Using AI Agents to Modify Authentication Systems

Let’s now see how such a system could work in a practical example of implementing a major change in a high-risk, critical area: a change to authentication behavior in a platform with multiple deployment types.

A generic coding agent may understand the local files it edits, but in our experience, it will almost always miss the bigger-picture complexity. It usually focuses on one happy path in the flow that it thinks is at play, while completely missing that:

• one deployment uses a different auth provider
• one customer segment depends on legacy permissions
• a flag is enforced in the frontend but not the backend
• a migration affects token behavior
• a test covers the happy path but not privilege escalation
• rollback disables UI access but leaves an API path exposed

We’ve seen even more extreme examples: agents relying on existing but unused code paths, choosing legacy backward-compatibility mechanisms instead of the intended new ones, or misinterpreting obscure but still active legacy auth paths.

A safer agentic workflow starts before code generation.

1. First, the change is classified as high risk because it touches auth.
2. Second, the auth knowledge base is retrieved: diagrams, permission matrix, deployment modes, known invariants, and previous edge cases.
3. Third, two specialist agents, auth and deployment agents, help compose a plan for building the change. The plan identifies affected flows, required tests, feature flags, compatibility constraints, and rollback assumptions. They also help verify what coding agents were created from the plan.
4. Fourth, implementation happens inside containment: a feature flag, a strategy boundary, or a clearly isolated path.
5. Fifth, validation covers both new and existing behavior, with the flag on and off. Rollback plans are defined early and tested before anything reaches staging or production rollout.

Finally, the human reviewer receives a focused brief: what changed, which auth modes are affected, what the agent checked, where confidence is high, and where human judgment is required. Human reviewers must never forget that, despite all their efforts, it’s still a language model’s output, so the final judgment layer always belongs to them. Especially in high-risk areas, exercise a healthy dose of doubt. This is the point where they should check behavior for correctness, run manual QA, test the real deployment, and return the work to the agent’s hands for any corrections.

After everything is accepted, it is time for specialized agents to run checks for documentation drift. The new functionality likely changed something major in the auth path; therefore, the docs need to be updated immediately so other specialized agents can get the updates.

Safe Agentic Engineering Requires Infrastructure, Not Blind Trust

The organizations that scale output with agents successfully will not simply be the ones that trust AI more. They will be the ones who build better systems around autonomy.

Risk-based deployment gives teams a way to move faster without pretending all work is equal. Low-risk changes can become increasingly automated. Medium-risk changes can move through containment and validation. High-risk changes can benefit from agents while involving human-supported judgment on several levels.

In the experimentation phase, agents are impressive because they produce code.

In the infrastructure phase, agents are valuable because they move work through context, containment, validation, rollout, and accountability, all while leaving clear points for humans to catch mistakes, exert control, and guide the system in the right direction. That is the paradigm shift: not just faster output, but higher-quality and safer deployments.