All posts

Grant Agent Autonomy One Class of Work at a Time

Agent autonomy belongs to a class of work, not to a team. How to write an operating domain: eligible work, permissions, independent checks, and fallback.

Misha Druzhinin
Diagram of an agent operating domain: incoming changes pass an eligibility gate, then independent verification, then release or fallback, with ineligible work routed to a human path.

“How autonomous are your agents?” is a question with no useful answer. The same team can safely let an agent ship a dependency bump end to end while needing two humans on a payments change. Autonomy is a property of a class of work, not of a team, a tool, or a model.

Itamar Friedman makes this point in The Path to L4 Software Engineering (LinkedIn, October 22, 2026). He proposes six levels, modeled on the SAE levels for self-driving cars and building on Dan Shapiro’s five levels. He says they apply per workflow and domain. That last clause is the part we’d build on. The levels are a vocabulary. The operating domain is the artifact you can actually write this week.

Key Takeaways

  • Give autonomy to a named class of work, such as dependency bumps on internal services, not to “the team” or “the agent.”
  • Write an operating domain for each class: eligible work, required conditions, permitted actions, independent verification, and safe fallback.
  • Verification counts as independent only when the agent can’t edit the criteria. A second agent with the same context isn’t independence.
  • Design fallback before granting autonomy. Work you can’t roll back stays out of the domain.
  • Run each domain supervised first, and log every human intervention as a missing capability or a missing boundary.

What does “L4” mean for software engineering?

Friedman’s levels run from L0, human execution with ordinary automation, to L5, a “dark factory” he treats as broad and less practical. He’s explicit that this is his proposal, not an industry standard. The two levels that matter for most teams today are L3 and L4.

Level Who contains a failure What it looks like
L2 An engineer, in real time Agents do substantial tasks; a person supervises and connects results
L3 A person, as a required approval or recovery step The system runs a delivery workflow under defined conditions
L4 The system, inside a bounded class of changes Verification, permitted release actions, and safe fallback run without timely human help

Summarized from Friedman’s proposed levels, October 2026.

His one-line test for L4 is the clearest part of the piece: “L4 must contain failure inside its authorized domain before relying on human help.” Notice what it doesn’t say. It doesn’t say no human ever looks. It says the system doesn’t need a human to show up in time to stop damage.

This is a different axis from the five levels of AI SDLC maturity we published earlier this week. That model asks which artifacts carry work between sessions: chat, skills, spec-driven workflows, parallel agents, agent teams. Friedman’s model asks who contains a failure. You need both. A team can run agents at our Level 4 (parallel, isolated workspaces) while every workflow is still L2 in his terms. An engineer still catches every problem by hand.

Why autonomy belongs to a class of work, not a team

Risk varies by change type far more than by team. A lockfile bump on an internal tool and a schema migration on the billing database can sit in the same repository. The same agent can open both. Once they fail, they have nothing in common.

So a team-wide autonomy setting is always wrong for something. Set it high and the risky changes ship unwatched. Set it low and engineers rubber-stamp hundreds of trivial diffs, which is how real review attention gets spent on the wrong things. We covered the review side in reviewing AI-written code by risk. Operating domains are the same idea moved upstream: decide the risk class before the agent starts, not when the diff lands.

Friedman’s own example makes the split concrete. A team might target L4 for routine changes to an internal service and keep close human control over payment authorization. Same team, same week, different levels.

How to write an operating domain for agent work

An operating domain is a short document that defines one class of work the system may complete on its own. Friedman lists the parts: eligible work, required conditions, permitted actions, and safe fallback. Anything outside the domain takes another path. We’d add verification, an intervention log, and an owner, because that’s where domains fail in practice.

Here’s an illustrative example. It isn’t from a client or a real system; it shows the shape.

