Treating Safety as a Brake Is How Teams Fall Behind at Agent Speed

In the race to move faster with software delivery, the desire to add more approvals and checks before changes are merged, deployed, or released can seem prudent. However, each additional safeguard can inadvertently slow down the entire process. Treating safety as a hindrance rather than a necessary measure can lead teams to believe that every change carries the same level of risk.

As software factories embrace agents and automated workflows to handle greater development workloads, this mindset becomes harder to justify. To maintain safety at the pace of agents, controls must be strategically placed where risks originate, their purpose clearly defined, and their timing carefully determined.

Rushing releases does not necessarily enhance safety. Waiting can actually reduce risk if used to address specific issues like unstable dependencies, failing critical tests, or unprepared on-call rotations. The key difference lies in distinguishing between time spent fixing problems and time spent waiting for authorization. The latter type of delay incurs its own costs.

When changes are hoarded for scheduled releases, they can accumulate into larger batches, complicating the identification of regressions and making recovery more challenging. Waiting without a clear purpose can instead concentrate risk rather than mitigate it.

A more effective approach involves designing constraints that govern specific decisions and actions. Safeguards are controls intended to minimize the likelihood or impact of adverse outcomes. Some controls prevent issues before they occur, others detect problems as they arise, and others limit damage or assist in system recovery.

Speed training provides a relevant analogy. Athletes often train on treadmills with safety harnesses, allowing them to push their limits while minimizing the risk of serious injury. Similarly, software safeguards enable routine work to proceed smoothly while intervening only when necessary.

In a software factory, these boundaries apply throughout the development lifecycle, from intake and planning to execution, review, and release. For instance, consider a factory producing numerous pull requests, each requiring identical manual approval. As the queue grows, engineers spend more time reviewing routine work, leaving less time for changes that carry significant risk.

A policy based on risk could route each pull request through automated validation for low-risk updates, while work involving sensitive data, elevated permissions, or critical infrastructure would require human approval.

Effective safeguards should be determined by identifying the decision to govern, the associated risk, and the stage at which that risk can be best evaluated. Controls can either allow the change to proceed automatically, require human review, or halt the process until a problem is resolved. Early safeguards can prevent costly rework.

For example, if an agent assigned to modify an application's data export functionality produces a plan that exposes data beyond the intended permission scope, a risk-based approval gate placed after planning but before implementation can catch this issue early. The agent can then revise its plan, avoiding the need to rebuild the feature and reducing the need for repeated development cycles.

Release safeguards are crucial, as they operate at a different decision point than the release of a change. Readiness for deployment does not guarantee that the software will perform as expected in production, so teams need mechanisms to observe production behavior and mitigate the consequences of unexpected outcomes. Design questions remain at the release stage, shifting from authorizing implementation to determining the extent to which users should encounter the new functionality.

A team might limit initial exposure to a limited audience, monitor error rates and latency as the rollout progresses, and gradually expand access as long as performance metrics remain within acceptable limits. If signs of trouble emerge, predefined policies or human intervention can pause the rollout, investigate the issue, or reverse exposure without triggering another deployment.

These safeguards work because they respond to real-time production data. Certain decisions can be guided by predefined conditions, while others require human judgment. Not every release can be undone through a rollout control, and some failures may necessitate manual intervention or a new deployment. The goal is to make the appropriate adjustments based on observable production evidence, ensuring that risk is managed effectively throughout the software delivery process.