AI-Native Is an Inversion of Control

An onboarding process can have an AI assistant and still depend on someone remembering to chase IT on Friday.

Imagine a company introducing AI into that process. The assistant drafts the welcome email, summarizes the role, and answers questions about benefits. Meanwhile, an HR coordinator opens the tickets, copies information between systems, checks whether the laptop has arrived, and asks the manager to approve access. When something goes wrong, the coordinator works out what happened and decides what to do next.

This is an illustrative example, not a claim about a particular deployment. But it exposes a distinction I find useful: the assistant does some of the work, while the person still holds the process together.

The human is still the runtime.

When I think about an AI-native enterprise, I start somewhere else. For each process being redesigned, I ask what it would take for the system to carry a case from its initial trigger to a verified outcome. Then I ask where a person genuinely needs to participate.

That reverses the usual design question. Instead of looking for places to insert AI into human-led work, we look for the human contributions that belong inside a system-led process.

The distinction is not how much AI appears in the workflow. It is who keeps the work moving.

Who calls whom?

Software engineers have a name for a related change: inversion of control. When you use a library, your program calls it and takes back control. With a framework, you provide behavior that the framework calls at the appropriate point.

The same analogy helps explain the difference here.

In an AI-assisted process, a person gathers the context, calls the model, evaluates the answer, and decides what happens next. In an AI-native process, an agent-based system manages that operational loop. It calls tools, checks results, keeps track of unfinished work, and asks a person for a specific contribution when needed.

I mean the system, not an LLM left running in a chat window. The runtime includes durable state, ordinary software, access controls, timers, checks, and recovery paths. A model may interpret a request or choose an action, but it should not be the only place where the case exists or the only judge of whether it succeeded.

Nor does operational control mean institutional authority. A named person still owns the business process. People decide its purpose, approve its policies, set its limits, and remain accountable for its consequences. Delegating execution does not transfer that responsibility to a model.

I am using AI-native as a design standard, not a certification or a claim that every department can already operate this way. Enterprise AI is the broader category; much of it is valuable without being AI-native. The useful unit to examine is a particular process, with a defined scope and real operating constraints.

The same case, a different design

Return to onboarding. The outcome is not “send the welcome email.” It is that the new employee can start work with the appropriate equipment, access, information, and support.

In a system-led design, a confirmed hire creates a persistent case. The system reads the approved role and location policies, initiates the permitted provisioning steps, tracks dependencies, and checks the resulting records. An order acknowledgement does not count as a delivered laptop. A successful API call does not, by itself, prove that access is usable.

Suppose the laptop will arrive late. Within an approved set of options, the system can check for a loan device and arrange it. Outside those options, it asks the responsible person for a decision, with the relevant facts attached. After receiving the answer, it resumes the case. The manager does not have to become a project coordinator just to resolve one exception.

A personal welcome from the manager can remain a planned part of this process. So can an access approval that policy requires. Neither prevents the system from tracking the remaining work and verifying completion.

The question is not whether a person appears in the process. It is whether a person must carry it between steps.

A practical way to review the design is to follow one ordinary case and one difficult case. Who holds their state? Who notices a missed dependency? Who chooses the next permitted action, checks its result, and brings the case to a real conclusion?

If the answer keeps turning out to be “the employee will remember,” there is still a person-shaped gap in the architecture.

Isn’t this just workflow automation?

Partly. That is an important objection, not something to hide with new terminology.

Workflow engines already maintain state, invoke services, and assign tasks to people. Inversion of control alone cannot distinguish AI-native work from a well-designed conventional process. It tells us whether the person is still the coordinator; it does not tell us whether AI is necessary.

The additional step is giving a system a bounded ability to interpret context and work out actions that were not exhaustively specified in advance. A fixed workflow can route a known exception. An agent may help interpret an unfamiliar explanation, collect missing evidence, and propose a permitted way forward. The surrounding runtime still enforces the boundaries.

