Stop Managing AI Agents Like Employees

As AI coding agents become more capable, we’ve started borrowing a strange organizational metaphor.

We talk about AI “workers.” We build “multi-agent organizations.” We give agents titles like developer, reviewer, security engineer, and manager.

Then, having invented a synthetic workforce, we start asking management questions about it:

What’s our AI adoption rate?

How many agents are our engineers using?

How do we supervise them?

Which roles will they replace?

Who is accountable when an agent makes a mistake?

I think most of these questions start from the wrong abstraction.

AI agents can perform work. Increasingly, they can perform a remarkable amount of work.

That does not make them employees.

And it certainly does not make them accountable.

Doing work is not the same as owning responsibility

Imagine an engineer using an AI agent to implement a feature.

The agent writes most of the code. A second agent reviews it. A third performs a security review. The first agent fixes the findings. Tests pass, the pull request is ready, and the engineer decides to merge it.

Who delivered the feature?

The human engineer did.

That answer doesn’t depend on whether the engineer personally typed 90% of the code or 10%.

We already understand this with other engineering tools. A developer does not become less accountable because a compiler generated machine code, an IDE performed a refactor, or a library provided most of an implementation.

AI makes the distinction feel less obvious because agents increasingly resemble human collaborators. They reason, write code, critique designs, use tools, and can carry a task for hours.

But resemblance to human work does not create organizational responsibility.

An AI agent cannot meaningfully accept business risk, own a production incident, answer to a customer, or decide that a tradeoff was justified and then bear the consequences.

A human can.

That difference should remain visible in the architecture.

The wrong abstraction

This is the distinction we’ve been deliberately designing into OpenOrc.

Wrong abstraction

Company
├── Human developer
├── AI developer
├── AI reviewer
└── AI security engineer


OpenOrc's abstraction

Company
└── Human engineer
    ├── responsibility
    └── OpenOrc
        ├── Producer
        ├── Reviewer
        └── Security Advisor

OpenOrc can coordinate several AI roles. They can have separate contexts, disagree with one another, review each other’s work, and produce a detailed record of what happened.

But those agents sit inside the engineer’s working system.

They do not sit beside the engineer in the company’s accountability structure.

That distinction sounds small. I think it matters enormously.

“Human in the loop” is too weak

A lot of AI governance discussion stops at keeping a “human in the loop.”

That makes the human sound like somebody who occasionally clicks Approve while the autonomous system does the real work.

OpenOrc takes a stronger position.

The human is the accountable authority.

The Producer can propose a plan.

The Reviewer can reject it.

The Producer can implement it.

A Security Advisor can identify a vulnerability.

The Producer can remediate it.

But consequential decisions still terminate at the human: authorize the work, accept the tradeoff, publish the engineering artifact, merge the change.

More agents do not mean more authorities.

They mean more capability available to the person who remains responsible for the result.

Management gets a much simpler question

Once you adopt that model, several popular management questions become much less interesting.

Take:

“What’s our AI adoption rate?”

Why should that be a primary engineering KPI?

If one engineer uses six agents and another uses one, but both produce excellent work at an appropriate cost and pace, what exactly did the adoption number tell us?

AI usage is an input.

The outcome is engineering work.

The useful questions remain suspiciously traditional:

What did the engineer deliver?

How long did it take?

Was it correct?

Was it secure?

How much did it cost?

How maintainable is it?

What happened in production?

And perhaps the most interesting one:

How much can this engineer responsibly own now?

AI may allow one engineer to own a much larger surface than before. Teams may get smaller. Roles may broaden. Some categories of work may disappear.

Those are real organizational changes.

They still don’t require putting the tools on the org chart.

“Who gets replaced by AI?” is probably the wrong unit of analysis

The same problem appears in the inevitable question:

“Which engineers will AI replace?”

Perhaps some jobs will disappear. Pretending otherwise would be comforting but not especially useful.

But mapping one human role onto one synthetic replacement may still be the wrong way to think about the transition.

A better question is how much the scope of a human-owned role changes when that person gets dramatically more leverage.

