From AI Assisted to Agent Owned

October 24, 2026 · By Aviv Zaken

An agent owns one of our production workflows. It plans the work, updates the code, reviews the changes, and runs the process. A person does not approve every change.

The interesting part is why we let it.

The workflow produces a recurring market analysis. It is useful, time-consuming to maintain, and sufficiently contained that a mistake does not have the same consequences as a mistake in our core product. That combination gave us somewhere to try a different ownership model.

We did not start by asking whether we trusted the model. We started by asking what we were willing to let this particular system get wrong.

That is a much more uncomfortable question. It also leads to a better engineering decision.

Review Capacity Is Already Making the Decision#

In Code Was Never the Bottleneck, I wrote about the work accumulating downstream of code generation. A team can generate changes faster without increasing its ability to understand them. The work waits for somebody who knows enough to say whether it should ship.

Under enough pressure, the review process changes. The queue gets longer. Reviewers read less carefully. Approvals become a way to unblock somebody else. The policy still says every change is reviewed, but the amount of judgment behind each approval is declining.

Faros’s April 2026 research compared organizations’ lowest- and highest-AI-adoption periods. Median time to first review increased 156.6%; median time in review increased 441.5%. Its later Speed Trap report, examining deeper use among high-adoption organizations, reported a 76.3% increase in PRs merged without review. That figure measures growth, not the percentage of all PRs that went unreviewed. Both reports are observational vendor research, so they do not establish that AI alone caused these changes.¹²

The point for an engineering leader is local. Look at what your team actually reviews, how long it waits, and what gets waved through when the release is late.

You may already be accepting unreviewed work. You just have not decided which work it should be.

What Exactly Does the Agent Own?#

“Agent-owned” can mean almost anything unless you separate the responsibilities.

In an assisted workflow, a person defines the task, the agent writes the code, and a person reviews the result. Most of the human decisions remain where they were. The implementation gets cheaper.

At the next level, a person approves work at explicit gates. Approve the plan, let the agent implement and test, then require a human decision before release. These are the checkpoints: the agent can move independently between them, but cannot decide to pass them itself.

In an agent-owned workflow, the agent can plan, implement, review, and run routine work inside an agreed scope. The human decision moves earlier, to the decision about that scope and its acceptable consequences.

This is where the connection to Code Review Is Risk Management matters. I argued there that the reviewer owns the decision to accept risk. Delegating execution does not transfer the company’s accountability to a model. Somebody still has to authorize the work, understand the exposure, and decide when the arrangement should stop.³

A person who approves every diff has many opportunities to intervene. A person who delegates a recurring class of changes has fewer. The delegation therefore needs a clearer boundary than “the agent seemed good at this last week.”

Classify the Consequences Before the Task#

Our framework starts with four questions: who gets hurt if the output is wrong, whether we can undo the damage, whether we would detect the mistake before it causes harm, and how critical the workflow is to the people depending on it.

Answer them about behavior, not about the name of the system.

Consider two hypothetical reporting jobs. One drafts a weekly analysis for an internal team. The other writes the same analysis directly into a customer-facing dashboard used to make spending decisions. The calculation could be identical. The permission to publish changes the risk.

Or consider recovery. Reverting a script restores the code. It does not retract a report somebody already used to make a decision. “It is in Git” answers only part of the reversibility question. You also need to know which outputs must be corrected, who received them, and whether the consequence can still be contained.

Detection deserves the same scrutiny. A failed request is easy to notice. A report that is complete, well-formatted, and confidently wrong may look healthy. If the first reliable signal comes from an angry customer, that belongs in the classification too.

These distinctions determine the ownership model. In our framework, mission-critical work keeps a person responsible for the plan and every change review. Middle-tier work uses explicit human gates. Low-criticality work can be a candidate for agent planning and review.

The classification is a starting point. A small maintenance task can cross into a more consequential dependency. Fixing a report parser and changing the shared permissions that parser relies on are different decisions, even when the agent needs both to finish its original assignment.

