When an agent can write code, open pull requests and run tests, the tempting next step is to let it do more. Sometimes that is right. Sometimes it means a team has quietly handed real authority to a system nobody is checking. The fix is to tie the amount of freedom an agent gets to how well you can verify what it produces.

Agents produce work faster than people can comfortably inspect it. When the queue grows, the pressure is always the same: approve faster, check less, trust the green build.

That pressure does not announce itself. Nobody decides to stop reviewing. Reviews just get shorter, then become a glance, then become a click. The process still looks controlled on paper.

In my experience the risk is rarely one dramatic failure. It is a slow drift where the team believes it has oversight it no longer has.

Tip: Ask your reviewers, privately, how long they actually spend on an agent-authored change. If the honest answer is "seconds", your process has already moved up a rung without anyone deciding it should.

Once agents can complete more engineering tasks, the next question is how much freedom they should receive.

Allowing an agent to generate code is different from allowing it to modify critical systems, approve changes, or deploy software independently. The greater its authority, the greater the consequences of an incorrect decision.

A useful approach is to increase autonomy gradually through four stages.

Stage 1: Human involvement at every step

A person directs the agent, reviews its work, and approves each meaningful action. This is appropriate when a workflow is new, unfamiliar, or carries significant risk.

Stage 2: Bounded execution

The agent can perform tasks independently within clearly defined limits. For example, it might modify approved files, run tests, or prepare a pull request, while a person retains control over merging and deployment.

Stage 3: Human oversight for exceptions

The agent handles normal operations without requiring approval at every step. People become involved when predefined conditions occur, such as failed tests, unexpected changes, or security concerns.

Stage 4: Autonomous execution

The agent manages the workflow from beginning to end, calling for human intervention only when specific thresholds or exceptions are reached.

The important principle is that teams should not skip stages simply because an agent appears capable. Each increase in autonomy needs evidence from the previous stage.

For example, an agent that consistently generates correct documentation updates may eventually be allowed to publish them automatically. That does not mean the same agent should immediately receive permission to modify production infrastructure.

Autonomy must be matched to the reliability of the workflow and the ability to detect failures.

There must also be a clearly identified human accountable for each AI-enabled process. Delegating execution does not eliminate responsibility for the outcome.

One danger is creating checkpoints that exist only on paper. If a reviewer approves every change without meaningful inspection, the organization may believe it has human oversight when it actually has an automated approval habit.

A genuine control system requires people to understand what they are monitoring, which risks matter, and when intervention is necessary.

Tip: Define measurable success and accuracy thresholds before expanding an agent's permissions. Increase autonomy only after repeated evidence of reliable performance, and assign a specific person to remain accountable for the workflow.

The most dangerous rung is the one that looks like Stage 1 but behaves like Stage 4.

A person who is nominally in the loop but approves everything gives you the appearance of control without the benefit. It is arguably worse than no checkpoint at all, because it creates confidence exactly where the system needs scrutiny.

The way out is to be explicit about the difference between reviewing and monitoring. Reviewing means a person inspects each change before it lands. Monitoring means a person watches the overall behavior and outcomes and intervenes on signals. Both are legitimate. Pretending to do the first while actually doing the second is not.

Tip: For every agent workflow, write one sentence: "A human reviews each change" or "A human monitors outcomes and acts on these signals." If you cannot write it honestly, that is your finding.

Moving up should feel boring, because the data already made the decision.

Before you widen an agent's freedom, agree on what success looks like and how you will measure it. Example signals (examples, not targets):

That last one surprises people. An agent that pauses and asks when it is unsure is a good sign. It means the system is not trying to outrun its own evidence.

Tip: Write the promotion criteria before the trial starts, not after. If you set the bar once the results are in, you will be tempted to set it where the results happen to land.

Delegating execution does not delegate responsibility. Every agent-enabled workflow should have one named person who owns its outcomes, its rung, and the decision to move it up or down.

This matters most under time pressure. When a release is late, loosely defined oversight is the first thing to erode. A named owner with a written rung and written criteria is much harder to erode quietly.

It also works in reverse. If incidents or rework start climbing, the owner moves the workflow down a rung. Demotion is not a failure. It is the ladder doing its job.

Tip: Add an "owner" and "rung" column to wherever you track your agent workflows. Review it in the same meeting where you review incidents.

The biggest mistake is treating AI agents as another tool attached to an existing development process.

If a team simply inserts an agent into a workflow designed around human-paced coding, it may accelerate one step while making the surrounding process less efficient.

An AI-native engineering environment requires teams to reconsider how requirements are prepared, how agents receive context, how work is divided, and how completed changes are verified.

For example, an agent may struggle because the project documentation is outdated or because important architectural decisions exist only in the memory of one engineer. The agent's failure may appear to be a limitation of the model, when the actual problem is missing organizational knowledge.

Similarly, agents may complete tasks quickly but create conflicts if multiple teams are working on related components without clear ownership or coordination.

This is why engineering leaders need to look beyond individual productivity. They must understand how changes move across the organization and whether the surrounding systems can support the increased pace.

A useful starting point is to identify one workflow with frequent delays, improve its documentation and automated checks, and introduce agents within clearly defined boundaries. The team can then measure whether the entire process improves, not just how quickly code is generated.

The goal is to create a repeatable operating model that can expand as the team's experience and confidence grow.

Tip: Start with one real engineering workflow rather than introducing agents everywhere at once. Measure delivery time, review delays, defect rates, rework, and deployment outcomes before expanding the approach.

Trust in AI agents should be built the same way we build trust in people: in small steps, on real evidence, with someone accountable for the result. The teams that move fastest over time will not be the ones that hand out the most autonomy. They will be the ones that can prove, at every rung, that the autonomy they gave was earned.

Hit reply and tell me: which of your agent workflows is on a higher rung than it has earned, and what would bring it back down? I read every answer.

Keep going, one small spark at a time.

Erwin