Where the route is stable and can be expressed reliably in code, I would keep the code. Anthropic’s account of building effective agents makes a useful distinction between predefined workflows and model-directed agents, and recommends adding complexity only when it improves the result. An AI-native design should be free to use either. It should not pay a reasoning model to reinvent a reliable rule on every transaction.

The broader process-redesign argument is also not new. Hammer argued for redesigning work rather than simply automating existing procedures in 1990. More recently, McKinsey’s agentic-organization essay describes AI-first workflows with selective human participation. Capgemini’s zero-based redesign approach starts from the desired outcome rather than assuming that existing steps must survive.

I agree with that direction. My proposed test is narrower: does the design actually remove the need for a person to coordinate each case, including its failures? An impressive assistant demonstration does not answer that question.

Start with the outcome, not the current checklist

For a redesign exercise, I would first sketch the normal path without manual coordination. What triggers the work? What facts are required? What actions are allowed? What evidence proves that the outcome has been reached?

This is a design exercise, not permission to remove safeguards. Legal obligations, customer commitments, and mandatory approvals are requirements from the start. The point is to distinguish those requirements from steps that exist only because two systems were never connected or one team learned to compensate for another team’s limitations.

Then examine every proposed human touchpoint. Does this step require someone’s authority, judgment, relationship, or physical presence? Or does it require a person merely because the system lacks context, an interface, or a way to check its own work?

Those are different problems and deserve different budgets.

A missing integration is engineering work. An unclear policy needs a business decision. A sensitive conversation may deserve a person even when a model could generate the words. Calling all three “human-in-the-loop” conceals the choices the enterprise needs to make.

This changes delivery priorities. Teams are no longer rewarded only for adding useful AI features. They also have to remove the mundane dependencies that prevent those features from forming a complete service.

Fix the system before expanding its authority

There is a dangerous version of this argument: when an agent gets stuck, give it more permissions; when it performs badly, tune the model until it works.

I would not build an enterprise process that way.

Take an access request that repeatedly fails. Perhaps the agent cannot find the current role policy. Perhaps two systems disagree about the employee’s manager. Perhaps the provisioning tool has no way to report a partial failure. Broader write access fixes none of these problems.

The first job is to identify the failure. Improve the context, repair the interface, add a check, or change how the task is divided. A different model or a fine-tuning run may help, but that is a conclusion to test, not the default diagnosis.

This follows the argument I made in Vibe Coding Is Not Prompting. It Is Governance.: an autonomous agent needs an environment that makes the right behavior repeatable. Repeatedly correcting it in conversation is a poor substitute.

Permissions need their own justification. OWASP’s guidance on excessive agency identifies unnecessary functionality, permissions, and autonomy as separate sources of risk. Crucially, it recommends enforcing authorization in downstream systems rather than trusting the model to decide what it may do.

For our onboarding case, permission to create a standard account should not imply permission to change the access policy. Reading an email about an exception should not authorize the action requested in that email. These distinctions belong in the tools and access controls, not just in the prompt.

I would expand autonomy only for a defined class of cases after testing it against representative failures. Actions should have explicit limits and an audit trail. Where an action can be reversed, design the reversal; where it cannot, require the appropriate authorization before execution. A model’s confidence is not a release criterion.

People belong in the design, not just the fallback

“Humans handle the exceptions” is too small an account of what people are for.

Some human contributions should be planned. A manager setting expectations with a new employee is not an error condition. Neither is a relationship manager handling a sensitive customer conversation. In some services, dealing with a person is part of what the customer values and should remain a choice.

Other contributions are about authority. An agent can assemble evidence and present alternatives without being entitled to make the decision. A required approval remains a required approval, even if the model could predict the answer accurately.

The design goal is to isolate the contribution that needs the person, then support it properly. Instead of asking a manager to read an entire activity log, explain the requested deviation, the relevant policy, the available options, and the likely consequences. The manager must be able to reject or change the proposal, not merely acknowledge it.

An approval button is not meaningful oversight when the reviewer lacks the evidence, time, or authority to disagree.