Make that distinction before implementation. Otherwise the last step of a supposedly routine task becomes an argument about authority, usually after somebody is already invested in shipping it.

The Work That Kept Returning to an Engineer#

Our case was market testing across AI engines and markets.

We help brands understand their visibility in AI-generated answers. The underlying engines behave differently across countries and change over time. Which sources they access, how citations are distributed, and how they use social content all affect the picture our teams need.

A person used to assemble that map every week. We had scripts. The problem was keeping the scripts useful while our own system evolved. Each change could create another maintenance task, and the workflow would return to an engineer.

The recurring expense included remembering how the analysis worked, figuring out what had changed, repairing the script, and getting the next run out. Automating execution had left much of the ownership with a person.

That made this a useful candidate. The job was recurring, its purpose was understandable, and maintaining the process was part of the work we wanted to delegate.

It also had a limited operational role. The reports reached our AI Strategists and internal teams before customers. Code changes were versioned and reversible. We did not consider this particular workflow mission critical.

Those conditions reduced the risk we were taking. They did not make every result correct. Internal readers provide an opportunity to catch a problem, not a guarantee that someone will catch it. The customer-facing use of the findings still matters.

The decision was to delegate this workflow under those conditions. It would not automatically apply to the same code with a different destination or a more consequential dependency.

A Team of Agents Still Needs a Way to Work With People#

We built the workflow around three roles.

The orchestrator plans and coordinates. The coder writes and updates the Python scripts. The reviewer receives the plan and the coder’s results, checks the work, and sends feedback. The coder and reviewer iterate inside a harness that passes tasks and results between them.

This gives us a process for maintaining the workflow, rather than a single prompt that produces a report. The agent team has the environment, tools, data, and goal it needs to do the job.

Initially, people shaped the plans and approved runs. We were operating at the checkpoint stage. Once the workflow worked, we asked what was missing for it to run without somebody starting every cycle.

Communication was a major part of the answer.

The orchestrator became our point of contact. It raises issues, alerts us to problems, and publishes findings. The process runs twice a week: a mid-week check for problems, then an end-of-week run for the statistics.

This changes the human role. Instead of initiating every routine run, people remain available when the workflow needs them. The agent also maintains the code that makes the next run possible.

But there is a limit worth stating clearly. A reviewer agent can check whether an implementation follows a plan while missing that the plan itself contains a bad assumption. Two agents agreeing is useful evidence only to the extent that their checks would actually expose the failure you care about.

Imagine a market-analysis job silently omitting failed requests. The report could look cleaner after the change. The code could pass its tests. A reviewer could agree that the implementation follows the plan. The missing evidence would be coverage: what was supposed to be analyzed, what was actually analyzed, and what disappeared between the two.

That is why I would distinguish review of the code from verification of the job. Successful execution, acceptable output, and permission to publish are separate things to establish. A convincing review summary cannot stand in for all three.

Write Down the Delegation Before Removing the Gate#

For a team adopting this approach, I would write a short delegation contract before removing human approval. This is a practical template, not a description of every control in our implementation.

For a recurring internal report, it might contain:

• Purpose: produce the agreed analysis for a defined internal audience. State which decisions it is intended to support.
• Allowed work: maintain the report’s own scripts and run the analysis using approved inputs. Specify which dependencies it may change.
• Human decisions: changes to the audience, underlying definitions, access permissions, shared services, or financial commitments require a person.
• Evidence: record the inputs, coverage, missing data, checks performed, and output version. Define which failures prevent publication.
• Escalation: stop when continuing would require crossing the boundary, weakening a check, or making an assumption that changes the meaning of the result.
• Recovery: name the person who can stop the workflow and decide what happens to previously produced outputs.

The details will differ by system. The point is to expose disagreements while there is still time to resolve them.

Take a provider quota failure. Retrying within an agreed limit may be routine. Dropping half the markets to finish on time changes the product. Buying more capacity creates a financial commitment. Switching providers may change the meaning of the comparison. One operational problem can lead to four very different decisions.