A frontend engineer might once have needed several people around them to deliver a certain amount of work. With coding agents, automated review, security analysis, and specialist assistance, perhaps that engineer can now own a much larger part of the product.

The role changed.

The organization’s capacity changed.

The accountability did not move into the model.

GitHub should tell the same story

While building OpenOrc, this principle eventually forced a concrete architectural decision.

OpenOrc has rich internal provenance.

We want to know that the Producer proposed something, the Reviewer objected, a Security Advisor found a problem, the Producer remediated it, and the Owner authorized the result.

That information matters.

But GitHub is the durable engineering record.

If Alice’s OpenOrc workflow creates a pull request, GitHub should show Alice created the pull request.

If Bob merges a backend change through his OpenOrc workflow, GitHub should show Bob performed the merge.

Not OpenOrc[bot].

Not ProducerAgent.

Not SecurityReviewer-04.

That led us to a design principle I’ve become rather fond of:

OpenOrc records agent provenance. GitHub records human accountability.

Technically, this means separating two things that are easy to conflate.

The GitHub App installation answers:

Where may OpenOrc operate?

The human authorization answers:

Which person is OpenOrc acting on behalf of?

So Alice and Bob can work on the same repository, through the same GitHub App installation, while using completely separate OpenOrc accounts, Workspaces, agent runtimes, models, and review configurations.

Alice’s engineering actions remain Alice’s.

Bob’s remain Bob’s.

The synthetic committees behind them are implementation detail.

That feels much healthier than filling the repository history with bots and then asking which robot should be blamed when something goes wrong.

Companies should still govern AI tools

None of this means companies should stop caring which AI systems engineers use.

They may care deeply about whether a tool is approved to access proprietary source code, customer data, credentials, or production systems. They may impose rules around vendors, licensing, security, data residency, or spending.

That is ordinary tool governance.

The same company already decides which cloud providers, SaaS products, development environments, and security tools its engineers may use.

AI does not need a new organizational status to be governed.

A useful rule is:

Govern the tools. Hold the human accountable for the work.

The mistake is turning tool governance into synthetic workforce management.

Stop measuring synthetic headcount

Once the tools are approved, management should mostly stop caring how the engineer uses them.

How many agents did they run?

How busy were those agents?

Which model did the Reviewer use?

How often did the Producer fail?

How many review cycles did the task require?

Those can all be useful questions for the engineer.

OpenOrc should absolutely help the engineer understand agent cost, failures, review findings, runtime health, and whether their particular setup is actually making them more effective.

But those are operational details of the engineer’s toolchain.

Their manager should not need an agent-utilization dashboard any more than they need a dashboard showing how often the engineer invoked the compiler.

The management contract can remain almost embarrassingly simple:

Engineer A owns outcome X.

It needs to be delivered by Y.

It needs to stay within cost constraint Z.

It needs to satisfy the organization’s quality, security, and operational standards.

Then evaluate whether Engineer A delivered it.

That is the measurement.

If Alice can deliver the outcome safely in three days using eight agents, that is interesting because she delivered it in three days.

If Bob delivers an equivalent outcome using one agent, that is interesting because he delivered the outcome.

If Carol writes most of the code herself and gets the same result within the same constraints, nobody needs to stage an intervention because her AI adoption metric is falling behind the quarterly target.

Management should measure the human engineer’s output, just as it did before.

The tools underneath that engineer may become radically more powerful. They may become expensive enough that cost constraints change. They may allow the engineer to own considerably more work.

But the unit being managed is still the engineer.

Not their synthetic headcount.

The interesting question

AI agents may eventually give one engineer the productive capacity that once required several people.

That is a profound organizational change.

It may reshape team size, hiring, career paths, and the boundaries between engineering disciplines.

But we don’t need to pretend the software became an employee in order to capture that value.

Give agents more capability.

Give engineers better controls, better review, better evidence, and better visibility into what those agents are doing.

Let the agents argue among themselves if that produces better software.

Then keep responsibility where it belongs.

With a human.

The interesting question for engineering management isn’t:

“How many AI agents work here?”

It’s:

“What can each engineer responsibly own now?”