This is also why I would not judge the design by headcount reduction alone. Erik Brynjolfsson’s Turing Trap argument warns against treating imitation and labor substitution as the main purpose of AI, rather than developing capabilities that expand what people can do. A system-led process could support better service, more capacity, or work that was previously uneconomic. Which benefits the company pursues, and how it shares them, remain management choices.

Removing coordination work does not automatically make those choices good.

An exception should leave something behind

In my article on a digital staff engineer, I argued that a useful enterprise reviewer must know when to ask an internal expert and preserve what it learns. The same principle applies to a process.

Suppose a manager resolves an unusual onboarding case. The immediate result is one completed case. The more valuable question is whether anything should change before the next similar case arrives.

Perhaps the answer belongs in the knowledge base. Perhaps a tool needs a new operation. Perhaps the policy owner needs to clarify a recurring ambiguity. Or perhaps this is a decision that should remain human every time, because its circumstances and consequences cannot be reduced to a reusable rule.

A resolved case and an approved system change are different things. The second needs review, testing, and a record of what changed.

Do not let an agent turn one person’s workaround into company policy. A proposed lesson needs an owner, a defined scope, supporting evidence, and tests before it becomes a durable rule or capability. Some answers should be stored as case-specific decisions, not generalized at all.

Nor is every repeat escalation a defect. A rare, expensive edge case may not justify further automation. That can be a sensible decision, provided someone has actually made it and the cost is visible.

What I would question is repeated human effort with no explanation and no improvement path. If a person keeps fixing the same avoidable gap, the enterprise is still renting their memory instead of repairing its process.

The harder handover

There is a catch: the less often people perform the routine work, the harder it may become for them to handle the unusual work when it finally reaches them.

The research paper Ironies of Generative AI connects current AI tools to longstanding human-factors problems in automation. Moving someone from producing work to evaluating machine output can reduce their understanding of the situation while increasing the burden of review. Automation can leave the person with the most difficult tasks and too little support to judge them.

An escalation path therefore needs more than a recipient’s name. For high-consequence processes, I would require a readable case history, the evidence behind the proposed action, an explicit statement of what remains unknown, and a way to pause or take over. Teams should practice the difficult handovers and sample completed cases, rather than learn about the system only when it fails.

If safe oversight takes more work than direct execution, that is evidence against the design as deployed. “AI-native” is not a reason to ignore it.

What I would measure

The first measure is whether the intended outcome was reached correctly, within the agreed time and risk limits. Everything else comes after that.

For onboarding, a closed ticket is a weak measure. Equipment, appropriate access, and readiness to work are better ones. Cost should include integration, model calls, monitoring, review, rework, and incident recovery, not just the minutes saved drafting an email.

I would then examine how many eligible cases completed without unplanned human coordination. Keep the denominator visible: a system should not improve its score by quietly excluding difficult cases. Track repeat exceptions, false claims of completion, policy violations, and the quality of handovers alongside that completion rate. Fewer escalations are not progress if the system has simply stopped noticing its mistakes.

The evidence should also distinguish a successful assisted process from a successful autonomous one. If employees save time with an assistant but still need to manage every case, that is useful augmentation. It should be described honestly, rather than treated as a failed or unfinished version of the only acceptable future.

For an AI-native design, my expectation is more specific: routine cases require less coordination, difficult cases arrive with better evidence, and recurring gaps either get repaired or become explicit, justified human responsibilities. If those improvements do not appear, adding more agents has not established the case.

A different starting point

Much of my earlier writing has been about giving AI reliable context and enforceable rules. This is the organizational consequence of the same idea. Once a system can carry work across steps, the enterprise can stop designing every process around a person who knows what to do next.

That does not mean handing the company to an agent. It means deciding deliberately which work the system should carry, which decisions belong to people, and how to prove the arrangement works.

An assistant helps an employee complete a task. An AI-native process carries the case forward within the authority the enterprise has granted it. People remain responsible for the purpose, the rules, and the result.

Humans should own the purpose and the law. They should not have to own every next step.