An instruction to “finish the report” does not resolve those decisions. In fact, it can encourage the wrong choice if completion is the only visible success criterion.

The boundary should also exist in the environment wherever practical. If the workflow has no reason to change a shared service, do not rely only on prose telling it not to. Narrow permissions reduce what an incorrect decision can do. The permissions need to enforce the boundary independently of the prompt.

A useful escalation should make the next human decision small. Which part failed? What was tried? What will be missing if we stop? What permission or judgment is required to continue? A message that merely says “please investigate” hands the ownership straight back.

Maintainability Can Change the Answer#

During the internal rehearsal for my Geektime talk, a colleague challenged the low-risk classification. What about over-engineering and poor maintainability? Shouldn’t somebody at least inspect the scope and the files being added?

It is a fair objection. A workflow can be unlikely to cause a production incident and still become expensive to own.

Suppose an agent keeps restoring a report by adding another adapter, exception, or copy of an existing transformation. Each change may be locally reasonable. Over time, the path from input to result becomes harder to reconstruct. The workflow continues to run, but taking it over becomes a project.

In Technical Debt Is a Tool, I wrote about how uncertainty makes engineers reluctant to change a system. Agent ownership does not remove that cost. It may postpone the point at which a person has to confront it.⁴

That does not mean every internal script deserves the architecture of a core service. Some workflows are cheap enough to replace. A complicated implementation can be an acceptable trade if its lifetime is short and rebuilding it is genuinely inexpensive.

The dangerous part is assuming replaceability without checking it. Ask what would have to be reconstructed if this workflow disappeared tomorrow. Its code? Its undocumented definitions? The history used to compare this week’s results with last week’s? The people who quietly built their own process around its output?

For this kind of work, a periodic high-level review may be more useful than approving each routine diff. Look at dependency growth, duplicated logic, changing assumptions, and the cost of taking over. That would manage a different risk from checking each change.

There is a real cost either way. Inspect too much and you recreate the manual job with additional orchestration overhead. Inspect too little and you may save routine maintenance now while accumulating a larger recovery bill later.

Ownership Has to Be Reversible Too#

Treating agent ownership as a graduation ceremony makes it hard to reverse. Once a team has announced that a workflow runs autonomously, bringing a human gate back can feel like failure.

It should be a normal operational decision.

I would revisit the arrangement when the audience changes, when the workflow starts touching shared state, when a human repeatedly has to correct its conclusions, or when the same failure produces another workaround instead of a repair. A change in the provider, model, or data contract is also a reason to check that the evidence still supports the permission.

These are different reasons to intervene. A newly important consumer may change the risk even if the agent’s performance has not deteriorated. Repeated corrections may reveal that the original acceptance criteria were incomplete. Growing dependencies may make recovery harder. The response should match the reason: narrow the scope, restore a checkpoint, improve the checks, or redesign the workflow.

Measure the result accordingly. PR count is a poor substitute for useful ownership. So is the number of scheduled runs that completed.

For a report-producing workflow, I would track whether it delivered when needed, whether its coverage was sufficient, how often people had to correct or rerun it, and how much human time went into intervention and maintenance. Compare that with the actual human-operated process, including its omissions and delays.

The economics need the whole bill. Time removed from routine execution must exceed time spent on exceptions, verification, recovery, and keeping the agent environment working. A workflow that saves an hour every week but regularly requires a day of investigation may still be worthwhile, but you should make that trade with the numbers in front of you.

Closing#

The first candidate should be a recurring job whose output matters enough to maintain, but whose failure you can afford to contain. Start with people involved. Learn what requires judgment. Then decide which decisions can happen without asking them again.

Our market-testing workflow gave us a place to make that decision concrete. Its value was in taking a recurring job off the team while keeping the consequences small enough to accept.

That is the work ahead for engineering leaders: decide where human attention changes the outcome, what evidence is enough to delegate, and what would cause you to take that delegation back.

Decide what your agents own, or your review queue will.

References and Further Reading#

Related: Code Was Never the Bottleneck