# agent-domains/dependency-patch.yaml  (illustrative)
domain: dependency-patch-updates
level: L3            # target L4 after the supervised period
eligible:
  repos: [internal-tools/*, platform/build-*]
  change_types: [patch and minor version bumps, lockfile regeneration]
  excluded: [auth, payments, crypto libraries, major versions]
conditions:
  - default branch CI green in the last 24h
  - changelog for the new version fetched and attached to the PR
permissions:
  can: [open branch, run CI, merge after checks pass, deploy to staging]
  cannot: [touch prod config, change CI files, edit tests, raise spend limits]
  token_budget_per_run: set by owner
verification:          # owned outside the agent's write scope
  - full test suite, run by CI the agent can't modify
  - smoke scenarios stored outside the repo
  - staging error rate compared to the previous release
fallback:
  - auto-revert merge if staging checks fail
  - stop rollout and page the domain owner if revert fails
interventions_log: agent-domains/dependency-patch.log.md
owner: platform-team

A few things make this work.

Eligibility is an allowlist. List the repositories and change types that qualify, then list the exclusions. Friedman points out that real requirements often live outside the ticket: architecture decisions, incident history, customer commitments. If eligibility depends on that context, the agent needs access to it. Our post on giving agents context from shipped work covers one way to provide it.

Permissions are narrower than the agent’s credentials. The domain says what the agent may do, and the environment enforces it. Stripe’s Minions run in devboxes that, in Stripe’s words, are “isolated from production resources and the internet” (Stripe, February 9, 2026). That isolation is why they can run without permission prompts. Keep credentials outside the agent’s reach, as we described in keeping agent credentials outside the sandbox.

The owner is a person or team. Domains drift. Someone has to approve expansions and read the intervention log.

What makes verification independent?

Verification is independent when the agent that wrote the change can’t change what “correct” means. Friedman puts it as protected criteria, separate authority, and checks grounded in observable behavior. He also warns that a second agent titled “reviewer” isn’t independence on its own, because two agents can share the same mistaken assumption.

StrongDM’s software factory is the strongest public example of taking this seriously. Its CTO, Justin McCarthy, writes that tests “can be reward hacked” when agents can see and change them (StrongDM, February 6, 2026). Their answer is end-to-end scenarios stored outside the codebase, so agents can’t edit them to pass. They also built behavioral clones of services like Okta, Jira, and Slack to run scenarios at volume.

The practical test is simple. For each check in the domain, ask: can the agent edit this? If the answer is yes, it’s a convenience check, not verification. That includes tests in the same repo, CI config the agent can touch, and an LLM judge prompted with the agent’s own plan.

Verification is also a system you have to evaluate. Friedman notes it needs calibration, like any other component. Treat your scenario set the way you’d treat evals for an AI agent: measure what it misses, not just what it passes.

Design the fallback before you grant autonomy

Fallback is what makes L4 different from L3. Friedman lists the usual moves: withhold the release, stop the rollout, disable a feature, or restore the prior version. He also notes that rollback isn’t always possible. A destructive migration can’t be undone by reverting a commit.

We’d turn that into an eligibility rule. If you can’t describe the automatic fallback for a change type, that change type isn’t in the domain yet. This rules out a lot, and that’s the point. Data migrations, external API contract changes, and anything that sends email to customers stay on the human path until you’ve built a way to contain them.

This also gives you a cleaner conversation with leadership. “We let agents ship” sounds like a risk appetite question. “Agents ship patch bumps to internal tools, with automatic revert on staging regression” is a design you can review.

What StrongDM and Stripe show about where to start

The two examples Friedman cites sit at different points, and both are instructive.

StrongDM states two rules: code must not be written by humans, and code must not be reviewed by humans. It’s tempting to copy the rules. But the rules are a consequence of their machinery: held-out scenarios, a probabilistic satisfaction metric, and digital twins of the third-party services they depend on. Without that machinery, “no human review” is just no review.

Stripe kept human review. Minions run unattended, typically from a Slack message to a pull request. CI runs selected tests from a battery of over three million, and each run gets “at most two rounds of CI.” Then a human reviews the PR. Stripe reports over 1,000 merged pull requests per week that are fully Minion-produced. By Friedman’s definitions, we’d call that a strong L3: the human is still a required approval step, by choice.

Our read: most teams should aim for Stripe’s shape first, with domains narrow enough that the review is fast. Then promote individual domains to L4 when the evidence supports it, not the whole pipeline at once.

How to promote a domain from supervised to autonomous

Promotion should run on evidence. Friedman suggests measuring the success rate on eligible work, the human effort still required, verification escapes, and the cost of failures. He’s explicit that agent count and lines generated aren’t measures of progress.

The most useful input is the intervention log. Run the domain supervised. Every time a human steps in, write one line: what happened, and whether it was a missing capability or a missing boundary.

  • Missing capability: the agent couldn’t find the changelog, or didn’t know the deploy order. Fix it with context, a tool, or a skill.
  • Missing boundary: the agent touched something it shouldn’t have, or took on work that was never eligible. Fix it by tightening the domain.

Friedman’s rule is that repeated human corrections should become rules, tests, or persistent context. The log is how you notice the repetition. When interventions become rare and verification escapes stay at zero for a period agreed with the owner, you have a case for L4. If you can’t replay what the agent did during an intervention, you can’t classify it; trace replay helps here.

One more caution. Supervised runs cost human attention, which is the scarcest input in agent work. We wrote about designing agent work around human attention. Keep the first domain small enough that reviewing it doesn’t swamp the person reading the log.

Should you build the factory or buy it?

Friedman’s answer is to buy specialized capabilities, such as review agents or context platforms, as building blocks. You design, integrate, and operate the system yourself. He runs Qodo, which sells AI code review, so weigh the “buy review agents” part accordingly. We still agree with the build-the-system half, and the operating domain is the reason. No vendor knows which of your change types are reversible, which repos carry customer commitments, or who owns the billing schema. That knowledge is the factory. The agents are interchangeable parts inside it.

Frequently asked questions

Is L4 the same as removing code review? No. L4 means the system can contain a failure without timely human help. A team can keep human review and still have the system revert a bad release on its own.

How many operating domains should a team start with? One. Pick a frequent, low-risk, reversible change type, write the domain, and run it supervised. Add the second only after the first one’s intervention log has settled.

Where should the domain file live? In the repository or a shared config repo, under version control, with an owner. Changes to a domain should get the same review as changes to CI.

The bottom line

Stop asking how autonomous your agents are. Ask which class of work they can complete, verify, and recover from without you. Write that down as an operating domain, with an allowlist, narrow permissions, checks the agent can’t edit, and a fallback you’ve tested. Then let the intervention log tell you when to widen it.

One thing to do this week: pick the most frequent agent-written change type in your last month of merged PRs. Write a one-page operating domain for it, using the fields in the example above. For each verification check, mark whether the agent can edit it. Every “yes” is your first fix.

Running agents but can’t say which work is safe to hand over? That’s the agent workflow cleanup we do with engineering teams.

Sources