Capability Is Not Authority: Who Decides What AI Agents May Do?

AI agents are getting better at doing the work. But who decides what they're allowed to do?

Where the engineering effort moved

Working with OpenAI Codex across complex, multi-service systems has changed where I spend my engineering effort. Less of it goes into typing the implementation. More of it goes into four things:

• Defining boundaries: what a task may touch, and what it may not.
• Delegating implementation: handing a well-specified task to an agent.
• Evaluating evidence: deciding whether the result is actually demonstrated, not just claimed.
• Deciding where human approval is necessary.

A release workflow made the shift tangible

An agent could prepare changes and support technical verification. Yet some verification remained incomplete. The release status had to preserve that uncertainty, instead of rounding it up to “ready”, and advancing the changes required explicit approval.

Capability and authority are two different things

That distinction matters more as we move from assistance inside an IDE toward autonomous, platform-managed workflows. Inside an IDE, a person approves almost every step implicitly. In a platform-managed workflow, nobody is watching each step, so authority has to be explicit.

Three execution paths

I see three kinds of execution path in an agentic delivery workflow:

Probabilistic paths

This is where agents add the most: reading an ambiguous requirement, trying alternatives, tracing a failure through logs. The output varies from run to run, which is fine for exploration and not fine for enforcement.

Deterministic paths

Pipelines run defined checks. Policy controls enforce permissions, quality gates and release approvals. The same input gives the same decision every time, whatever the model believes.

Hybrid paths

Agent reasoning and deterministic checkpoints form a controlled feedback loop. This is where most real delivery work sits.

The hybrid loop, with a budget

In a hybrid path, an agent proposes a change, CI evaluates it, and failure signals guide the next correction. A bounded retry budget limits the loop, and unresolved failures require escalation.

Written as policy, the idea is small. The syntax below is illustrative, not a specific product's:

# Illustrative policy: limits live outside the model
agent_loop:
  max_attempts: 3
  on_exhausted: escalate_to_owner
release:
  requires: [ci_passed, security_gates_passed, human_approval]
  agent_may_approve: false

Toward an Agentic Development Platform

This is the direction I see for an Agentic Development Platform (ADP): extending existing Internal Developer Platforms and Golden Paths to support agents as first-class consumers. The architecture needs a clear separation of responsibilities.

The agent harness provides context, tools and execution capabilities, ideally within isolated environments. I wrote more about it in AI Agents Can Write Production Code. Can They Prove It Works?

The governance plane manages non-human identities and enforces scoped permissions, quality and security gates, and approval boundaries independently of model reasoning.

Measuring success: engineering throughput

At scale, the measure of success is engineering throughput: independent tasks progressing concurrently and meeting defined acceptance criteria, with traceable decisions and controlled access. Not lines of code, and not the number of agents running.

More parallel work needs clearer authority boundaries.

For me, AI-native engineering increasingly means designing the systems that govern execution, alongside the software being delivered.

Which actions in your workflow should always require explicit human approval? Join the discussion on LinkedIn, or see how I approach agent-based systems.

Quick answers

• AI-Native Engineering
• Agentic Development
• Platform Engineering
• Governance
• Human Approval
• Codex