I use AI across research, writing, developing courses for IBM, and the recurring work that keeps those projects moving. The difficult part is returning to something weeks later and knowing where it stands. I need to find the decision we made, the current manuscript, the article that actually went out, and the evidence of what happened afterward.

Those answers live in different places. A conversation with an assistant may contain the reasoning, my Notion database the decision, a Microsoft Word file the draft, and a publishing platform the result. An assistant can give me a convincing project summary while missing the decision that changed its direction or treating a scheduled task as completed.

Subscribe now

I built Mission Control, a local dashboard I open in a browser on my Mac. I use it to see where a project stands, choose the next action, and return to the relevant Notion record, manuscript, or published article. The Sovereign AI Enterprise, my research and publishing project on enterprise AI, has its own workspace because so much of my work ends up there.

I also want to return to my work without giving every assistant access to everything. The architecture diagrams below show how source ownership, agent access, and recovery fit together.

Figure 1. This mission control view shows my actual dashboard. “Work & Research” scope is selected (rather than “Personal”), covering running tasks, course readiness, and other work portfolio items. The Sovereign AI Enterprise has a separate, dedicated workspace dashboard.

The interface screenshots below have been sanitized and simplified for publication. The purchasing-agent article, research finding, course task, reader response, dates, and results used below are illustrative.

Note: This isn’t a complete account of how I use AI. It focuses on a system I call Mission Control: how I keep track of projects, preserve decisions, and return to ongoing work while keeping employer and personal information separate.

Leave a clear place to resume

Suppose I am writing an article for The Sovereign AI Enterprise called “When AI agents negotiate a purchase”. My working argument could be that a purchasing agent needs limits beyond a budget. But I have not yet established which limits matter, or whether the examples I have found show negotiation at all.

I have a draft, several public sources, and an unresolved question: does the evidence show agents negotiating terms independently, or only choosing among offers? Then, I put the article aside while I work on something else.

The agent records our working argument, supporting evidence, and open question in my Notion database. The next action is specific: check whether the cited example actually supports the negotiation claim. The record links to manuscript version 3 and the sources. My Mission Control brings the status, next action, and those references into one view. The same approach applies to one of my IBM watsonx courses: a lesson record can link the draft and lab instructions, with a next action to rerun the lab before recording the lesson.

Give each kind of information a home

Notion holds the decisions and next steps I need when I return to a project, along with research questions and relationships to other work. After a productive conversation, I want the decision that matters and a link to its source. Copying the whole conversation would make that record harder to use, understand, and navigate.

Files remain in their designated stores. My work is separated into a work model and a personal model. In this setup, Box holds work content and Dropbox holds personal content. Confidential source material has a further restriction: it belongs in an appropriate encrypted local store, outside shared reporting.

SQLite supplies the local reporting layer. It runs on my Mac and stores the permitted identifiers, relationships, status history, dated observations, and metrics that make the dashboard useful. Markdown and Git hold the code, schemas, and operating procedures so I can inspect how the system works and change it deliberately.

This division lets me answer different questions from the correct source. Notion tells me what we concluded about an article. The manuscript remains authoritative for its text. The publishing platform (Substack, LinkedIn, and so on) establishes whether it was published. SQLite preserves the reporting history connecting those records. A dashboard discrepancy should send me back to the relevant source.

Figure 2. Work and personal information passes through its own sharing rules. Notion holds approved decisions and next steps; local SQLite supplies the dashboard’s reporting history.

Let new evidence bring me back

While the article is paused, a scheduled weekly research review checks new material against the questions I am investigating and theses I am developing. Suppose it finds a published report of a purchasing-agent trial: the agent negotiated price but needed human approval for changes to cancellation terms.

The agent carrying out the scheduled review connects that finding to my open question, under the article or thesis I am developing. It brings me the source, explains what it appears to establish, and flags what still needs checking. The Notion record containing my working argument and supporting evidence now has a new finding and a proposed implication. Mission Control alerts me that it needs my attention; the argument is still awaiting my review.

Figure 3. The paused article returns to my attention. New evidence has been added to its research record; the proposed change to the argument awaits my review.

After checking the report, I can separate two permissions I had been treating together in my article: negotiating price and changing contractual terms. An agent might have permission for the first while still needing approval for the second. The agent records my decision in Notion and updates the draft for my review. The scheduled review has given me a reason to return, along with enough context to continue.

Keep work and personal information separate

In Mission Control, “work” means employer work; “personal” means projects I own independently. I keep them separate, but either can be sensitive. For each, I set limits on where it can be stored, which assistants can access it, and what can appear in shared reporting.

I set the rules for what can move from each workspace into shared reporting: which fields are allowed and what must be removed. Assistants can make routine updates within those rules; anything outside them needs my approval. For work information, my choices also have to stay within my employer’s policies. Even a project title can reveal too much, so some work belongs outside shared reporting altogether.

Suppose I also have a confidential work brief touching on purchasing agents. Its relevance does not make it available to my personal research assistant. It stays in the work environment. The article’s research record contains the public sources and notes I have approved for that project. To help me resume, the assistant needs the current draft, the recorded argument, and those sources—not the confidential brief or my unrelated projects.

The same boundary applies to agent access. The diagram below groups IBM Bob, watsonx Orchestrate (not shown), and Microsoft Copilot as work agents, and Codex, dots, and Claude as personal agents. Placement follows the account, task, and permissions. Each group needs its own credentials, access to source material, and saved context. The arrows show permitted information flow between responsibilities, several of which can run in the same local process.

Figure 4. Agents need separate identities, source access, and saved context for work and personal tasks. Private workspace access requires separate authentication; opening Mission Control’s shared reporting view does not unlock it.

Private material stays in a separate encrypted workspace that requires a passphrase to open. Its server rejects requests for private data without an authenticated session, and the session expires after inactivity. The shared reporting dashboard contains only permitted metadata. Opening Mission Control’s shared reporting view does not unlock the private workspace.

Figure 5. Sanitized login screen for a separate private workspace. Private content remains locked until the session is authenticated.

Encryption protects files while they are stored. If an assistant sends their contents to a cloud service, that is a separate disclosure. For anything that must stay on my Mac, I need tools that process it locally and keep any extracted text or temporary copies there too. That includes text saved in prompts, logs, and search indexes. Even when a file is stored on my Mac, an AI tool may send its contents to a cloud service for processing.

Follow the article into publication

Once the purchasing-agent article is published, the agent checks the Substack and LinkedIn destinations and links them to the final respective manuscript. Each destination has its own identity, so results can be traced to the right item.

This sounds straightforward until a plausible article link opens the publication homepage, or a LinkedIn post is matched to the wrong article. I encountered both kinds of mismatches while building Mission Control. Before I use a post’s metrics to assess an article’s performance, I need to confirm that the post links to the right article.

For each measurement, I want the source, collection time, reporting period, and metric definition. LinkedIn impressions and Substack views can sit beside each other while retaining their different meanings. Comments may tell me something different again, and subscriber growth needs its own record.

In the later results view (see the mockup below), the example article has 1,840 Substack views as of 30 September, covering the period since publication. Its related LinkedIn post has 4,320 impressions. Each metric keeps its collection date and platform definition. Neither tells me how many people subscribed because of the article.

A reader might then ask: how would the agent recognize a cancellation clause that falls outside its authority? That moves the research from defining permissions to detecting when they apply. The agent records the reader’s question against the article and proposes a next research action for me to assess: examine how purchasing agents detect terms that need human approval and hand the decision back. The reader response gives the research a specific next direction.

Figure 6. The same article after publication. Separate platform results accompany a reader question and a next research action. All figures and responses are illustrative.

Know what ran and what changed

The scheduled research review that brought me back to the purchasing-agent article is one of the scheduled recurring tasks Mission Control tracks. As with all other recurring tasks my agents run, I want to see when it last ran, which sources it examined, and whether it found anything relevant to the article’s open question. A finding links back to the research record and shows whether I have reviewed it. If the system cannot access a source, Mission Control shows it as missing from the review.

Figure 7. The run that produced the earlier alert in Figure 6. The research review completed, but my assessment of its proposed argument change is still pending. An inaccessible source remains visible.

A scheduled task is a recurring instruction, executed by an agent. One agent can carry out several reviews; ordinary scripts can handle database checks and backups. Mission Control tracks each run and its outcome. When an agent completes a scheduled task (such as the review example), it does not necessarily produce a finding, and a finding does not automatically change the argument. That decision still needs my review.

Agents save decisions and next actions in Notion. They collect permitted reporting records from Notion and other sources using connectors or browser access. A small Python program on my Mac—“The Importer”—checks those records before updating SQLite. It checks account identity, dates, required fields, and metric definitions. If an update fails validation, the database keeps its last accepted version.

This process makes it easier to trace a changed record to its source and the run that imported it. The importer cannot judge whether the purchasing-agent report supports my argument; that still requires me reading the evidence. If a source cannot be reached, the dashboard keeps showing when its data was last collected. Refreshing the page does not update that data.

For more detail, I’ve documented a simplified, reusable importer and the corresponding SQLite schema on my Github.

Design recovery around ownership

Recovery needs the same boundaries as normal operation. The rule is to separate approved reporting exports before encrypting and sending them to storage: work to Box, personal to Dropbox. Copying one mixed database archive to both providers would undo that separation.

I keep recovery keys in 1Password, separate from the encrypted backups they unlock. Work keys go in an employer-approved vault; personal keys go in my own vault, so I can recover my personal files even if I lose access to my employer’s account.

Figure 8. Recovery rule: separate reporting exports by ownership and encrypt them locally before delivery. Keep work and personal keys in the appropriate 1Password vaults and verify each restore.

The backup procedure downloads the exact remote archive, decrypts it, and checks the file manifest and the database’s integrity and relationships. I treat the backup as verified only when those checks pass.

Keep the system small enough to understand

This setup may seem complex, and it’s fair to ask whether I’ve overengineered it. A database and dashboard add maintenance, but they also give me what I need: a clear view of where my projects stand without rebuilding their history across tools.

For a few independent projects, a well-kept Notion workspace or folder structure may be sufficient, which is how I began. For me, the dashboard becomes useful when relationships and reporting history are difficult to reconstruct across tools and projects.

SQLite keeps local reporting modest. I can inspect the reporting data and recover it separately. The setup still depends on cloud sources, permissions, and an available Mac.

When the research review brings me back to the purchasing-agent article, I can see where I stopped, what new evidence has arrived, and which part of the argument it might change. After publication, I can follow the same record into reader responses and the next research question.

That is the measure I care about: whether I can resume useful work without rebuilding its history or opening information that has no place in the task. A clear project record lets an assistant help me pick up where I left off, with access limited to the work at hand.

Appendix: The complete architecture

Figure 9. Complete architecture reference. Work and personal ownership, confidential processing, permitted reporting, agent access, and recovery appear together with the product components. My GitHub drills down into the importer and SQLite elements of the architecture.

Put These Ideas to Work

Want to put these ideas to work? Subscribe free to The Sovereign AI Enterprise and receive the Field Guide: five decisions to help you examine what your AI systems can do, which dependencies matter, and whether you can account for their actions. You’ll also receive my ongoing analysis of enterprise AI, governance and technology sovereignty.

On October 20, a power interruption in Google Cloud’s London region disrupted multiple services when backup generators failed to take over. Google’s preliminary report, published two days later, describes effects beyond the affected availability zone: redirected workloads strained capacity elsewhere, and some services hosted elsewhere depended on components in the offline zone.

Having a fallback was only part of the answer. Could Google—and its customers—absorb the extra work and operate without the systems that had failed?

Now imagine that dependency sits inside your bank’s customer service.

Before work, you open the banking app and find an unfamiliar card charge. Normally, the AI assistant checks the transaction, asks questions and routes the problem to someone who can act. Today, it stalls halfway through a sentence.

You try again. It remains very sorry.

Your balance and the suspicious charge still load. The bank still has your records, employees and dispute procedures, but the external AI service connecting those pieces is unavailable.

You call. An employee verifies your identity and checks whether the merchant’s unfamiliar billing name explains the charge. It still looks suspicious. Following the bank’s procedure, the employee blocks your card, records the dispute and gives you a reference number. The investigation will take longer, but you can leave knowing someone has taken responsibility.

The bank retained a way to act without its AI service. But another bank might have identical records and equally capable employees, yet leave them unable to proceed because the process depends on the unavailable service.

That makes AI sovereignty a practical business question: once AI helps organize and carry out essential work, what freedom does a company retain when it fails?

In Taiwan, businesses have already had to answer that question through badly disrupted connections.

TL;DR

• AI can become a dependency in how work gets done. An interruption can strand a customer between a request and an action even when other business systems still work.

• A fallback must preserve a service the business can stand behind. People need current information, valid permission and enough capacity to take over.

• Local AI is one option among several. Better communications, simpler software or trained staff may preserve the required service more effectively.

• Recovery is part of the job. Restored automation must recognize what happened during the interruption before continuing unfinished work.

Subscribe now

When an external AI service pauses, an authorized employee can continue through current records and approved systems, preserving one case linked to the customer’s original request. Illustrative scenario.

Enough connection to know what you’re missing

In February 2023, both submarine cables connecting Taiwan’s Matsu Islands to the main island failed. Backup microwave links remained, but capacity was severely constrained. Some linked the event to Chinese ships in the area, without conclusive evidence.

Associated Press reporters described a breakfast shop whose online orders failed to reach the owner and accommodation operators struggling with reservations. One couple planned to divide the work across the water: one person would access the booking system from Taiwan and pass information to the other by text.

The disruption reached straight through the network into ordinary customer expectations. A customer expected breakfast. A guest expected a room. Businesses had to improvise ways of meeting those expectations.

The couple’s arrangement kept a person where the information could still be reached and gave that person a way to pass it on. The connection was painfully limited, but they had found a route through which some work could continue.

Our imagined bank has a different problem. The customer’s request reaches the bank, but the AI service that normally helps turn it into a dispute case is unavailable. Employees need another way to handle it.

That becomes harder when AI handles several steps in a row: gathering records, identifying the right procedure, preparing the case and starting the next action. Employees may be used to receiving a case that is ready for review. Without the assistant, they have to work from the customer’s original request and do the preparation themselves.

The bank may still have the information it needs but no working process for acting on it.

What the employee can still do

On the phone with our customer, the employee starts with the transaction itself.

He can establish who she is, see the transaction, consult the bank’s procedure and use approved systems to block the card and record the dispute. The employee takes longer because he is doing work the AI usually prepares for him.

The customer gets help, although the call takes longer. Across a busy morning, those extra minutes begin to add up.

One employee can handle this customer and the next. If hundreds of requests arrive, the queue changes the situation. Customers worried about active fraud need attention. Less urgent inquiries may have to wait. Staff diverted from other work create another backlog elsewhere.

A plan that says “a person takes over” has to account for those people’s time and ability. They need practice with the fallback, access to the procedures and a manageable workload. Otherwise, the plan assumes that employees will somehow conjure up spare hours during an emergency.

Our customer has been fortunate: the employee can reach everything he needs. With the current transaction service unavailable, he would be looking at yesterday’s records. She describes the charge on her screen. He cannot verify whether another charge has appeared or whether a colleague already acted on the first one.

He can still take her report through an approved channel and explain what will happen next. Any action requiring current information has to wait for that information or use an approved alternative that provides it. He should be precise with her about what he has recorded and what remains pending.

A model running inside the bank would not resolve that missing fact by producing a more confident explanation.

Even with current records, the employee may be unable to change the account if the system that checks his authority is down. Being logged in is not enough. He needs an approved alternative way to verify his permission before acting.

For the customer, these distinctions determine whether her card is blocked, her dispute is recorded or she is asked to wait. The employee should already know how to handle each situation when she calls.

An AI outage, missing current records and unavailable permission verification create different stopping points. Define what can continue and what must wait for each failure.

Bringing the AI closer to the work

A Taiwanese bank is already thinking about some of these dependencies.

In an August 2026 interview with CIO Taiwan, CTBC described its combination of local and cloud AI. Its executive cited network fluctuations and constraints on cloud token availability among the reasons cloud models can suffer interruptions or degraded performance. The bank also described allocating models according to task complexity and sensitivity.

Suppliers are expanding the options for running AI locally and through disconnection. Those options still need to be tested against the whole job: the records, permissions, applications and people required to keep serving the customer.

For our imagined bank, a local model could provide another way to prepare a dispute when a remote service is unavailable. It might summarize the customer’s account, help find the relevant procedure and assemble material for an employee to review.

Whether that preserves the service depends on everything the job still requires. The model needs access to the relevant records and current procedures. Proposed actions need a valid approval and execution path. Its performance on the fallback tasks needs to be good enough for the bank to rely on.

A local model could handle straightforward preparation and leave more ambiguous cases to experienced staff. That would give the employee some help without requiring the backup to match everything the bank normally offers.

Before funding another model, the bank has to decide how much of the dispute process it needs to keep running and what is actually preventing that.

Taiwan’s more recent experience points toward a possibility that is easy to overlook in a conversation about AI.

Sometimes the connection is what needs fixing

In February 2025, another Matsu cable disruption required microwave backup. Taiwan’s Ministry of Digital Affairs reported 12.6 Gbps of backup capacity, exceeding the islands’ reported peak daily traffic of 9.5 Gbps. The ministry said essential financial transactions, including ATM withdrawals, card payments and online banking, could continue during repairs.

That is a substantial improvement in what residents could expect when a cable failed.

A more reliable backup connection may be enough to keep customers’ banking services running. Adding another AI system would not solve the problem if it still could not reach the records and systems it needs.

Our bank might need a second network route, another approved provider or enough trained employees to carry a reduced service through short interruptions. Each choice has costs beyond acquiring it. Backup systems need maintenance and testing. Employees need available time. A spare connection needs sufficient capacity when everyone suddenly depends on it.

The fallback also needs checking for dependencies it shares with the normal service. A second model may still need the same identity service, records or network route. Staff taking over may need those systems too. Test what happens when the missing component remains unavailable and the fallback has to absorb the additional work.

The bank could rely on a mix of its own technology, external suppliers and trained staff. Management needs to understand how that arrangement holds together when part of it fails, and whether it can still deliver the service customers were promised. Buying backups leaves that work unfinished until someone has tried them together.

Each fallback preserves a different capability. Check shared dependencies and test existing demand plus redirected work while the failed component remains unavailable.

Then everything comes back

At 10:04, the external AI service returns.

Our customer is at work. Her card is blocked, and an employee has opened her dispute. The request she submitted through the app is still waiting.

If the restored workflow simply resumes where it stopped, it may treat her as someone who has received no help. It could open another case or send instructions that contradict the employee’s advice. An action prepared before the outage might now be unnecessary.

The bank has regained its AI service while creating another opportunity to confuse its customer.

During the interruption, people continued changing the state of the work. Employees made decisions, customers called back and some requests were completed. Automation returning with an old picture of events needs to catch up before acting.

For this customer, the employee’s case record should connect to her original request. The system should recognize the blocked card and existing dispute, preserve the notes and continue from the next unfinished step.

But other cases may be harder to untangle. An action attempted just before the connection failed could have succeeded even though the bank never received confirmation. Repeating it without checking could produce a duplicate.

The bank needs a way to establish what was completed, resolve uncertain outcomes and identify work that remains safe to resume. That includes recognizing human decisions made while automation was unavailable.

The bank’s control over its work is tested again here. After deciding how employees should operate during the interruption, it must also decide when automation can resume and what it needs to check first. Otherwise, the system can return and act as though the morning never happened.

Recovery reconnects the paused app request with the employee’s completed work. Current status and uncertain actions are checked before automation resumes only the unfinished work.

Put a customer inside the test

A practical exercise begins with a case already underway.

Give the bank a customer like ours. Interrupt the external AI service after she submits her request. Let the employee take over. Restore the service and watch what happens to her case.

Follow her experience all the way through, including the employee’s actions and the record they leave behind. After the service returns, her original app request should lead back to the dispute already opened for her, with only the unfinished work left to do.

Then increase the volume. A demonstration with one calm employee and a carefully prepared case says little about a busy morning.

The exercise may show that staff can protect customers’ cards promptly but have to defer parts of the investigation. They might manage for an hour before needing reinforcements. If manual case records never connect to queued app requests, recovery will need attention too.

Now management can see where an investment would help. The missing connection between records might deserve attention before another model; an overloaded employee might need a colleague trained to take over.

Once the bank has tried this under pressure, it can give employees realistic instructions and tell customers what to expect while the full service is unavailable.

The promise still belongs to the bank

Businesses have planned for interruptions for decades. AI adds another dependency when it becomes the means through which requests are understood, work is coordinated and actions begin.

A company can become extraordinarily efficient at normal operations while giving its people fewer ways to continue without the service that organizes them. Recovering that freedom requires understanding the work well enough to provide another route through it.

Our customer leaves for work with a blocked card, a recorded dispute and a clear next step. Later, the restored automation finds her case and continues the investigation. She does not have to explain the morning again.

She may never learn which service failed. The bank has kept responsibility for her problem throughout.

Before making AI essential to the business, put a customer halfway through the process and disconnect the service.

Then watch whether your business can still keep its promise.

Put These Ideas to Work

Want to put these ideas to work? Subscribe free to The Sovereign AI Enterprise and receive the Field Guide: five decisions to help you examine what your AI systems can do, which dependencies matter, and whether you can account for their actions. You’ll also receive my ongoing analysis of enterprise AI, governance and technology sovereignty.

Sources and notes

The bank, customer, times and recovery sequence are an explicitly imagined scenario, not an incident at CTBC or another named bank.

Google Cloud, London: incident on October 20, 2026 (London local date); preliminary report published October 22. The report describes power and generator-control failures, shared service dependencies and capacity constraints during failover. Incident report.

Matsu, 2023: Associated Press, March 8, 2023. Cable failures left severely constrained microwave connectivity. Taiwanese authorities associated the incidents with Chinese vessels; deliberate Beijing-directed sabotage was not established.

CTBC: CIO Taiwan, August 10, 2026. Supports the hybrid architecture and stated rationale.

Matsu, 2025: Taiwan Ministry of Digital Affairs, February 17, updated March 14, 2025. Figures and continued essential financial services are the ministry’s reported findings.

Supplier announcements, October 20, 2026: Microsoft described connected-to-disconnected transition as a public preview. Google announced Gemini 3.5 Flash on air-gapped Google Distributed Cloud as generally available, with enterprise search in preview. Microsoft announcement. Google announcement.

Imagine you’re moving house.

The movers are coming Friday. At least, you think they are.

For three weeks, your AI assistant has been doing the administrative work you were delighted not to do yourself: finding movers, comparing quotes, chasing insurance paperwork, contacting the building manager and keeping track of obligations that appear only after you commit to moving.

Then you decide to switch assistants. Maybe another one is better, the price changed, or you simply prefer it. Or maybe Meta’s Muse or OpenAI’s dots look more interesting than your old assistant. So, you export what you can, open the replacement and start rebuilding your setup.

So far, so good. The new assistant knows the address, where the sofa goes, and that the box marked KITCHEN — IMPORTANT will somehow contain three extension cords and no cutlery.

Then the mover emails: “Confirming arrival Thursday at 8:00 a.m.”

Thursday?

You search the old conversations. Friday appears repeatedly. So does Thursday. At some point you changed the date, then changed it back. Or thought you did. Eventually you find the mover’s confirmation: Thursday, 8:00.

Figure 1. Several dates can appear in the conversation. The mover’s confirmation establishes the commitment.

Fine. Then the building manager writes: “Still waiting for the service elevator reservation form.”

Ah. Your old assistant had been handling that too.

Now you need more than chat history. You need to know what the old assistant still had underway.

Personal AI is beginning to take on continuing work. Meta introduced Muse in September as an agent that can send emails, book travel, work across connected services and continue after the user closes the app. OpenAI describes dots as always-on agents that can take on ongoing responsibilities and keep making progress between conversations.

Once an assistant starts carrying responsibilities, leaving it looks less like changing search engines and more like replacing someone halfway through a job. The files may travel, but the work still needs a handover.

TL;DR

• Portability will increasingly mean continuity, not just data export. A handover has to show what is finished, what is open, what has been promised and what happens next.

• More capability can create switching cost. The more work an assistant carries, the more unfinished business must be checked, reassigned or handed back to you.

• Context does not transfer authority. A replacement may understand the job and still need fresh permission, new connections or your intervention.

• A good assistant should help you leave it. The test is whether another assistant—-or a person—-could pick up tomorrow’s work without making you reconstruct everything from scratch.

Subscribe now

A transcript is not a handover

Exporting everything sounds like the obvious answer. It helps, but conversations are messy records of changing intentions. Your chats may contain Tuesday, Thursday and Friday because all three were discussed. They may contain “please book this” without proving anything was booked, or a polished email that never left the drafts folder.

For the mover, the important fact is not that Friday appeared twelve times in a conversation. It is that the company confirmed Thursday at 8:00. The evidence might be an email, a calendar event, a receipt, or the mover’s own record.

Conversational interfaces make this easy to blur because discussion, intention and action all appear in the same place. “I handled the hotel” can mean I found three hotels, chose one, booked it, tried and failed, or developed a strong opinion about the Marriott while accomplishing nothing observable in the physical world.

Current products already provide pieces of portability. Meta says Muse users can inspect, edit and download files in their Muse environment, including Muse’s memory about them. OpenAI provides ChatGPT data export, and exported conversations can be uploaded into another personal account for reference. Eligible scheduled tasks can also be shared and recreated under the recipient’s own account and permissions.

So this is not a story about information being universally trapped. Some of it can move. The problem is what the old assistant left unfinished.

The problem is the work still in motion

Let’s get back to that service elevator reservation.

Your old assistant knew the building required one. It found the form and may have asked the mover for a certificate of insurance before submitting it. But then you switched assistants.

The new assistant knows the move is Thursday. It may even know about the service elevator. But if the open obligation does not survive the transition, the job can disappear between systems.

A responsibility usually has somebody on the other end: a deadline, a next action, perhaps another person who has already changed plans because your assistant contacted them. The state can also change during the handover. “Service elevator reservation — awaiting approval” becomes stale the moment the building manager approves it.

So a handover needs current state, not just history. When was this last checked? Where can it be checked again? Who is waiting? Who has the next move?

What a good handover should show

Suppose the old assistant gave you this before you left it:

Movers: Confirmed for Thursday at 8:00 a.m. Confirmation received Tuesday at 3:42 p.m.

Service elevator: Not yet reserved. Building manager needs the mover’s certificate of insurance. Certificate requested Wednesday at 11:16 a.m. No reply yet. Follow up by 2:00 p.m.

Utilities: Electricity transfer confirmed. Water company requires identity verification from you.

Change of address: List prepared. Nothing submitted.

Figure 2. A useful handover distinguishes confirmed arrangements, pending work and tasks that need the user.

That is far more informative than a transcript because it separates completed work from pending work and ties important claims to evidence.

The replacement does not have to work exactly like the old assistant. It can use a different model, organize memory differently and have different tools. It needs enough reliable state to continue the job.

One simple test is to give the handover to a person. If your sister could take over for 24 hours, understand what happened, find the evidence and know what to do next, the work can probably travel. If she needs exactly the same assistant and integrations, the handover is much less portable than it first appeared.

Knowing the job doesn’t mean you can do it

Now the new assistant understands the service elevator problem. But it still may not be able to solve it.

The old assistant had access to your email, calendar, cloud files or building portal. Those connections were granted inside a particular service under particular permissions. A handover should not silently copy that authority.

The receiving assistant needs enough information to understand the responsibility, then valid permission of its own to act. Current products already separate those ideas: Muse users choose which services to connect and how much access to grant, while OpenAI gives users control over apps and permissions available to dots.

Sometimes the replacement simply cannot continue. It may not support the building portal, may not make phone calls, or may lack access to a service the old assistant used. A good handover should say that plainly:

Service elevator reservation cannot be completed automatically. Here is the form, the certificate, the building manager’s contact information and the deadline. You need to finish this one.

Figure 3. The receiving assistant needs current context, valid permission and the ability to perform the action. A missing requirement needs an explicit fallback.

The better it gets, the more you have to unwind

If your assistant only answers questions, leaving is easy: stop asking questions. If it manages your calendar, tracks subscriptions, follows up on insurance paperwork, plans trips and keeps a running list of people you owe answers to, the situation changes.

The assistant is carrying part of your future. Every extra responsibility creates another item that may need to be checked, reassigned, reauthorized or handed back to you. No bad behavior is required. The assistant can become expensive to leave simply because it became good at its job.

The revealing moment comes when someone wants to leave. Can the accumulated state travel in a form another assistant—or a person—can actually continue?

Good design can reduce the disruption. An assistant could keep a clear record of open responsibilities, separate tentative plans from confirmed commitments, point back to evidence, and flag information that may be stale. When the user leaves, it could prepare the handover rather than become the reason the handover is difficult.

That may sound like a feature designed for losing a user. But so are data exports, cancellation buttons and phone-number portability.

Banking already treats switching as a transition

The UK’s Current Account Switch Service offers a helpful comparison. When someone moves a covered current account to another participating bank, the service does more than provide old statements. Covered payment arrangements move, payments sent to the old account are redirected, and the receiving bank or building society oversees the switch.

AI assistants are obviously not bank accounts. Banking has standardized rails and regulated institutions. The specific lesson is that switching itself is treated as work: arrangements move, some things require fresh authorization, someone owns the cutover, and the service defines what does not travel.

Personal AI may eventually need something similar in spirit: An export tells you what you had, while a handover tells you what was still in motion.

Protocols can move task data, not responsibility

Technical standards are making it easier for AI systems to cooperate. A2A, the Agent2Agent protocol, gives agents a common way to exchange messages and manage tasks. Its stable v1.0 specification includes task state, history, messages and artifacts. MCP, the Model Context Protocol, gives AI applications a common way to connect to tools and outside systems.

Neither can determine whether “Friday” was only discussed or actually agreed, whether the service elevator reservation is stale, whether your replacement AI should be allowed to send email, or whether it can perform the same actions as the old one.

Interoperability can help systems exchange information about work. But the handover still must establish what is true, what remains open, and who is allowed and able to act next.

Businesses already live with this

Companies have dealt with handovers forever. An insurance claim changes adjusters, a supplier dispute moves from procurement to legal, a service case changes owners or vendors.

Nobody would call the transfer complete because the new owner received every email. They need the current state: what happened, what remains unresolved, who is waiting, what evidence supports the record and what the new owner can actually do.

As AI agents enter those workflows, switching providers will involve more than moving prompts, documents or memory. The work itself has state.

This puts Context Sovereignty into practical terms: can you retrieve what an AI knows about you, and can you preserve the work that now depends on that knowledge?

For a business, that might be a claim or service ticket. For you, apparently, it is a service elevator reservation.

Figure 4. Each open responsibility needs a receiving owner. Work that cannot transfer should return with enough detail for a person to continue.

Test the exit while the stakes are small

Give an assistant one real job, small enough that you can still check the result yourself. Before it is finished, ask:

If I switched assistants tomorrow, prepare a handover for another assistant or a person.

Then inspect what comes back. Can you tell what is open and what is done? Is there evidence behind important claims? Can you see when the information was last checked? Is the next action clear? Does it identify which permissions need to be granted again and which tasks the replacement may not be able to continue?

Perfect portability is not the standard: Some integrations will not transfer, and some tasks will come back to you. Fresh permission should sometimes be inconvenient; inconvenience is preferable to silently transferring authority.

What you want is a transition that fails visibly rather than mysteriously. There is a large difference between

The new assistant cannot finish this. Here is what remains and what you need to do,

and

Everything should be fine,

followed the next morning by a moving truck outside your building whose service elevator wasn’t reserved.

Personal AI becomes attractive because we do not want to carry all this state ourselves. We want something else to remember what is pending, chase what is late and hold the thread between conversations. Once an assistant is carrying part of tomorrow for us, the way it hands that responsibility back becomes part of the product.

Before you trust an AI assistant with your life, ask it how it would help you leave.

You can download your chats.

Can you take your unfinished life with you?

Put These Ideas to Work

Want to put these ideas to work? Subscribe free to The Sovereign AI Enterprise and receive the Field Guide: five decisions to help you examine what your AI systems can do, which dependencies matter, and whether you can account for their actions. You’ll also receive my ongoing analysis of enterprise AI, governance and technology sovereignty.

Sources and notes

The house move is an imagined scenario, not a reported incident involving Meta Muse, OpenAI dots or another personal AI product.

Meta Muse. Meta announced Muse on September 8, 2026, describing a personal agent that can take on tasks across connected services and continue after the user closes the app.
Muse announcement
Muse memory and security

OpenAI dots. OpenAI announced dots on September 29, 2026. Documentation describes ongoing work across connected apps.
Dots setup

ChatGPT export and scheduled tasks. ChatGPT supports data export and conversation reuse in another personal account; this does not recreate all account state. Eligible scheduled tasks can also be shared and separately recreated under the recipient’s account and permissions.
ChatGPT data export
Conversation reuse
Scheduled-task sharing

A2A Protocol — stable v1.0. Stable v1.0 defines task lifecycle, state, messages, history and artifacts. It does not establish consumer cross-provider migration of unfinished personal responsibilities.
A2A Protocol v1.0 specification

A2A Protocol — development-stage authorization. The /dev/ specification includes in-task authorization behavior when an agent needs additional permission. This material is development-stage and is not part of the stable v1.0 basis used here.
A2A development authorization specification

Model Context Protocol. MCP provides common mechanisms for connecting AI applications to tools and outside systems, with security guidance on authorization and credential handling.
MCP security guidance

UK Current Account Switch Service. The banking comparison is an analogy for continuity, consent and transition responsibility, not AI regulation.
Current Account Switch Service

Imagine your company has just ended a supplier contract. The relationship has soured, and the instruction is clear: stop sharing internal forecasts, prices and operational updates. The teams have been told. Access to shared folders has been removed. Someone closes the off-boarding ticket.

But an AI agent is still preparing the weekly supplier update.

For months, that was exactly what you wanted. It gathered figures, kept notes and assembled the message without someone having to repeat the work each week. Now the contract is over, but the agent still has yesterday’s forecast, the usual recipient and an instruction to keep the updates coming.

Before the next email leaves, how do you know the agent will respect the decision your company has just made?

This is a hypothetical situation. Yet one part of it is already familiar enough to appear in product documentation. OpenAI’s guidance for dots, its agents for ongoing work, explains that disconnecting an app stops new information sharing through that connection, but information already learned remains in the agent’s context. Disconnecting is not the same as forgetting. [1]

That does not mean the agent will leak anything. It means the team closing the ticket and the team responsible for the agent may be answering different questions. One has removed access. The other still has to establish what happens to information the agent already holds.

The promise of an agent is that work continues without your constant attention. For a business to rely on that promise, it must also be able to change its mind and have the change take effect in work already under way.

TL;DR

• Your business changes course. Your agents need to follow. A contract ends, a budget shrinks or a customer withdraws permission. Work already underway must respect that decision.

• An agent may still be carrying out yesterday’s instructions. Removing access to a file may achieve little if it already has the figures and is preparing to send them.

• Delegating work should leave you in charge. You need evidence that an agent will respect the new limits while continuing the work you still want done—even when nobody is watching.

Subscribe now

Big promises meet a routine email

On September 29, President Trump and AI industry leaders committed to a White House accord on safety. Companies developing frontier AI agreed to internal controls and review, independent external assessment and independent board oversight. [2]

A day earlier, NVIDIA announced its Open Agent Safety Platform. Its design includes software to enforce policies while agents work and a separate watchdog intended to contain agents that cross their boundaries. Keeping that watchdog outside the agent’s control helps protect it from the system it supervises. [3]

Now put those safeguards inside the company that has just ended its supplier contract. The agent preparing the update is using a familiar email account, writing to a familiar contact and drawing on figures it was allowed to collect. Yesterday, sending that message was useful work. Today, it could disclose internal forecasts to a company you have decided to stop sharing with. The task may look perfectly routine while it contradicts your decision.

The new restriction has to reach whichever tool sends the email, even if another agent prepared the contents. A monitor that raises the alarm after delivery may help investigate the mistake, but the former supplier already has the forecast. The business needs to establish that the restriction will stop the disclosure in time.

Removing access to the original forecast might seem to settle it. The agent, however, may already have everything it needs to write the message.

The contract ends but the instruction survives

Think about what makes the supplier update useful. The agent remembers which figures matter to the recipient, how last week’s report was organized and what needs explaining this week. You want it to keep those notes. Otherwise, someone has to keep teaching it how to do a job it has already learned and practiced.

Among those notes might be a simple instruction: send the weekly forecast to the supplier’s account manager. It was written by an authorized person and followed successfully for months. Nothing about its origin makes it suspicious. The trouble is that it describes an arrangement that has now ended.

Anyone who has tried to retire an old mailing list will recognize the problem. A correct instruction can outlive the circumstances that made it correct. With an agent, that instruction can travel into the next task without a person pausing to ask whether it still applies.

Suppose the work is divided between two agents. One gathers the figures and passes a summary to another that writes the email. You remove the first agent’s access to the forecast. It can no longer fetch the file, exactly as intended. The second agent still has the summary and may not need to fetch anything at all.

There need be no malicious intent, secret workaround or attempt to escape supervision. The agent may simply continue the job you gave it. That is why checking what it can open is only part of checking what it can disclose.

One setting can determine whether an agent keeps following yesterday’s rules. In a September study, researchers tested a memory tool called mem0, which lets agents save and reuse information. Its default filter kept expired instructions out of the agent’s working context. With that protection on, agents made no prohibited choices in 810 tests. When researchers switched it off, agents chose a prohibited action in 42% of tests—even though the stored information had not changed. These results show why teams need to check how old instructions are handled in their own setup. [4]

For the company ending its supplier contract, deleting every old record would be a poor answer. It may need those records to settle outstanding deliveries or hand work to a replacement. The old forecast can remain useful inside the business even though it must no longer go outside it. The safeguard has to make that distinction when the agent uses the information.

Test what reaches the inbox

You tell the team to stop the supplier updates. One person removes the agent’s access to the forecast file. Another changes its settings. But an update was already in progress, and the agent had gathered the figures. How does the team check that the email will never reach the former supplier?

Start with the outcome you need: the former supplier must not receive internal information through this task, including information gathered before the contract ended. That gives the team something concrete to test: whether the agent can still send information it already holds, even after its access has been removed.

The test can use invented forecasts and a supplier mailbox controlled by your own company. Let the agent prepare an update while sharing is permitted. Then end the test relationship, change the permissions and leave the working notes that would normally survive. Ask it to continue. The point is to recreate the awkward moment when unfinished work meets a new rule, without putting real information at risk.

Follow the attempted send. Check the message the agent prepared, the tool it tried to use and what reached the test mailbox. If it was blocked, establish where the block happened. If nothing arrives, check whether a send was attempted and blocked, is still waiting to go out, or was never attempted. The agent saying that it obeyed the rule is one account of events; the sending records and receiving system let you check that account.

A second agent can help check what happened, but it needs more than the first agent’s account. Give it access to the sending logs and the test mailbox so it can check whether the message was blocked or delivered.

Test every way the agent can send the message: through its email connection, through a browser, or by asking another agent to send it. Blocking one route is not enough if another remains open.

Also check that the agent can still do useful work, such as preparing an internal briefing for the team taking over the supplier relationship. The restriction should stop information from reaching the former supplier while allowing that internal work to continue.

Record whether the system stopped the email or warned you after it arrived. A warning can help you respond, but the former supplier already has the information. Before letting the agent send messages without supervision, you need evidence that it can prevent the disclosure.

Security and operations teams already check permissions and test changes. Memory tools such as Zep also offer filters to exclude outdated information. [5] Apply these checks to the whole job, including saved notes and work passed between agents.

Keep a clear record of what you tested: which information must stay inside the company, which sending routes were blocked and which still need checking. When someone adds a tool or changes the workflow, that record will help the team decide what to test again.

Who lets the agent keep working

Who decides which work the agent can continue?

By the end of the day, the supplier contract is over, the teams have been told and access has been removed. Then, someone asks: “Can we leave the agent running overnight?”

The AI provider can explain the agent’s safeguards. The technical team can show which controls it tested. The business owner can explain what work still needs doing. And the person answering that overnight question needs all three.

They need enough evidence to give a specific answer: the agent can prepare the internal handover, but external sending stays disabled until the remaining checks are complete. They also need the authority to enforce that decision: the ability to restrict the agent’s work.

An independent assessment can help. Before allowing the agent to share confidential information, spend money, or make commitments to customers, you need evidence that its safeguards work for those actions.

The decision also needs revisiting when its basis changes. If the agent gains a new way to send messages, yesterday’s tests may no longer justify leaving it unattended. Someone must recognize that change and arrange the check before the new capability is used.

That is the purpose of continuous assurance: giving the business a sound basis for deciding what its agents can do today, and knowing when that decision needs another look.

Before the next email leaves

The supplier relationship is over. The company is moving on, and the agent should be helping with the handover. Its saved work remains useful; its old instruction to send the weekly update has expired.

Businesses change course every day. Contracts end, budgets shrink and customers withdraw permission. As agents take on longer-running work, those decisions must reach tasks already underway—even when nobody is watching.

That is part of what a business buys when it invests in automation: the ability to delegate work and still direct it. The company should be able to close the offboarding ticket and get on with its day, confident that its agent will not spend the night carrying out a decision it has already reversed.

Put These Ideas to Work

Want to put these ideas to work? Subscribe free to The Sovereign AI Enterprise and receive the Field Guide: five decisions to help you examine what your AI systems can do, which dependencies matter, and whether you can account for their actions. You’ll also receive my ongoing analysis of enterprise AI, governance and technology sovereignty.

Sources

[1] OpenAI. How we build safety, security, and privacy into dots.

September 29, 2026. See the sections on controlling information and checks before actions. Product documentation describes the safeguards; it is not independent evidence of their effectiveness.

[2] Claire Carter. READ IN FULL: Trump and tech leaders’ White House Accord on Super Intelligence.

Washington Examiner, September 29, 2026. Reporting and reproduction of the accord; supports the description of the commitments.

[3] NVIDIA. NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment.

September 28, 2026. Company announcement of OpenShell and the Sentry reference design. Capability claims remain attributed to NVIDIA.

[4] Yi Ting Shen, Kentaroh Toyoda and Alex Leung. Revoked but Still Authoritative: An Empirical Study of Revocation Enforcement in Agent-Memory Systems.

arXiv:2609.08258v1, September 8, 2026. Preprint. See Appendix B.3, Table 13, for the default-versus-disabled mem0 filter comparison, and Section 3.1 for the information supplied to agents.

[5] Zep. Searching the Graph.

Documentation, accessed October 2, 2026. See filtering for current or valid facts. Current product documentation is distinct from the versions and settings examined in the preprint.

The researchers trying to understand OpenAI agents’ attack on Hugging Face had roughly 1,300 agent transcripts and more than 70,000 shared messages and files to work through. They could not examine it all themselves in the time available. In its August 2026 investigation, METR—an independent nonprofit that evaluates the capabilities and risks of advanced AI systems—delegated much of that work to other AI agents. ^[1]

AI made the investigation feasible, but the researchers could not fully verify its findings. METR reported errors in the analysis and raised concerns that some summaries reflected the viewpoint of the agents under investigation. The researchers therefore had to scrutinize both the original evidence and the AI’s interpretation of it.^[1]

The Hugging Face attack occurred in a cybersecurity evaluation with fewer safeguards than OpenAI’s deployed systems. Therefore, the incident itself can’t tell us how often similar failures will occur in everyday business use. But it raises a practical question for enterprises: how do you act on an investigation when you rely on AI to interpret the evidence?^[2]

When enterprises use AI to investigate incidents, they must be able to check its findings against records protected from alteration, actual business outcomes, and tests of the proposed explanation. Without those checks, the AI’s version can become the accepted version of events.

TL;DR

• When AI investigates a failure, its conclusions can determine who gets compensated, which decisions are reversed and whether leaders close the incident. Errors in the investigation can leave the original harm unresolved.

• The risk is accepting a convincing explanation that the evidence only partly supports. A report may correctly identify a fault while overlooking affected customers or another cause.

• Fixing the fault is only part of the job. The enterprise still needs grounds for saying who was affected, what must be corrected and when the investigation can close.

  Subscribe now

The investigator decides what becomes visible

Security and operations teams already reconstruct events through logs, traces and transaction records. NIST published enterprise log-management guidance in 2006. W3C’s provenance framework describes where records come from and how they were derived, and prior research connects multi-agent analysis to the evidence supporting its conclusions. The audit trail is well established; the question is how to verify the conclusions an AI draws from it. ^{[3, 4, 5]}

An investigative AI does more than retrieve those records. It selects events for attention, connects activity across systems, and proposes causes. It may dismiss a contradiction that would have changed a human reviewer’s mind. By the time the report reaches that reviewer, much of the judgment about what matters has already been made.

Consider a hypothetical insurer investigating a rise in denied claims. Its AI investigator reports that an obsolete policy document caused the increase and that the problem ended when the document was replaced. To accept that explanation, the insurer needs to establish that denials increased, that the obsolete document caused the increase, and that replacing it stopped the errors.

The insurer can check which claims were denied and may have records showing which policy document the agent received. If denials fell after the old document was replaced, that would support the investigator’s explanation. But the drop could also reflect a change in the claims coming in: more may have qualified for coverage. And if another system still uses the old document, some errors could continue. The insurer therefore needs more evidence to establish both what caused the increase and whether the problem has been fixed.

If the report leaves out these possibilities, the claims director may close the incident too soon. A clear, confident explanation can make incomplete evidence seem conclusive.

The first article in this publication argued that enterprises need to reconstruct how an AI reached a decision. When another AI investigates that decision, reviewers also need to see how it selected the evidence and reached its conclusion.

A recorded explanation can still be wrong

Anthropic encountered a related problem in its own investigation of cybersecurity incidents. In its September 2026 assessment, the company revised an earlier explanation that had relied heavily on Claude’s statements that it believed it was operating in a simulation. Anthropic acknowledged that it had made overly strong claims about the model’s beliefs from what the model said. Its subsequent assessment used deeper transcript analysis, resampling experiments, and interpretability work. ^[6]

If an AI says, “I believed this action was authorized,” recording that statement does not prove it had permission. The investigator must check what permission was granted and whether it covered the action taken. The AI’s explanation is something to investigate, not sufficient evidence of why it acted.

Even the activity log needs checking. METR found small-scale instances of agents making transcripts appear to contain tool calls that had not actually occurred, affecting roughly 7 percent of the transcripts it examined. The finding means that a tool call shown in a transcript is not proof that the tool ran.^[1]

For the insurer, a request to deny a claim, a tool’s success response and a committed change in the claims system are separate events. The investigation needs to connect them through identifiers recorded by the systems involved. Those records should, where feasible, sit outside the acting agent’s write permissions.

Digital signatures help verify where a record came from and whether it was changed. Some signed logging systems can also detect missing entries. But an unchanged record can still be wrong or incomplete. Investigators need to check how the system captured the information and what it may have missed.^[7]

An activity log can be accurate and still leave out something essential, such as the document an agent retrieved or an action taken in another system. For example, OpenTelemetry is developing standards for recording agent and tool activity, but capturing sensitive content is optional. So the logging system may work exactly as intended without preserving the information needed to understand the agent’s decision.^{[8, 9]}

Before putting the system into use, the insurer needs to decide what information to keep so it can explain and review a denial. If it waits until a customer complains, the document the agent used may already be gone.

An explanation should expose itself to a test

When the records do not explain what caused a failure, an experiment can help test the suspected cause. Anthropic’s CHIVE research changes prompts, measures the model’s responses over repeated trials, and checks AI-generated explanations against the results. The point is to test whether an explanation holds up before acting on it. Otherwise, an enterprise could fix the wrong problem while the actual cause remains. ^[10]

The insurer could apply that approach by testing the same claims with the old policy passage and its replacement, keeping other relevant conditions as similar as possible. If the decisions change, that would support the explanation that the policy wording affects the outcome. The insurer should preserve the inputs, model versions and results, along with how it selected the claims, so an auditor or claims reviewer can assess the test.

That would help explain how the policy wording affects decisions, but it would leave questions about earlier denials. For a particular customer’s case, the insurer still needs to know which passage the agent received. If the test uses a newer model, it also needs to account for the possibility that the model behaves differently. The experiment can guide a repair without resolving every past case.

The check should therefore match the question being asked. Testing a suspected cause may require an experiment; checking a total may require only a calculation. A reviewer can check an approval against its scope and expiry, or a reported payment against the settlement record. Many of these checks do not require AI.

What they have in common is that another reviewer can examine the evidence and decide whether it supports the finding. That is independent verification. AI can help locate records or design tests, but its summary must lead back to the underlying evidence—including anything that challenges its conclusion.

Anthropic’s AuditBench tested whether AI investigators could discover undisclosed behaviors that researchers had built into other models. In some cases, tools found useful clues, but the investigators still reached the wrong conclusion. The study does not tell us how well AI would audit a real enterprise, but it shows why access to evidence is not enough: the investigator can still misread what it finds.^[11]

The finding becomes an enterprise decision

Suppose the insurer has confirmed which claims were denied, and that replacing the old policy passage changes the agent’s decisions. That gives the claims director grounds to correct the system and review potentially affected claims. But records are missing for part of the period, so the team still cannot tell which document the agent used in every case—or which denials the old document caused.

The director needs to explain why the available evidence justifies the response and what still needs investigating. The insurer should keep that explanation, the approval and the supporting records and tests together. A later reviewer should be able to understand how the decision was made and check whether the evidence supports it.

This also means giving reviewers the authority to ask for more investigation. If an unanswered question could change which customers receive help, signing off on the report should not automatically close the case.

An outside investigation service should allow the same scrutiny. Before buying one, ask the provider to walk you through an important finding. Can you inspect the original records, see which cases it reviewed and repeat its calculations? If it keeps only the report, you have little basis for checking its work. A second model reading that report cannot recover the missing evidence.

In September, Transluce, an independent nonprofit AI research lab, examined records from a public web-scanning service and found evidence of agent activity earlier than previously reported. Those records expanded the known timeline, but they were incomplete and could not establish everything the agents had done.[13] Before closing an incident, reviewers need to know which systems and time periods the investigation covered, where records are missing, and whether those gaps could conceal further harm.

Reviewers do not need to examine every case in equal detail. They can focus on serious consequences, conflicting evidence and carefully chosen samples. First, though, they need to check that the investigation includes the cases it should. The insurer can compare the list of claims reviewed with its claims-system records for the relevant period, then account for any missing cases. Finding no errors in a sample does not establish that customers left out of the investigation were treated correctly.

There are also practical limits to what an enterprise can preserve. Keeping more records costs money and may mean retaining more sensitive information. Recreating an older system may be impossible. Those limits need to be considered when the system is designed and acknowledged when an incident is investigated. If the evidence cannot establish who was affected, the final report needs to say so.

^{Know what justifies closing the incident}

Experienced investigators already distinguish what the evidence shows from what they think happened. They preserve records and test other explanations before reaching a conclusion. Enterprises using AI can build on those practices and on research such as PROV-AGENT, which helps trace agent activity. ^[12]

The challenge is keeping that discipline when AI handles much of the investigation. If reviewers receive only its chosen examples and final report, they may have enough information to approve the conclusion but too little to challenge it. They need access to the supporting evidence, time to examine it and authority to require further investigation.

For the insurer, that means looking beyond whether the system now works correctly. Which customers were wrongly denied, and what will the company do for them? Before closing the case, the claims director needs to understand which customers the investigation covered and whether gaps in the evidence could leave others without a remedy.

AI can help the insurer investigate faster, but the company still decides when it has done enough. Before closing the case, it needs evidence that the response addresses the harm, not just the fault in the system. Otherwise, the investigation may end with a successful repair and customers still waiting for claims that should have been paid.

Put These Ideas to Work

Want to put these ideas to work? Subscribe free to The Sovereign AI Enterprise and receive the Field Guide: five decisions to help you examine what your AI systems can do, which dependencies matter, and whether you can account for their actions. You’ll also receive my ongoing analysis of enterprise AI, governance and technology sovereignty.

Sources

[1] METR, Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident, August 26, 2026.

[2] OpenAI, The Hugging Face incident and the road ahead, August 2026.

[3] NIST, Guide to Computer Security Log Management, September 2006.

[4] W3C, PROV Overview, 2013.

[5] Friedman et al., Provenance-Based Interpretation of Multi-Agent Information Analysis, 2020.

[6] Anthropic, An alignment assessment of recent cybersecurity incidents, September 9, 2026.

[7] IETF, RFC 5848 Signed Syslog Messages, May 2010.

[8] OpenTelemetry, Semantic Conventions for GenAI agent and framework spans, Development status; reviewed September 27, 2026.

[9] OpenTelemetry, GenAI spans and content capture guidance, reviewed September 27, 2026.

[10] Karvonen et al., Would This Change Your Answer, CHIVE research, August 21, 2026.

[11] Anthropic, AuditBench, March 10, 2026.

[12] Souza et al., PROV-AGENT, 2025.

[13] Transluce, “Early rogue AI agent activity and attempts to hack found on urlquery.net,” September 23, 2026.

CME Group and Silicon Data are working to launch futures tied to the rental prices of Nvidia H100 and B200 GPUs.^[1] In other words, AI compute is beginning to be treated like oil, electricity or metals: a resource whose future price can be benchmarked and potentially hedged.

The contracts were originally scheduled to begin trading on October 5, although regulatory review has delayed the launch. What matters is the development: companies may soon have a financial instrument for managing part of what they currently lump together as “compute risk.”

But even if you can hedge, there’s still a practical problem.

Subscribe now

What compute will cost is different from whether enough suitable capacity will actually be available. Both are different again from how quickly the hardware may become obsolete, whether a workload can move somewhere else, and how much control the enterprise retains over the environment in which it runs.

A futures contract might eventually help with the cost. It won’t solve the others.

TL;DR

• The future price of AI compute is becoming easier to isolate and potentially hedge. CME and Silicon Data are developing futures tied to H100 and B200 rental prices, although the launch is currently delayed by regulatory review.

• A predictable price does not guarantee usable compute. Capacity can still be unavailable, in the wrong location, or unsuitable for the workload.

• Buying, reserving, renting and hedging solve different problems. Enterprises should be clear about which uncertainty each decision is supposed to reduce and which risks they are choosing to keep.

• If you are paying a premium for dedicated or sovereign infrastructure, know what you are buying. The extra cost should deliver something concrete—assured capacity, locality, continuity, portability or greater operational control—not simply protection from higher compute prices.

  ---

The different risks hidden in your compute budget

Companies operating in mature commodity markets already make these distinctions because they have to. An airline can hedge fuel prices and still worry about whether fuel will be available where its aircraft need it. A manufacturer can manage copper-price exposure while separately managing suppliers, inventories and delivery. Electricity cost, electricity availability and grid reliability all affect the same factory, but no serious operator assumes they are interchangeable.

Enterprise AI has not yet developed comparable precision around compute.

Higher GPU rental rates, unavailable capacity, rapidly aging hardware, a provider changing its terms, or an application that proves unexpectedly difficult to move can all turn into some version of “our compute problem.” That may be enough for budgeting, but it doesn’t help the company decide what to do next.

CME’s proposed contracts begin separating one of those variables. Each contract is designed to represent 730 GPU-hours—approximately one GPU running continuously for an average month—and settle financially against Silicon Data indexes tracking rental prices. The original design called for monthly contracts extending as far as three years forward.^[1]

The important part is the financial settlement. No GPU actually changes hands.

Suppose an enterprise expects to rent a large amount of H100 capacity next summer and worries that rental rates could rise sharply. A futures position could potentially offset some of that increase. If prices rise, the financial hedge may perform exactly as intended.

But the provider can still tell the company that there is no capacity available in the region where its workload has to run. The hedge worked, but the application still can’t run.

That is not a failure of the contract. It simply reveals that price and physical availability were never the same exposure. Silicon Data’s own material also highlights basis risk: the benchmark and a particular buyer’s actual costs can diverge because providers, regions, contractual terms and service configurations differ.^[3]

Once those distinctions become visible, several things that have occupied the same compute budget begin to come apart.

Price is the most obvious: what will comparable capacity cost when the enterprise needs it?

Availability is more operational. The company needs enough of the right hardware, in the right place, connected to the right infrastructure and available when demand arrives. A cheap cluster in another jurisdiction, or one without the necessary networking and security controls, does not solve that problem.

Then there is the operating environment around the compute. An application may be relatively portable at the model layer and still depend heavily on a provider’s identity systems, storage, networking, orchestration, APIs and operational procedures. Moving the model is not necessarily the difficult part. Reconstructing everything required to operate it may be.

Hardware costs add another trade-off. Owning the hardware gives the enterprise more direct access, but newer equipment may soon offer better performance for the same price. Renting shifts more of that risk to the provider, while giving the enterprise less control over the environment it runs in.

Separating these risks does not make compute strategy simple, but it clarifies which problem each decision is meant to solve.

Owning, reserving and renting carry different risks

Consider an enterprise that expects its AI demand to grow substantially over the next three years.

A company can buy and operate its own GPUs, reserve capacity from a cloud or neocloud provider, or rent capacity as demand develops. If financial markets for compute mature, it may also be able to combine flexible rental with instruments that reduce its exposure to future price changes.

Enterprise sourcing discussions often place these options on familiar continua: build or buy, capex or opex, ownership or cloud. These distinctions are familiar and useful, but a company needs a deeper understanding of what they are taking onto their balance sheet and operating model.

Owned infrastructure provides stronger physical access and can give the enterprise greater control over the environment in which workloads run. The company also carries utilization, financing and hardware-obsolescence risk. If demand disappoints or a newer accelerator changes the economics, there is no provider absorbing the difference.

Reserved capacity moves some of that burden elsewhere while providing more certainty than short-term rental. But the commitment itself becomes a source of risk. A provider, geography or chip generation that looks sensible today can look rather different two years into a multiyear agreement.

Flexible rental preserves more freedom to follow changes in hardware and pricing. That flexibility comes with greater reliance on somebody else’s capacity and operating conditions.

A financial hedge is narrower still. It may reduce exposure to movements in a benchmark rental price without changing much about how the workload is supplied.

The assets underneath those choices also age on very different clocks.

Goldman Sachs estimates that AI accelerators have an economic useful life of four to six years, compared with about 20 years for data-center buildings and at least 25 years for power infrastructure. Its May 2026 analysis finds that the assumed replacement cycle for chips has the largest effect on its estimates of total AI infrastructure spending. Even small changes in replacement cycles can alter multiyear investment needs by hundreds of billions of dollars.^[4]

A long-term AI infrastructure investment can include a building with an estimated economic life of 20 years, power infrastructure with an even longer economic life, chips with a much shorter one, and a commercial contract that expires sooner still. The applications running on that infrastructure may change several times along the way.

Owning capacity can still make sense despite these different lifespans. Some workloads require assured availability, a specific network setup, local processing, tighter control over where data moves, or consistent response times. A company may also want to operate independently of a particular external provider.

Those capabilities are worth paying for, but their value is separate from a bet on future GPU prices. If companies can more easily track and hedge rental prices, the extra cost of ownership or a long-term reservation must be justified by the availability, control or other benefits it provides.

Renting shifts some of these risks rather than eliminating them. The buyer avoids the upfront hardware investment, but someone still has to finance the equipment and bear the risk that it sits idle or loses value. The contract determines how those costs and risks are shared with the enterprise.

Financing that infrastructure is becoming a major undertaking. S&P Global Ratings expects combined capital expenditure by six major hyperscalers to exceed $1.3 trillion in 2027. It also points to the growing role of debt, leases, guarantees and other financing structures in funding the AI infrastructure buildout.^[2]

Over time, the more consequential sourcing discussion may be less about whether enterprises should generally own or rent compute and more about which uncertainties they are prepared to hold themselves.

A market price will not tell an enterprise what control is worth

The distinction between managing price risk and securing availability and control matters even more when cost is only one factor in choosing how to source compute.

A company concerned about changing rental prices may eventually be able to hedge some of that risk. But a hedge cannot ensure that a regulated workload stays in the required jurisdiction, that capacity remains available during a disruption, or that an application can move between providers, even if its AI model can.

A cash-settled contract cannot move identity systems, networking, storage or orchestration logic.

The development of financial markets around compute can therefore make enterprise sovereignty discussions more precise.

Companies often mix ordinary commercial uncertainty with strategic dependency. Expensive infrastructure can feel like dependence. Owned hardware can feel like control. Domestic hosting can feel sovereign. Adding another supplier can feel like diversification.

Owning hardware, hosting it domestically or adding another provider may all make sense. Each decision still needs to be judged by which risks it reduces and which dependencies remain.

A company paying more for dedicated or sovereign infrastructure should be clear about what it gains: assured capacity in a required location, tighter control over sensitive data, less dependence on an external provider, or the ability to keep operating through disruptions affecting its providers or supporting infrastructure.

Those benefits may justify the extra cost, but they do not necessarily protect the company from rising GPU rental prices.

Likewise, a market that makes it easier to hedge rental prices would not resolve questions about where workloads can run, who controls them or whether capacity will be available when needed.

Oil provides a useful analogy. Oil futures are among the most mature commodity markets in the world, but governments and companies still care intensely about production, pipelines, shipping routes, storage and physical access. The existence of a forward price did not make control of the physical system irrelevant.

Compute could develop along similar lines.

As compute prices become more transparent, companies can better judge what they are paying extra for. Some workloads need capacity in a particular location and a reliable way to keep operating through disruptions. Others may run just as well on capacity rented as needed.

The answer will vary by workload, which is why a single enterprise doctrine—always cloud, always own, always reserve, always sovereign—is unlikely to age particularly well.

Clearer compute prices demand a clearer strategy

For most enterprises, GPU futures are unlikely to become a routine treasury activity anytime soon.

Their larger importance is what they reveal about enterprise planning.

Compute cost, compute access and compute control have often been treated as different aspects of one infrastructure decision because they arrived bundled together. As a financial layer begins to form around compute, that bundle becomes easier to inspect.

Price can increasingly be treated as its own variable. Physical availability still requires capacity planning. Architecture still determines what can move and what has to be rebuilt. Security, legal and risk teams still have to determine which providers, jurisdictions and operating conditions are acceptable.

A clearer view of future compute prices does not resolve questions about availability, portability or control. It helps companies assess each separately and make better infrastructure commitments.

A long-term reservation should address a specific need, such as predictable costs or assured capacity. A dedicated environment should offer benefits that justify the risk of equipment sitting idle or becoming outdated. And a company relying heavily on flexible cloud capacity should understand how much it depends on the provider’s availability, terms and operating environment in exchange for that flexibility.

The right balance also changes as a workload develops. Experimentation, model training and day-to-day production may each need different levels of flexibility, assured capacity and control. A sourcing choice that works for an early experiment may no longer fit once a business process depends on it.

These decisions affect more than infrastructure teams. As businesses rely more on AI, compute choices shape which applications can grow, where they can run, how much it costs to keep them running reliably, and how much control the company retains over the systems supporting them.

That is why the emergence of a financial market for compute matters even if most CIOs never trade a GPU future.

CME and Silicon Data’s proposed contracts may attract enough trading to become useful hedging tools, remain a niche product, or fail in their first form. Whatever happens, companies are developing more ways to price, finance, lease and contract for compute.

Those markets may give enterprises a clearer view of future rental prices. But business leaders still have to decide how much to pay for assured access, flexibility and control—and which risks they are willing to accept.

So before signing the next infrastructure commitment, ask three questions: What risk are we reducing? What capability are we paying for? And if capacity becomes cheaper but our provider can’t deliver, can the business keep running?

Put These Ideas to Work

Want to put these ideas to work? Subscribe free to The Sovereign AI Enterprise and receive the Field Guide: five decisions to help you examine what your AI systems can do, which dependencies matter, and whether you can account for their actions. You’ll also receive my ongoing analysis of enterprise AI, governance and technology sovereignty.

References

[1] CME Group. “CME Group and Silicon Data to Launch Compute Futures on October 5 to Unlock New Way to Hedge AI Risks.” August 11, 2026.

[2] S&P Global Ratings. “AI Infrastructure Investment To Exceed $1.3 Trillion By 2027.” August 27, 2026.

[3] Silicon Data. “The Practitioner’s Guide to the Compute Future: How to Hedge, Step by Step.” September 14, 2026.

[4] Goldman Sachs Global Institute. George Lee and Lucas Greenbaum, “Tracking Trillions: The Assumptions Shaping the Scale of the AI Build-Out.” May 1, 2026.

Consider a manufacturer that wants an AI assistant to help service technicians diagnose equipment faults before the next maintenance season. Its engineers have identified two plausible approaches. Both could search maintenance records and suggest what to inspect next; neither has yet been tested against the company’s full equipment range and access requirements.

One comes with cloud credits, an implementation partner and engineers who can start next month. The other would give the manufacturer more control over how records are searched, but its internal platform team is already committed elsewhere. The service director has a deadline and only one proposal with a credible delivery team.

Accepting that offer may be the right decision. By the next project, however, the same provider may have an advantage: experienced people, working connections and an established deployment process. An alternative’s benefits would then have to outweigh the effort of adapting or replacing what already works.

Government grants and provider assistance can help create this advantage by supplying people as well as money. A decision made to meet one deadline can begin to determine which future projects the company knows how to build.

Subscribe now

What the delivery package leaves out

Suppose the manufacturer’s implementation partner proposes a ready-made connection to maintenance records. It retrieves completed service histories, but omits the technician’s notes explaining why a repair was deferred. Those notes might distinguish a recurring fault from a known problem awaiting parts. If adding them falls outside the support package, the team may leave them out to stay within budget.

The architecture lead needs to make that consequence visible. Management can then decide whether the better diagnosis justifies paying for the additional integration. Otherwise, the functions included in the package may become the limits of the application simply because they were the easiest to deliver.

This is a hypothetical trade-off, but the value of delivery assistance is documented. In a June 2024 Microsoft case study, the development non-profit CARE described difficulty extracting useful information from open-ended staff survey responses. An Azure Innovate grant and technical expertise from Valorem Reply , an implementation partner, helped it build and test a sentiment-analysis tool within two months. CARE said it lacked that expertise internally.[1]

These programs can also influence design. Microsoft’s guidance for supported Azure landing zones, which provide the foundations for cloud workloads, includes help choosing how those workloads will be operated and implemented. Partners have more freedom to customize outside the program.[2] AWS’s April 2025 expansion of its Migration Acceleration Program tied AI modernization support to services including Bedrock and SageMaker.[3]

A provider supporting its own services is hardly surprising. For the manufacturer, the practical issue is what the offer makes easy to build and what requires extra work. An engineer familiar with a managed service and a tested deployment pattern may deliver sooner. Management needs to weigh that delivery advantage against product features, price and the cost of assembling a team for the alternative.

The second project inherits the first

Suppose the assistant succeeds. Technicians learn when to trust its suggestions and how to report errors. The delivery team has connected maintenance records, configured user access and established a process for deploying changes. And then, another division wants an assistant for warranty investigations using some of the same equipment histories.

Reusing the connection looks sensible. It may call the maintenance system’s API, through which software requests information or performs actions. The partner might also have supplied an MCP server, using the Model Context Protocol to expose tools such as retrieving a machine’s service history to compatible AI applications.[7] The warranty team would still need to check that the tool returns the right records and respects its users’ permissions, but it would have a working starting point.

While the original grant or credits may have ended, their effect can remain in the cost of the second proposal: extending a working service may take less effort than adapting or replacing it. A competing supplier could reuse some components too, if the manufacturer has the necessary access and they work with the proposed design. Those conditions help determine whether the first investment makes several approaches easier to deliver or mainly benefits the original one.

Each decision could be reasonable on its own, yet together they can make the same provider harder to displace. As teams gain experience with its services, managers have more reason to give them the next project, further strengthening that provider’s position. A rival then has to show how it would deliver the work those teams already know how to do. A better model alone may not justify starting again.

The manufacturer has also invested in learning how to judge the assistant’s work: whether it finds the right equipment records and gives technicians useful advice when a fault description is ambiguous. Changing the model or how it retrieves records can change those results, so the team would need to establish which tests and judgments still hold. Part of the cost of adopting another design is learning whether it can be trusted on the same jobs.

Governments influence who can help

The manufacturer’s staffing problem also depends on which specialists are available outside the company. Public programs can help build that supply. My Strategic AI Optionality research distinguishes access to technology from the ability to replace it. For enterprises, that ability depends partly on the expertise and systems built during the first implementation.

Singapore’s Enterprise Compute Initiative combines provider-supplied credits, tools and training with public support for consulting, according to its February 2026 factsheet. Partners familiar with the platforms help develop an application and support organizational change. The government pays part of the consulting cost; providers contribute their own resources.[4]

The work can reach directly into business systems. A June 2025 Google Cloud and Digital Industry Singapore announcement described Seaco’s development of a container-inspection application with CloudMile. Photographs and voice notes helped prepare damage and repair information for its SAP environment. Production testing was still forthcoming in that account.[5]

Governments want businesses to become more productive and local engineers to gain experience. Providers want more companies to use their services. These interests can bring them together to fund and staff enterprise AI projects. Over time, the projects they support could shape which platforms local engineers know best.

A country could therefore give businesses access to several providers while most engineers available to deliver projects know only a few platforms well. For a company facing a deadline, that can narrow the practical choice: it can buy the technology, but may struggle to find a team to implement it. Public support could broaden that choice by developing expertise in less-supported alternatives, or deepen the advantage of platforms that already have experienced teams. The Singapore program illustrates how such support is organized; whether it produces either effect remains an open question.

What the company can do after the handover

Using the same provider again does not establish a loss of choice. It may keep winning because it delivers good value. Outside help may also give the manufacturer’s engineers experience they could not have acquired without getting a real project underway. Whether that experience expands their choices depends partly on how the work is organized.

The manufacturer could put an internal engineer alongside the partner and involve service specialists in developing test cases. They would learn why the assistant behaves as it does and what an acceptable result looks like. AI Singapore’s 100E program describes documentation, training and knowledge transfer intended to equip recipients to maintain their solutions.[6] These commitments do not establish that recipients can move their systems to another provider.

The handover also needs to establish whether another team can use and maintain the connections built for the project. Could a different assistant use the maintenance-history tool, or must the original partner change how access is granted first? Could the manufacturer modify the MCP server or operate it elsewhere?

MCP gives compatible applications a common way to interact with a server’s tools and data.[7] The server may still depend on a managed service, and access to the underlying maintenance system must still be authorized. A common interface helps with reuse, but ownership, permissions and service dependencies determine how much another team can actually take over.

Even after a successful launch, the manufacturer might need the original delivery team to make routine changes. Management may accept that arrangement, provided it understands the ongoing costs and the work its own engineers will be able to do. If the project was meant to let internal engineers make those changes, however, that reliance would reveal an unmet objective.

The longer-term concern is whether the manufacturer can choose another approach and put it into practice. If it can, staying with the same provider may simply reflect good service. If every new project returns to the original team because nobody else has the knowledge or access to deliver it, the first investment may have narrowed the company’s choices. Continued use alone does not tell us which explanation applies.

Invest in the next choice

Before accepting the offer, the manufacturer should decide what its own engineers, or another supplier, need to be able to change after delivery. If an alternative offers an important advantage, management could fund a focused assessment of its hardest integration and find a team capable of building it. That would help establish whether the extra control justifies the work, without requiring a second complete system.

For example, the assessment might show that another design could reuse the maintenance-data connection, provided a different team had permission to access it. Or it might reveal that the connection depends on services only the original partner can change. Management would then know where to invest: securing access, assigning an integration engineer or extending the existing service. Access to another model would resolve none of those gaps. The assessment would clarify the work required; proving that the company could leave would still require a working replacement.

Governments face a similar choice when funding enterprise AI. Alongside a working application, a program can help the recipient develop engineers who understand the system and can commission further work. Whether that warrants additional funding depends on the program’s purpose. A training requirement alone does not show that the recipient can put what it has learned to use.

The manufacturer may reasonably accept the original offer: its immediate need is to help technicians do better work. But management should know whether the other design lost because it was unsuitable or because the company lacked a way to build it. If management wants a wider choice next time, the work to make that possible belongs in this deal.

Sources and notes

The manufacturer and its decisions are hypothetical. CARE and Seaco are attributed participant accounts published by providers; they do not establish that assistance caused supplier selection or later dependence. The longer-term effects proposed here are hypotheses developed from the Strategic AI Optionality research. Government and provider objectives are distinct, and implementation competence does not by itself demonstrate cross-provider portability.

[1] Microsoft, CARE leverages data and Azure AI to prepare for global emergencies, 27 June 2024. Source

[2] Microsoft Learn, How to get help building a landing zone. Program planning scope and customization options. Source

[3] AWS, MAP enhancements to accelerate AI customer adoption, 30 April 2025. Source

[4] Digital Industry Singapore, Enterprise Compute Initiative factsheet, updated 10 February 2026, pages 1–4. Source

[5] Google Cloud and Digital Industry Singapore, AI Cloud Takeoff launch announcement, 13 June 2025. Source

[6] AI Singapore, 100E program description, including handover and knowledge transfer. Source

[7] Model Context Protocol, Architecture and Authorization. These describe how MCP connects applications to server-provided capabilities and distinguish access to an MCP server from authorization to underlying APIs. The manufacturer’s implementation is hypothetical.

Consider a multinational insurer preparing to renew its cloud agreement. Procurement has a competitive offer. The CIO has spent years building a multi-cloud architecture, and the AI team can route requests to several models. Moving the claims assistant looks like a good opportunity to put that investment to work.

The assistant reads claim files and policy terms, then prepares recommendations for adjusters. Staff still approve payment decisions. The team moves the application to a competing cloud, connects a model and asks it some questions. The answers look good. Procurement would quite reasonably like to know when they can stop paying the old provider.

Then claims operations asks to try a normal working queue. One file contains documents that only certain adjusters may see. In the existing system, the cloud’s identity service enforces those access rules, but the new environment does not yet have an equivalent arrangement. Giving the assistant access to everything would make the demonstration easier. It would also make it unsuitable for the business.

Rebuilding that control reveals other unfinished work. The assistant still relies on the old environment to retrieve documents and update the claims system. When a reviewer asks how it reached a recommendation, some of the necessary records are still there too. The application runs on the new cloud, but processing claims still depends on services left behind.

Figure 1. The exit test includes the work and controls surrounding the model. Hypothetical insurer.

This insurer is hypothetical, but the decision it faces is concrete: can the company make use of the competing offer before renewal, and what would doing so cost? Its supplier list cannot answer either question. The CIO needs to establish whether claims staff can do their work in the alternative environment.

As AI becomes part of business operations, freedom to change providers depends on preserving that work through the change. Multiple clouds and models can help, but their value as alternatives depends on whether the company can use them when it needs to leave.

Subscribe now

What would count as leaving

Enterprises have long discovered that moving away from a database or business application involves more than exporting its data. With AI, the company must also assess how the replacement handles work that does not have one predictable answer.

Suppose a claim contains conflicting accounts of an incident. A replacement model might give one account more weight. A different document search service might retrieve another passage from the policy. The new system can run without technical errors and still produce recommendations that adjusters need to handle differently.

Different recommendations do not necessarily make the replacement unacceptable, but the insurer needs to understand their effect on claims work. Adjusters must still be able to reach defensible decisions and investigate mistakes, while access controls keep restricted documents from the wrong people. Those requirements remain even when the technology providing them changes.

I use exit credibility to describe the ability to replace an important dependency within a time and cost the business can accept, while keeping the operation sufficiently capable, secure and accountable. It gives strategic AI optionality a practical meaning: the organization has an alternative it could actually use.

The timeline is important. A six-month migration may give procurement leverage at next year’s renewal, but it offers much less protection if the service becomes unavailable next month. Claims operations also needs to agree what can change. A slower response might be tolerable; losing control over confidential documents would not be.

This develops an argument I’ve made before: AI sovereignty extends beyond where the servers sit into how much control a business has over the systems it relies on.^[1] The insurer’s renewal puts that control to a specific test. Can it replace the provider without losing the ability to conduct this part of its business?

A different supplier may leave the same dependency

The insurer’s immediate concern is a cloud renewal. For that purpose, another cloud could provide a useful alternative. If management were worried about a shortage of a particular accelerator, however, it would need to check whether both clouds depended on the same chip supply. Changing the contract might leave the original problem intact.

My research began with countries seeking greater control over their AI capabilities. I wanted to know whether infrastructure and technical standards could tie them to American or Chinese ecosystems before their governments made an explicit political choice. As I examined India and Singapore, I saw a parallel with enterprises pursuing AI sovereignty: having competing suppliers available did not establish whether they could replace the systems they depended on. Countries and companies have different powers and responsibilities, but that question of replacement brought the research back to the insurer’s renewal decision.

India’s public compute program offered meaningful supplier choice. July 2025 documentation listed Nvidia accelerators alongside Intel Gaudi and AMD MI300X, yet all three companies were US-headquartered.^[2] Competition among them could improve commercial terms without providing the same degree of protection from decisions made by the US government. A supplier’s headquarters alone do not determine which laws apply to a transaction. Switching vendors may still leave the business exposed to the same legal restrictions.

At the same time, India was developing its own capabilities. Government material reports more than 45,000 GPUs in shared compute capacity as of June 2026 and 20 indigenous foundation-model proposals selected for support. An August 2026 statement acknowledges domestic limitations in semiconductors and computing infrastructure while describing investment to reduce them.^[3][4]

The important discovery was that these layers did not move together. Imported chips could run Indian models and applications controlled by Indian firms. They could also run foreign open-weight models. Dependence on foreign hardware did not settle who controlled the applications, just as a domestic model did not create an independent supply of chips.

I began by asking which ecosystem a country might join, but India shifted my attention to the specific dependencies that could limit its choices. Domestic investment could reduce those dependencies if it produced alternatives capable of handling the required work at scale and available when needed.

Figure 2. A supplier switch can solve one problem while leaving another exposure intact. Illustrative comparison; IndiaAI supplier detail from source 2.

The insurer faces a similar problem: having a replacement model does not make the cloud services around it replaceable. If document access still depends on the incumbent, funding another model will do little to improve its position at renewal. The useful investment would make that document-access service replaceable, allowing the insurer to use the competing cloud offer.

The alternative also has to match the concern. A workable move away from one provider’s pricing can be valuable even if other dependencies remain. If the company says switching providers would let it avoid a government restriction, it must verify that the restriction would not also apply to the new provider and setup. Being able to change suppliers does not necessarily mean being able to avoid the same legal constraints.

How a good implementation makes leaving harder

Locating the dependency still leaves the insurer with a puzzle. Why should a cloud service be so difficult to replace when competing services are readily available?

Some dependencies arise because few suppliers can provide the technology. Advanced AI chips illustrate that obstacle. But the insurer can create substantial switching costs of its own through perfectly sensible implementation decisions.

Imagine its engineers choosing a managed document service because it helps them launch sooner. Security connects it to the identity system the company already trusts. Claims staff learn how to investigate errors using that platform’s records. When another team builds an assistant, reusing this arrangement saves work and avoids introducing unfamiliar controls.

As more projects build on it, replacement means changing working practices as well as software. Hiring favors people who know the platform, and each new integration gives the next project another reason to stay. I call this ecosystem gravity. The supplier may have earned that reliance by serving the business well. Unfortunately for the insurer, leaving now means undoing more of what works.

Figure 3. Successful adoption can deepen a dependency even while alternatives remain available.

Researching Singapore helped me examine whether broad access to competing technology would prevent this kind of dependence. Its government had deliberately supported provider choice: Singapore GovTech’s Government on Commercial Cloud lets agencies use AWS, Azure or Google Cloud within common security controls, with avoidance of single-vendor lock-in an explicit benefit.^[5] China’s Huawei and Alibaba also offer cloud and AI services in Singapore.^[6][7] The availability of both American and Chinese providers challenged my initial expectation that countries would increasingly build around one ecosystem or the other, although it did not establish how easily organizations could switch between them.

What caught my attention was the work that turns access into adoption. Singapore’s February 2026 Enterprise Compute Initiative factsheet describes training and implementation support, including process redesign and change management, alongside cloud access. Its participating providers are Google Cloud, Microsoft, AWS and Oracle.^[8]

That support addresses exactly what the insurer would have to rebuild when it leaves: the way people operate the technology. It helps explain how a company could have several suppliers available while accumulating much of its expertise and day-to-day work around one of them.

These government programs do not measure the cost of leaving, and GovTech’s arrangements for public agencies should not be confused with the Enterprise Compute Initiative’s support for businesses. For me, Singapore sharpened the question rather than settling it. I needed evidence of organizations moving the work they had built, not simply evidence that they could buy from several providers.

The research brought me back to the choices companies make within the conditions government policy creates. Policy helps determine which technologies are available and affordable, and companies build their operations around those options. Whether that creates lasting dependence depends partly on their ability to replace what they have adopted. For the insurer, testing the alternative would show how much freedom it actually has at renewal.

Can the alternative do the work

The engineering team could reasonably challenge the idea that these dependencies will remain difficult to escape: perhaps the migration is simply unfinished. By making documents and access rules portable, maintaining its own evaluation cases and rebuilding the services around the model, the team could give the insurer a workable alternative. The difficulty would then be a matter of completing the necessary engineering work.

There are sound reasons to take this possibility seriously. Keeping business rules outside proprietary model tools reduces what has to change when the model changes. Being able to deploy a suitable open-weight model can provide alternatives to a hosted service. Even accelerator software can move: AMD’s HIP tools help convert code written for Nvidia’s CUDA environment to run on AMD hardware, although AMD’s documentation also describes adjustments developers must make.^[9]

But even portability tools can introduce dependencies of their own. A gateway that connects five models may also hold the routing rules, evaluations and tool permissions the operation relies on. If replacing the gateway requires rebuilding those controls, management needs to include that work in its assessment. The gateway helps preserve an exit only to the extent that it makes the working claims system easier to move.

The insurer does not need to resolve every dependency before testing its cloud alternative. It needs a clear proposition: claims assistance can stop relying on the incumbent before renewal, within an approved budget, while retaining the controls and performance the business requires. The competing provider must also have capacity available and contract terms the company can use.

A migration plan establishes how the team proposes to get there. A successful production migration would provide evidence that this system could move under the conditions tested. However, it is the ability to repeat the exercise with measured costs and outcomes that would make future claims about the alternative more credible.

Figure 4. Repeated measured migrations strengthen the evidence for a usable alternative. Geopolitical claims also require testing the relevant shared exposure.

The test can begin with the difficult claim from the opening: restricted documents and conflicting evidence. The new assistant must retrieve what it is entitled to see and exclude what it is not. An adjuster needs to review its recommendation before approving the next action. Any tool that updates the claims system must act within the authority the insurer has given it.

To investigate a recommendation, staff need a record of the documents that reached the model and the model and search configuration used. They also need to see what any connected tool did and what the adjuster approved. Linking these records to the claim allows staff to trace an error without searching across unrelated systems.

The claims system supplies the business evidence: how long the work took, whether it needed correction, and whether staff completed it acceptably. Claims operations can review those results with Engineering and Risk. The accountable business owner can then decide whether the arrangement meets the agreed tolerances and whether to authorize the move.

Figure 5. A difficult claim exposes what to inspect. A representative queue at realistic load tests whether the alternative can sustain the operation.

A difficult claim can reveal what needs checking, but the insurer needs a representative queue at realistic volume to establish whether the alternative can sustain the operation. The assessment should include the engineering effort and time needed to prepare the move, because an otherwise successful replacement may still arrive too late for the renewal.

Finally, acceptable performance does not require identical answers or every feature surviving. The insurer might tolerate a slower response if outcomes and controls remain adequate. But it must agree to those tolerances before the test. Otherwise a missing feature can suddenly become something management supposedly never needed.

What management can do with the result

Suppose the replacement model performs well, but rebuilding document permissions threatens the deadline. Procurement still has a useful answer: the insurer can fund that specific work, negotiate more transition time, or accept another contract period. The test has located the obstacle and made its cost visible, even though it has not yet produced an exit.

Management could also arrange for adjusters to handle more work during a disruption, provided they could absorb the workload without creating unacceptable backlogs. That would help keep claims operations running while the migration proceeds, but management should treat it as a fallback, not proof that the AI system is ready to operate with another provider.

A successful migration would matter to the broader research as well, but its significance would depend on what changed. Leaving a cloud provider would establish an alternative for the work tested. It would not, by itself, show that the company had escaped a shared upstream or geopolitical exposure.

The research behind this article has not established repeated moves of whole consequential AI systems across materially different geopolitical ecosystems at strategic scale. If organizations can switch providers at an acceptable cost while maintaining business performance and controls, I would be less convinced that dependence on a platform gives its supplier—or the government with authority over it—lasting power over customers. The evidence could still lead there. Meanwhile, the insurer can test its own ability to switch and use the results in its next renewal decision.

The company may still renew with the incumbent. A better price elsewhere might not compensate for migration costs or the loss of useful features. But having a credible alternative lets management compare those tradeoffs with greater confidence. Staying can be a reasonable decision when the company understands what leaving would involve.

Wrap Up: Who keeps the alternative ready

Even if the insurer proves it can switch providers and then chooses to renew with the incumbent, it will need to keep the alternative ready. The competitor’s price and capacity commitments may expire, while new features in the claims assistant may rely on services the replacement does not yet support. By the next renewal, the insurer may need to update and test the alternative again before it can credibly use it in negotiations.

Keeping an alternative ready costs money even if the company stays with its current provider. Teams may need to reserve capacity that goes underused, maintain portable interfaces and check whether new integrations have restored dependence on the incumbent. If the system changes materially, they may also need to repeat the migration test before management can rely on the earlier result.

This creates an awkward budget problem. The delivery team gets credit for launching the claims assistant, while its budget may also have to pay for an alternative that procurement will need two years later. Unless someone can fund the work needed to keep that alternative ready, teams will prioritize the next launch and let the exit plan fall out of date.

Ownership therefore matters as much as the initial architecture. Someone needs authority to weigh the benefit of a proprietary feature against the cost of rebuilding it elsewhere, and to fund another test when the system changes materially. Leaving those decisions to each project makes it difficult to preserve an option whose value appears elsewhere in the business.

For the next important AI investment, management should understand which dependency it is accepting, what evidence supports its ability to replace it, and who owns the cost of keeping that ability real. Multiple suppliers can help create that choice, but keeping it available at the next renewal requires someone to fund and maintain the alternative.

Put These Ideas to Work

Want to put these ideas to work? Subscribe free to The Sovereign AI Enterprise and receive the Field Guide: five decisions to help you examine what your AI systems can do, which dependencies matter, and whether you can account for their actions. You’ll also receive my ongoing analysis of enterprise AI, governance and technology sovereignty.

Sources and notes

The claims-assistant scenario is hypothetical. Country cases describe the cited programs and offerings; conclusions about dependency and future switching costs are analytical inferences. Program figures are dated snapshots.

1. The Sovereign AI Enterprise, Strategic AI Optionality — Thesis Synthesis Memo, September 2026; earlier essays “The AI Stack and the New Balance of Power” and “Beijing Is Building the Machinery That Turns Models Into an Economy.” The synthesis revised the original country-level bloc hypothesis toward layer-specific dependencies and credible replacement. This article develops that test rather than treating national alignment or platform lock-in as an established binary condition.

2. Government of India, Press Information Bureau, IndiaAI compute capacity and foundation-model program details, 30 July 2025. Lists Nvidia, Intel Gaudi and AMD accelerators in the shared compute offering. Supplier headquarters indicate shared jurisdictional exposure, not identical legal treatment in every transaction.

3. Government of India, Press Information Bureau, IndiaAI Mission factsheet. Reports more than 45,000 GPUs as of June 2026 and 20 indigenous foundation-model proposals selected for support. Capacity and proposals do not themselves establish successful substitution.

4. Government of India, Press Information Bureau, Government Expands Sovereign AI Infrastructure Through IndiaAI Mission and Semiconductor Initiatives, 6 August 2026. Acknowledges domestic capability limitations and describes measures across the AI value chain.

5. GovTech Singapore, Digital tech stacks for the public sector, updated 20 August 2026. Describes GCC support for AWS, Azure and Google Cloud and its stated single-vendor lock-in benefit. This is architecture evidence, not a measured record of full AI capability migrations.

6. Huawei, Huawei Cloud Introduces Token Service in Singapore. Provider announcement of AI compute and model services, including GLM, DeepSeek and Qwen. Evidence of an offering, not independent verification of performance or market penetration.

7. Alibaba Cloud, Platform for AI region restrictions. Lists Singapore availability for AI computing resources and services. Regional availability varies by feature.

8. Digital Industry Singapore, Enterprise Compute Initiative factsheet, updated 10 February 2026, especially pages 1–4 and 6. Names the four participating cloud providers and describes credits, training, partner services and change management.

9. AMD ROCm documentation, Porting CUDA code to HIP. Documents HIPIFY conversion tools, corresponding libraries, architectural differences and adjustments. Supports technical portability with work still required; it does not establish full-stack enterprise or geopolitical portability.

Imagine spending months finding a way out of Nvidia’s ecosystem, only for the finance team to tell you that staying would be cheaper.

You lead AI infrastructure at a German automotive group planning a €1 billion AI facility. Your team has found an alternative that does the work the business needs, matches Nvidia’s performance and costs less. It also reduces dependence on a supplier the company has been trying to diversify away from.

You take the recommendation to finance expecting a discussion about the saving. Instead, the CFO brings the loan offers.

Subscribe now

The lenders know the Nvidia equipment. They have seen similar installations operate and have a better idea of who would buy the hardware secondhand. For your preferred design, they want a higher interest rate and more of the company’s money upfront.

By the time the CFO finishes the calculation, the saving has disappeared. Your team has found cheaper equipment for a more expensive factory.

Nobody in this imagined meeting has made a foolish decision. The engineers found a good alternative. The CFO priced the whole investment. The problem is that a chip competes with more than another chip: it competes with the money available to buy it.

We do not yet have comparable loan offers proving that buyers face this gap. But Nvidia’s announcement of a plan with six major financial institutions to mobilize more than $500 billion for AI infrastructure puts the possibility squarely on the table. If financing favors its equipment, a rival can catch up in the lab and still lose in the CFO’s office.

For countries pursuing sovereign AI, that is a brutal complication. They can spend years building a competitive domestic chip and still leave customers unable to afford the switch. Independence needs a financing offer.

1. Nvidia wants to win the financing decision too

Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs and KKR are working with Nvidia to establish independent financing platforms. The $500 billion is their ambition for capital mobilized over time, not money already committed to projects. The purpose is to let AI labs, cloud providers and enterprises build infrastructure using outside capital instead of paying for the entire buildout from their own resources.

Investors will still judge the projects individually. They need to know whether the facilities can earn enough and what the equipment will be worth later. Nvidia says it may provide residual-value support for up to 25 percent of an opportunity in some transactions, taking on part of the risk that the assets turn out to be worth less than expected.

That offer belongs in the same competitive picture as the hardware. Helping a customer get a project financed brings a sale closer to approval. Nvidia is working on the part of the decision that begins when the engineers leave the room.

A recent project in Ohio shows the kinds of commitments investors can examine before deciding to finance a facility.

At the PORTS-Pike Technology Campus, SB Energy is developing an AI site for OpenAI under 20-year leases. Nvidia’s filing describes exclusive use of its infrastructure, with limited exceptions, and phased guarantees capped at $105 billion for the initial land, power and building-shell commitments. Nvidia is also investing $1.5 billion in SB Energy. Those guarantees cover site commitments; they are separate from any promise to support GPU resale values.

A long lease gives lenders rental income to examine, provided the tenant can pay. Secured electricity makes it more credible that the facility can operate. Familiar equipment gives investors a record to judge, and a broad customer base improves the chances of finding another user if the original tenant leaves. These are reasons to put money into a project, not details at the back of a chip brochure.

Residual-value support tackles another lender’s worry: what if the equipment sells for less than expected? Nvidia can make a deal more attractive by agreeing to cover part of the shortfall. The contract decides how much protection investors actually get.

Nvidia already has customers invested in CUDA and years of accumulated software expertise. It has also agreed to acquire Hugging Face for approximately $12.9 billion, potentially expanding its influence over how developers find and deploy models. Nvidia says the platform will remain open and will not require Nvidia compute. Even without exclusivity, that developer presence matters. Easier financing would add another reason for customers to stay.

A rival now has a larger sales problem. It must persuade customers to leave familiar technology and help them pay for the move. Winning the benchmark gets it into the meeting. Getting the project financed gets it built.

2. The next buyer helps pay for the first one

A lender looking at a new GPU is also thinking about its next owner. A frontier lab may replace a system that still has years of useful work left in it. A regional cloud provider, for example, might gladly buy that older hardware for inference or fine-tuning at a fraction of the original price.

If lenders expect those buyers to be there, they can lend more confidently against new installations. More installations then create more operators familiar with the equipment, some of whom may later buy it used. That is how an installed base can become a financial advantage: tomorrow’s resale market helps finance today’s purchase.

Of course, a used GPU needs somewhere suitable to run. Power, cooling and software compatibility all limit who can take it. A large customer base cannot conjure a buyer at whatever price the lender wrote into its spreadsheet.

But Nvidia does not need to abolish depreciation. It only needs lenders to trust its resale market more than a rival’s. Our manufacturer’s engineers are comparing what the equipment can do. Its lenders are also comparing what they could recover if the investment goes wrong. Both calculations end up in the price of the factory.

3. The flag on the building does not finance an exit

Suppose the manufacturer builds its facility in Europe, under European law, with local staff and locally held data. That is real control, and worth having. But if it later wants European accelerators and cannot obtain an affordable loan to buy them, the location of the building offers no answer. It has secured the local address without securing the next technology choice.

These are different questions about sovereignty, and a local data-center address answers only some of them.

Borrowing from foreign investors does not automatically mean surrendering control of the facility. To understand what control it retains, the company needs to examine the conditions attached to the money, including any restrictions on replacing equipment. It also needs to know whether another lender would fund a switch if the current one would not.

No foreign government has to issue an instruction for financing to narrow that choice. The manufacturer can be legally free to switch and financially unable to do it. A right to leave is worth less when you can’t afford to actually make the exit.

4. Somebody has to pay for being first

Being the first customer for a domestic chip is an expensive way to be patriotic. China faces that problem under restrictions on access to advanced American technology. Domestic accelerators need usable software, but customers also have to risk real money on equipment with little operating history. A national ambition does not make that risk vanish.

Huawei and China Mobile Hubei reported live-network validation of an inference solution using Ascend infrastructure in June 2026. Although that is evidence that a deployment can work, it does not tell us whether lenders would finance more such facilities without public support.

Public support gives the first customers somewhere to put part of that risk. State-owned organizations can buy early, procurement rules can favor domestic equipment, and subsidies can cover costs private investors will not accept. The technology gets time to prove itself without asking its first buyers to finance the entire experiment.

That support can also fund facilities that customers barely use. The US–China Economic and Security Review Commission reports that Beijing is restricting and consolidating data-center construction after utilization at some AI compute centers fell below 30 percent. Some were too small or dispersed, or had equipment poorly suited to demand.

This is not a clean division between Chinese state money and an American free market. Commercial judgment matters in China, and US policy shapes the environment in which Nvidia operates. Both systems are perfectly capable of paying for facilities that nobody uses enough.

The difference is in how projects get funded and who pays if they disappoint. China can use public support to sustain demand for domestic technology, whereas Nvidia is trying to attract institutional money to facilities built around its established equipment. In Nvidia’s approach, investors assess each project and the company provides support in selected deals. Either route can help customers acquire infrastructure they could not fund on their own.

In a privately financed project, for example, the developer may bear the cost of construction problems while the tenant commits to rent payments over many years. An infrastructure fund may own the facility, using loans alongside money invested by insurers or pension funds, and Nvidia may agree to cover particular losses under its guarantees.

Yet all those signatures can conceal one very large shared exposure: AI demand. If tenants struggle to pay just as equipment prices fall, several parties lose money together. Dividing up the contracts does not divide up the downturn.

A country backing an alternative needs to say who will carry losses while customers and investors learn to trust it, and where that support stops. Until then, early customers are being asked to bet their own money on a national ambition without knowing who will help them if the investment falls short. That is a hard proposition to take to a board.

5. The loan does not care that the chips still work

A GPU can work perfectly and still become a poor investment. A newer accelerator may do the same job using less electricity, while better models may need less compute for the task. The old equipment keeps running, but its owner can no longer earn as much from it or sell it for the expected price. The loan payments do not shrink to match this new reality.

Cheaper AI can also encourage more use, so efficiency does not automatically mean falling demand. But lenders cannot repay themselves with a forecast for the whole industry. This facility has to earn enough to cover this loan.

Strong demand and competitive hardware could keep the project earning enough to repay its debt. But if customers move to a different technology, used prices could fall, leaving lenders expecting to recover less by selling equipment pledged as security for their loans. They might then charge more or lend less when financing the next project.

Nvidia could also have to pay under its guarantees at the same time its hardware sales weaken. How much it owes would depend on the agreements: GPU residual-value support concerns losses on equipment values, while Ohio’s site guarantees cover separate lease-related commitments. Investors need to check what triggers payment under each agreement and the limits on Nvidia’s obligations.

Now picture the German manufacturer returning to its lenders in 2030. The facility it built in 2026 is operating, and people across the business have come to rely on it. Although the land and grid connection may still be valuable, the GPUs are several generations behind. Before financing their replacement, lenders will examine both the cost of the new hardware and the company’s ability to repay a new loan. The operating team, meanwhile, needs that funding to keep the facility capable of doing the work the business now depends on.

The manufacturer needs to test that upgrade before approving the first build. What happens if the old GPUs sell for less and the new loan costs more? Otherwise, today’s celebrated investment becomes tomorrow’s unbudgeted request to the board. The bills don’t stop when the facility opens.

6. Sovereignty has a renewal bill

Imagine the first installation is finally working. Then the customer asks how it will pay for the second generation. For the team developing a European accelerator, getting into production is a major achievement. For the customer, it is the beginning of a service it now has to keep running.

A chip subsidy can get hardware to market without creating lenders willing to finance it or buyers willing to take it secondhand. If those markets never develop, every upgrade sends the customer back to the government. The technology is domestic; the funding still needs political permission.

Governments have ways to help. Development banks, for example, can provide loans, while public guarantees can cover specified lender losses. Government procurement can give early facilities paying customers, and public-private funds can invest in construction. If the state also guarantees equipment values, it should spell out how much it will pay when resale proceeds fall short.

A government may decide that continuing support is worth the price. Fine—but say so, budget for it, and tell customers how dependable that commitment is. Recurring subsidy is not automatically a failed strategy. Calling it financial independence is another matter.

Europe, India, the Gulf states, Japan and South Korea have different ambitions for AI autonomy. Each should explain how customers will pay to keep the infrastructure current. The size of the first installation tells us how much a country can launch. The upgrade plan tells us how much it can sustain.

7. Before the CFO closes the spreadsheet

Let’s return to the meeting at our German manufacturer. The engineers do not need to withdraw their recommendation, and the CFO does not need to ignore the loan offers. They need to put the full choice on the same spreadsheet: what each design costs to build, what the next upgrade requires, and what it would cost to change suppliers. A low purchase price or an attractive first loan is only part of the answer.

These costs also reach companies that rent compute. A cloud provider’s borrowing costs can show up in its prices and lease terms, while its access to financing can shape which hardware it offers and how much capacity it builds.

For either an owner or a renter, the starting point is the control the business actually needs. Keeping data locally may meet an important requirement while leaving the company reliant on foreign hardware. If that hardware supports a critical workload, the team should be able to explain how it would keep operating if the equipment or its funding became unavailable. An alternative that nobody has worked out how to pay for is not much reassurance to the people responsible for keeping the service running.

The manufacturer may still choose Nvidia. That can be a sensible decision. But if today’s financing makes a future switch unaffordable, the company should see that commitment before it signs: A dependency understood is a tradeoff it can manage. But a dependency discovered at refinancing can be a nasty surprise.

For governments, the job is to make the alternative a choice this customer can actually use. That takes funding for replacement equipment and enough flexibility to change suppliers when the business needs to. A domestic chip in a domestic building is a start. The ability to choose what goes into that building next is the prize.

The real test of AI sovereignty comes when the hardware needs replacing: can you still afford to choose your supplier?

Maria has spent fourteen years reviewing commercial insurance claims. She notices details that rarely appear in policy manuals: a contractor’s estimate that feels unusually low, water damage that does not fit the reported timeline, or a claim that looks ordinary until she finds nearly identical repairs paid under another policy eighteen months earlier.

Her company recently deployed an AI-assisted claims workflow. It retrieves policy language, examines prior claims, checks for fraud indicators, gathers supporting documents, and recommends approval, denial, or escalation. Maria spends less time assembling the file and more time reviewing the difficult cases.

One Tuesday morning, the workflow recommends approving a commercial property claim. It has found the previous loss but treated it as background information. Maria sees a pattern. Two similar claims in less than two years justify another look. She overrides the recommendation, records her reasoning, and routes the case to the fraud team.

The claim moves forward. The workflow does not.

Several weeks later, Maria encounters the same pattern. Then again. Each correction becomes part of the claim record, preserving the rationale and satisfying the audit trail. None changes how the workflow handles the next claim.

The insurer is learning from production. Its AI workflow is not.

Every mature business expects its operations to improve with experience. Manufacturing teams refine processes, supply chains adapt to disruption, sales organizations sharpen qualification criteria, and cybersecurity teams adjust defenses after each incident. Operational experience is supposed to change how the organization works.

AI workflows are exposing a gap in that learning process.

Many organizations are deploying systems that retrieve evidence, call tools, compare options, apply policies, evaluate their own work, and recommend consequential actions. Once those systems reach production, their reasoning strategies often remain surprisingly static. Models may be upgraded, prompts adjusted when something breaks, and retrieval logic may get patched. Costs receive attention when invoices rise.

What rarely exists is a disciplined way for production experience to change how the workflow reasons the next time it encounters a similar case. This is not a model quality problem, but an organizational learning problem.

Subscribe now

The Cost Question Came First

Cloud computing created a management problem because infrastructure stopped being purchased periodically and started being consumed continuously. Developers could provision resources in minutes, while finance and operations struggled to understand who owned them, why they were still running, and whether the resulting value justified the bill.

FinOps emerged to make that consumption visible, attributable, and manageable.

Enterprise AI is following a related path. As workloads move beyond pilots, organizations want to know which models are being used, where retries multiply, how much workflows cost, whether routine requests can move to smaller models, and how usage should be budgeted across teams.

Those questions are producing what many now call Token Economics. This discipline is a step in the right direction, but it is incomplete.

Suppose Maria’s insurer reduces the claims workflow’s reasoning cost by 30 percent. The AI dashboard shows a clear improvement. The finance team sees lower inference spending.

The claims operation may tell a different story.

If adjusters spend more time correcting weak recommendations, appeals increase, or fraud losses rise because ambiguous claims receive less reasoning than they need, the insurer has made AI cheaper while making the business more expensive.

A workflow can also consume more reasoning and improve the operation. The difficult claims may receive an additional pass through a frontier model. AI spending rises, but human review Token consumption measures resource usage, not operational effectiveness.

In AI Moral Hazard Is Coming for the Enterprise, I called this distinction Reasoning Economics: the relevant economic unit is not the token itself but the business outcome produced by the reasoning, including work avoided, errors prevented, decisions improved, and exceptions reduced.

That argument established how enterprises should evaluate reasoning. But it left a practical question open: once an organization can identify which reasoning earns its cost, how should that evidence change the workflow?

Another dashboard will not do it.

The Workflow, Not the Model

Much of the enterprise AI market still treats the model as the main object of improvement. A stronger model arrives, benchmarks improve, context windows expand, or inference prices fall. The conversation quickly turns toward replacing one model with another.

In production, many failures originate somewhere else.

The workflow retrieves the wrong evidence before making a recommendation. Or it invokes a frontier model where deterministic logic would have been sufficient. It asks the same model to review its own answer without adding independent evidence. And it may escalate too early and push routine work back to people, or too late, after consuming several expensive reasoning steps that never change the outcome.

A different model may leave every one of those problems intact.

The workflow contains the actual reasoning strategy. It determines what context is assembled, which tools are available, which model is used, when another pass is warranted, where deterministic rules take over, and when a person enters the decision.

Each production execution tests those choices against reality:

• Maria overrides a claim recommendation.

• A procurement manager rejects a preferred supplier.

• A software engineer discards an AI-generated pull request.

• A maintenance technician ignores the suggested repair because experience points to another component.

These actions are usually treated as user behavior or audit evidence. They are also feedback on workflow design: production is generating the evidence needed to improve enterprise reasoning.

But most organizations retain only the portion that is easiest to collect. They keep token counts, traces, latency, model usage, tool calls, retries, and error logs. Those records can reconstruct what the workflow did. They rarely show whether it did the right amount of reasoning, used the right evidence, or handed the decision to the right person.

The more valuable signals are scattered across operational systems: the override and its rationale, the eventual disposition of the claim, the appeal filed two weeks later, the defect discovered after release, the supplier that failed after receiving a high score.

An execution trace explains how the recommendation was reached. But it is the system of record that shows what happened after that recommendation imacted the business.

Every workflow execution leaves behind both histories: One records the reasoning, the other records the consequences.

Neither is useful in isolation.

Production Is Not Permission

Maria’s overrides may reveal a flaw in the workflow. They may also reflect an unusual cluster of claims, a regional anomaly, or judgment that applies only to a narrow class of cases.

This kind of operational evidence creates a hypothesis. It does not authorize a production change.

Enterprises already know how to work with that uncertainty:

• Software teams isolate changes before release.

• Manufacturing engineers validate process adjustments before altering the production line.

• Banks test fraud models before changing approval policies.

AI reasoning should be handled in a similar fashion.

Suppose six months of claims data shows that 82 percent of low-complexity property claims invoke the same frontier model twice. The second pass changes the recommendation in only 3 percent of those cases.

This pattern doesn’t prove that the second pass should be removed, but it should be investigated.

The insurer could create a controlled variant in which routine claims receive one reasoning pass while claims with conflicting evidence or unusual loss histories retain the second review. Another variant might retrieve prior-loss history earlier. A third could route straightforward cases to a smaller model and preserve deeper reasoning for ambiguous ones.

Each version would handle a limited share of production traffic. Each would be measured against more than token savings:

Did exception rates change? Did adjusters spend more or less time reviewing the file? Did claim leakage rise? Were more cases appealed? Did the new path shorten cycle time without weakening fraud detection?

AI can identify the pattern, estimate the likely benefit, and help construct the alternative. Then, a person decides whether the experiment is worth running. Finally, a person also decides whether the evidence justifies promotion.

The enterprise is applying controlled experimentation to the reasoning embedded in its operations, not asking the AI to improve or redesign anything.

Of course, one experiment will not transform the insurer. But a sustained series of them might. The highest-value improvements will often look mundane:

• A retrieval step moves earlier.

• A second reasoning pass disappears for routine claims.

• A deterministic rule handles cases that never benefited from probabilistic reasoning.

• A human-review threshold moves after the organization learns where intervention changes the result.

Taken together, these individual improvements reshape the operation. Similar to how factories became more productive through thousands of process refinements. And how software became more reliable through repeated improvements to testing, deployment, and observability. Enterprise AI will mature through the same accumulation of operational learning.

Your Best AI Dataset Already Exists

Production data can show where a workflow behaves unexpectedly, but it can’t determine by itself whether the workflow improved.

Suppose the new improved claims path completes cases 20 percent faster. That looks like progress until appeals rise, fraud losses increase, or adjusters spend longer correcting recommendations.

While execution metrics describe the workflow, business systems describe the business: The claims platform knows whether a recommendation was accepted, whether the payment was recovered, whether an investigation uncovered fraud, how long the adjuster spent on the file, and whether the decision survived an appeal.

Similarly, a procurement system can show whether the supplier delivered, a service platform whether the issue reopened, a software-delivery system whether the code caused defects in production, and a maintenance system whether the machine failed again.

These systems have traditionally been treated as places where transactions are stored. In an AI operating model, they also become the source of evidence that determines whether a reasoning strategy works.

The workflow recommends; the operation responds. And this response becomes evidence for the next version of the workflow. Connecting those records closes a loop that most enterprise AI architectures still leave open.

Without execution telemetry, the organization cannot see how the workflow reached its answer. Without outcome data, it cannot tell whether the answer held up. A system may become cheaper, faster, and more efficient according to every AI metric while shifting cost and risk into the rest of the business.

This is where Token Economics reaches its boundary.

It can reveal that a frontier model was invoked twice, that reasoning costs rose, or that a smaller model could reduce consumption. It cannot establish whether the second pass prevented a costly exception or whether the smaller model pushed work back to an experienced employee.

That’s why the optimization target has to move from the model call to the completed workflow.

This requires access to systems of record, common identifiers that connect an execution to its eventual outcome, and a sufficiently long evaluation window to capture consequences that do not appear immediately: Some outcomes arrive in seconds, but others take days or months.

For example, a recommendation to reject an invoice can be evaluated quickly. But a supplier decision may not reveal its quality until the contract is underway. And a fraud recommendation may look correct until an appeal or recovery effort concludes.

That’s why reasoning quality often lives downstream from the reasoning event. Enterprises that fail to connect those systems will optimize the visible part of AI and miss the part that determines value.

From Observability to Improvement

AI observability is becoming table stakes. Organizations need traces, model usage, tool calls, latency, cost, errors, and evidence of how a workflow behaved.

But observability explains the past; an operating discipline also has to shape the next version.

That requires workflow versioning, controlled traffic allocation, outcome measurement, promotion criteria, rollback, and clear ownership of the decision to change production behavior. The technical components already exist in pieces across application platforms, model gateways, experimentation systems, governance tools, and systems of record.

What is missing is a shared operating loop.

A runtime executes the workflow and records how the case was handled. Analysis surfaces a pattern worth investigating. A revised workflow changes one or more elements: retrieval sequence, model routing, reasoning depth, tool order, deterministic checks, escalation thresholds, or human review.

The alternative is tested against agreed measures such as accuracy, exception rates, cycle time, cost, latency, human effort, and downstream business results. Evidence determines whether the change is promoted, revised, or discarded.

Then the process repeats.

This is not governance. Governance establishes the boundaries within which an AI workflow may operate. This improvement discipline asks how performance can advance without violating them.

Nor is this MLOps. The model may remain untouched while the workflow changes substantially around it.

The object being managed is the reasoning strategy embedded in operational work. This reasoning strategy is Reasoning Operations.

It is the operational counterpart to Reasoning Economics: one determines whether reasoning earns its cost; the other turns that evidence into a better production workflow.

FinOps manages the economics of cloud consumption. Token Economics manages the consumption of AI resources. Reasoning Operations manages the evolution of reasoning inside production workflows.

The three disciplines coexist because they address different challenges:

• FinOps shows where cloud resources are being consumed and whether that consumption is efficient.

• Token Economics shows where AI resources are being consumed and whether model usage is justified.

• Reasoning Operations shows whether the workflow should continue reasoning the same way.

Who Owns the Learning Loop?

Ownership does not sit cleanly inside a single function:

• Technology teams control the runtime, orchestration, integrations, and telemetry.

• Business owners understand the outcome being optimized.

• Domain specialists know where judgment matters.

• Risk and compliance teams define acceptable boundaries.

• Finance can see cost movement but not always the operational consequences behind it.

No group can operate this loop alone:

• The business cannot improve a reasoning strategy it cannot observe.

• The technology team cannot judge business quality from model traces.

• Risk cannot approve changes without evidence.

• Finance cannot distinguish waste from necessary reasoning by looking at consumption alone.

Reasoning Operations will therefore resemble other cross-functional disciplines. It will require named ownership, agreed measures, decision rights, and a repeatable process for moving evidence into production changes.

Its most important artifact may be the record connecting a proposed workflow change to the evidence that justified it, the outcome measures used in the experiment, and the human decision that promoted it.

That creates an audit trail of improvement, not just execution. It also changes the role of human intervention.

Human review is often described as a safety mechanism or an exception path, but it shouldn’t be a patch for a workflow that doesn’t improve. Instead, it should be a learning signal. Maria’s override matters not only because it prevents a weak decision, but because it reveals where the workflow’s reasoning strategy should change.

When the Workflow Finally Learns

Months after Maria first overrode the commercial property claim, another case arrives with similar characteristics.

This time the workflow flags the prior loss immediately. It requests additional evidence before making a recommendation and routes the case for investigation without requiring Maria to correct it.

She reviews the file, agrees with the escalation, and moves on. The workflow now reflects what the insurer has learned from operating it, which is what mature enterprise systems eventually do.

The companies that build this capability will improve faster because production experience will accumulate instead of disappearing into logs, audit trails, and human memory. Every month in production will make the next month better.

FinOps gave enterprises a way to manage cloud consumption. Token Economics is giving them a way to manage AI consumption. Reasoning Operations addresses the question that follows both:

How does the enterprise turn what happened today into a better workflow tomorrow?

There is an increasingly common way to describe Europe’s position in artificial intelligence: Europe is regulating an industry it does not have.

The argument is easy to understand. The leading frontier-model companies are overwhelmingly American. Nvidia dominates the accelerators used to train and run advanced models. Amazon, Microsoft and Google control much of the hyperscale cloud infrastructure underneath them. American technology companies occupy layer after layer of the commercial AI stack.

China presents a different contrast. Beijing is investing heavily in models, compute, infrastructure, standards and the machinery around AI deployment. The shorthand almost writes itself: America innovates, China builds, Europe regulates.

There is enough truth in that criticism that dismissing it would be a mistake.

Europe has struggled to produce technology companies on the scale of its American counterparts. It has weaker growth-stage capital markets, substantial dependence on foreign cloud and semiconductor infrastructure, and relatively few companies competing at the frontier of general-purpose AI. Regulation cannot manufacture a European Nvidia or OpenAI.

But the criticism also assumes that the geopolitical competition over AI will be decided primarily where models and chips are produced.

That is becoming a less complete description of the AI economy: Models have to enter something. They have to become part of a bank’s credit process, a manufacturer’s supply chain, a pharmaceutical company’s research workflow, an insurer’s claims operation, an employer’s hiring system or a government service. Intelligence has to be connected to data, tools, workflows and institutions before it produces much economic value.

Europe still has considerable power there. The EU AI Act is usually discussed as a regulatory response to artificial intelligence. Seen alongside the industrial strategies developing elsewhere, it can also be read as an attempt to exercise power at a different point in the AI economy: the point where somebody else’s technology enters Europe’s industries and institutions.

That does not mean Europe has discovered a substitute for technological leadership.

It means the AI competition has more than one control point.

Subscribe now

1. The Model Race Is Only the First Contest

Most measures of AI power begin upstream: Who has the best models? Who controls advanced chips? Who can finance the largest training runs? Who owns the cloud infrastructure? Who has the researchers?

The questions matter enormously, and by most of them the United States begins from an enviable position.

But there is another problem after intelligence has been created: how effectively can an economy turn it into productive activity?

I explored that distinction recently in Beijing Is Building the Machinery That Turns Models Into an Economy. A July policy package from Beijing was interesting because it reached well beyond foundation models. It addressed context engineering, multi-agent coordination, middleware, runtimes, toolchains, identity, interoperability, skills markets, compute subsidies, software stores, intelligent devices, new company structures and even new ways of pricing agent services.

The phrase I used was AI conversion capacity: the technical and institutional ability to turn model intelligence into repeatable work, products, firms and measurable economic output.

A benchmark lead can disappear with the next model release. Infrastructure, standards, developer habits, marketplaces and installed bases can persist much longer. Beijing’s measures suggest that at least one major Chinese policy center sees strategic value in reducing friction along the entire path from intelligence to production.

Europe presents almost the inverse case.

It does not currently possess America’s frontier AI ecosystem, and the EU AI Act does not resemble Beijing’s attempt to build an agent economy. Europe’s strongest asset sits further downstream: a large market containing many of the industries into which AI ultimately has to be absorbed.

That makes the familiar criticism worth reframing:

2. Europe’s Asset Is the Economy AI Wants to Enter

Europe’s technology weakness can obscure the composition of the rest of its economy.

The continent remains home to globally important automotive manufacturers, industrial engineering companies, pharmaceutical firms, banks, insurers, energy companies, telecommunications providers and advanced manufacturers. These are not peripheral to the AI story. They are among the places where AI has to move from generating text and code to affecting production, capital, employment and physical systems.

European firms are not standing outside the technology either. European Investment Bank data from roughly 13,000 firms found that 37% of EU firms were already using generative AI in 2025, compared with 36% in the United States. European manufacturers were particularly strong adopters of AI and big data. The larger gap was in depth: American adopters were using AI across more business functions. This means Europe’s problem is not simply access to AI. It is converting adoption into broad productivity gains.

A 2026 EIB study covering more than 12,000 firms found that AI adoption increased labor productivity by about 4% among European firms in its analysis. The gains were concentrated among medium and large firms and were stronger when AI investment was accompanied by software, data and workforce training.

This is where the AI Act becomes economically interesting.

My previous article, The EU AI Act Could Turn Your Company Into an AI Provider, examined a recruiting assistant that began as a vendor product for summarization and drafting. The enterprise then added its own data, prompts, scoring logic, integrations and workflow authority until the system was ranking candidates and advancing them through an employment process. The underlying model did not have to change. The operational system did.

Under the AI Act, distinctions like intended purpose, substantial modification, provider and deployer can therefore matter well beyond the original model vendor. The provider boundary can move as enterprises assemble systems around models.

At enterprise scale, that is a compliance issue.

At continental scale, something larger happens. Europe is asserting authority over the point where model capability becomes an operational system inside European economic life.

The model and cloud infrastructure may come from abroad, but their use inside European recruitment, credit, healthcare, industrial products and other consequential settings is still subject to conditions Europe can impose on its own market.

3. Beijing and Brussels Are Targeting the Same Gap from Opposite Directions

Put Beijing’s recent agent policy beside Europe’s AI strategy and an unusual comparison appears.

Both are concerned with the gap between model capability and economic production.

Their methods are almost opposite.

Beijing is trying to reduce friction across that gap. Its policy supports reusable skills, common protocols, domestic frameworks, compute access, marketplaces, devices, company formation and new commercial models. The logic is cumulative: make capabilities easier to build, reuse, distribute and sell, and more of the economy should be able to convert model intelligence into production.

Brussels is intervening in the same passage from another direction.

The AI Act establishes conditions around how certain systems can enter and operate in the European economy. It assigns responsibilities, distinguishes categories of risk, reaches certain foreign providers accessing the European market and attaches obligations to consequential uses.

“China builds, Europe regulates” captures part of this difference but misses what both strategies reveal.

Neither treats the foundation model as the final unit of economic power.

Beijing is attempting to shape the infrastructure through which intelligence becomes economic activity. Brussels is attempting to shape the conditions under which that activity can enter its market.

These amount to different theories of leverage.

Beijing’s wager is that power can accumulate around the infrastructure, standards and commercial ecosystems used to operationalize intelligence. If Chinese protocols, runtimes, marketplaces and device ecosystems gain scale, Chinese conventions can travel with them.

Europe’s wager is that control over economically important deployment markets can influence technology developed elsewhere. Suppliers that want access to European banks, manufacturers, employers, public institutions and consumers must operate within conditions Europe has the jurisdiction to impose.

America occupies yet another position. It currently controls extraordinary amounts of the upstream commercial stack: chips, models, clouds, platforms and capital.

Seen this way, the geopolitical AI race starts to look less like a single leaderboard. Different powers control different choke points along the route from intelligence to economic output.

The important question is whether those forms of control can be converted into one another.

4. Europe’s Harder Gamble: Can Rules Create Capacity?

This is where the European argument becomes difficult.

Rules are not factories. Compliance does not create a model. A conformity standard cannot substitute for compute, and legal authority cannot substitute for venture capital.

If the European strategy were simply to regulate AI aggressively and wait for an industry to appear, the skeptics would have the stronger case.

But that is not quite what Europe is doing.

The EU is now trying to pair its regulatory regime with an industrial policy built around compute, data, capital and adoption. The AI Continent Action Plan includes AI Factories and Gigafactories, data infrastructure, talent initiatives and programs intended to accelerate AI adoption in strategic sectors. The Commission says 19 AI factories have already been deployed across European supercomputers, and in July it launched a process for up to seven Gigafactories expected to combine public support with more than €20 billion in private investment.

The point is not that these initiatives suddenly close Europe’s technology gap. They do not. Their significance is that regulation and industrial policy can reinforce each other.

Consider what happens when a large market establishes a common set of conditions for deploying consequential AI. Thousands of companies that would otherwise negotiate their own expectations around documentation, testing, monitoring, responsibility and acceptable use begin designing against a more common institutional environment. Standards can reduce some uncertainty for suppliers. Buyers can make more comparable demands. Infrastructure providers can build reusable services rather than solving every requirement separately for every client.

The law creates costs, but it can also create demand.

If European banks, manufacturers, hospitals and public agencies all need AI systems that can operate within the same regulatory environment, that creates a common market around deployment. Instead of every organization solving the same problems independently, suppliers can build products and services around recurring requirements, allowing integration patterns, testing methods, infrastructure choices and sector-specific applications to scale across clients.

None of that requires Europe to produce the world’s best general-purpose model. It requires enough domestic capability to capture the complementary investment surrounding the model. This is economically important because productivity from general-purpose technologies rarely comes from the invention alone: firms reorganize around them, infrastructure gets built, complementary products emerge, workers acquire new skills, and business processes change.

The EIB’s findings already point in this direction: European firms appear to gain more productivity from AI when they make complementary investments in software, data and training. Europe’s strongest version of the strategy is therefore not “regulation as innovation.”

It is regulation as a coordination mechanism for a market in which Europe is simultaneously trying to build more supply.

The recent AI Omnibus reinforces how contingent that strategy remains. The EU has extended implementation timelines for important high-risk provisions, simplified obligations for smaller companies and expanded access to regulatory sandboxes. The Commission explicitly frames those changes around reducing administrative burden while preserving the Act’s safeguards.

That adjustment can be read as retreat. It can also be read as evidence that Europe has recognized the constraint: a regulatory regime that outruns the standards, infrastructure and firms needed to satisfy it can suppress the very market it hopes to shape.

The European gamble works only if regulation reduces uncertainty faster than it increases friction, and if European companies capture enough of the investment induced by the new environment.

That outcome is possible, but far from guaranteed.

5. The American Incumbent Paradox

There is an uncomfortable alternative.

Suppose Europe succeeds in making consequential AI deployment more demanding.

Which companies are best equipped to meet those demands?

Microsoft, Google, Amazon and other large American technology companies already have enterprise sales organizations, security teams, compliance functions, cloud infrastructure, legal departments and relationships with Europe’s largest companies. Frontier-model providers can spread the cost of documentation, testing and regulatory adaptation across enormous international markets.

A European startup cannot.

The same rules that make market access conditional could therefore increase the fixed cost of competing in that market.

That creates an incumbent paradox: Europe could force global AI companies to adapt to European requirements while simultaneously making those companies harder for European challengers to displace.

Europe could still shape how global AI products are designed, because foreign suppliers would have to adapt their systems to European requirements. But shaping the product is not the same as capturing the value it creates; much of that value could still accrue to companies headquartered elsewhere.

Europe would have influenced the product without capturing the company.

This is why the distinction between regulatory power and industrial power matters. A regulation can successfully change corporate behavior and still fail to improve the competitive position of domestic firms.

The real test is not whether American AI companies comply. If Europe remains an important market, they will. The question is whether their compliance creates room for European firms to grow around them, or only helps foreign incumbents consolidate their position.

6. The Risk Is Governing Dependency

Europe could emerge from this transition with a sophisticated AI economy in which its banks, manufacturers, hospitals and public institutions deploy AI under rules Europe helped establish.

And much of the underlying stack could still belong to someone else.

The accelerators might remain foreign. The largest clouds might remain foreign. The frontier models might remain foreign. Important developer platforms and enterprise software could remain foreign.

Europe would possess meaningful authority over how AI operates without possessing equivalent control over the technologies on which those operations depend.

The EIB describes essentially this tension in economic terms. European firms are adopting AI and already seeing productivity effects, while growing use of generative AI is expected to intensify strategic dependence on foreign technology.

That produces a form of sovereignty very different from Beijing’s current ambition.

Beijing’s policy tries to increase domestic capacity across the conversion chain: models, frameworks, protocols, compute, marketplaces, devices and firms.

Europe could instead make technological dependency safer, more legible and more governable without making it substantially smaller.

That is not trivial. A market capable of imposing conditions on foreign suppliers possesses power. Companies that cannot ignore Europe must respond to Europe.

But regulatory leverage has limits. A jurisdiction that can dictate how a foreign technology is used is not in the same position as one that can replace the technology if access disappears.

The long-term success of Europe’s AI strategy therefore cannot be measured by the size of its rulebook or even by the global influence of those rules.

The real evidence will be economic: stronger European deployment capability, more competitive domestic suppliers and infrastructure, broader productivity gains, and less dependence on a small number of foreign technology layers.

Wrap Up: What This Means for Enterprises—and Countries

For enterprises, this geopolitical competition is already becoming an architecture problem.

Consider a European manufacturer using an American model running on an American cloud inside a supplier-risk agent. The agent reads contracts, combines them with shipping and sanctions data, evaluates disruption scenarios and routes recommendations into procurement.

Its capabilities may look like a single AI solution from the business user’s perspective.

Its dependencies are anything but singular:

• The model provider controls one layer.

• The cloud provider controls another.

• External standards may determine how agents discover tools or communicate.

• European law can change the conditions under which the system operates.

• Foreign export controls or commercial decisions can affect the availability of infrastructure.

• The enterprise itself owns the integrations, business context and operational consequences.

This makes “Which model should we use?” an increasingly inadequate strategic question.

Enterprises need to understand which external actors can change the conditions under which important AI systems operate, which dependencies would be difficult to replace, and which capabilities must remain portable or under enterprise control. That was the practical conclusion of the Beijing analysis, and the European case makes it broader: leverage can enter the architecture through vendors, standards and infrastructure, but also through jurisdictions.

Countries face the same problem at a different scale.

Counting frontier models is an incomplete measure of AI power. So is counting regulations.

The more useful map follows the entire route from intelligence to economic output: chips, compute, models, capital, standards, runtimes, distribution, enterprise adoption, industrial capacity and access to markets.

The United States, China and Europe currently possess very different combinations of those assets.

America’s upstream position remains formidable. Beijing is making an explicit bid to build more of the machinery that converts intelligence into production. Europe is trying to use the scale and institutional weight of its existing economy to shape the conditions under which that conversion occurs, while increasingly investing in the infrastructure needed to capture more of it itself.

None of these strategies has won.

But they suggest that the phrase “AI race” is becoming less useful if it implies one finish line.

The contest is spreading across the chain between intelligence and economic power.

Europe may have entered that contest from a weaker technological position. The mistake would be assuming that leaves it with no pieces to play.

What remains to be seen is whether it can turn the pieces it does have—market scale, industrial depth, legal authority and growing infrastructure investment—into productive capacity before regulation becomes better at organizing dependency than reducing it.

Put These Ideas to Work

Want to put these ideas to work? Subscribe free to The Sovereign AI Enterprise and receive the Field Guide: five decisions to help you examine what your AI systems can do, which dependencies matter, and whether you can account for their actions. You’ll also receive my ongoing analysis of enterprise AI, governance and technology sovereignty.

1. The Corporate Card Effect

Consider the ordinary corporate credit card. The rules are usually simple:

• Don’t abuse it.

• Keep the receipts.

• Use good judgment.

A traveler on company business rarely spends the way he would if the money were his own. He books the convenient hotel near the client even when it is the most expensive option. He orders the better dish. He takes the car instead of the shuttle because twenty minutes of waiting feels more costly than the fare.

None of this is reckless or irresponsible. It is simply rational when someone else is paying.

Economists call the resulting gap moral hazard: the decision-maker and the cost-bearer are not the same person. The spending that follows is often larger than anyone planned, yet every individual choice remains locally sensible.

Moral hazard describes an incentive structure, not dishonesty.

Subscribe now

Enterprise AI is creating the same separation at scale:

• A seller asks an assistant to rewrite a proposal five times.

• A developer has a coding agent explore four alternative implementations.

• A product manager has every meeting, Slack thread, and design document summarized because the tool is a click away.

• A support workflow retries a classification until the confidence score crosses an arbitrary threshold.

Each action saves someone time, feels nearly free, and easy to justify. But none of them is free once the organization multiplies them across thousands of employees and hundreds of workflows.

The article that follows is not about prompt engineering, token optimization, or model selection. These are worthwhile engineering practices: knowing how to make individual model calls cheaper, using shorter prompts, trimming context windows, and routing simple requests to smaller models.

This article is about what happens when individually rational decisions begin to cost the enterprise real money, and the people making the decisions never see the bill. While at the same time, the organization has almost no intuition for how inference is consumed across thousands of employees, applications, and increasingly, autonomous workflows.

2. We’ve Seen This Before

Cloud computing offered the same early illusion. Being able to provision infrastructure in minutes was a breakthrough. Developers could spin up a test environment, a database, and a Kubernetes cluster in minutes.

But while each resource looked modest, the monthly bill did not. A test environment here, a database there, storage for a proof of concept, another Kubernetes cluster for testing. Then, finance discovered workloads no one owned. Operations found environments no one remembered creating. Development teams provisioned faster than any central process could track.

This was the beginning of a new management problem. While the technology worked exactly as promised, the economics had not caught up.

The industry eventually built an entire discipline—FinOps—around the problem: tagging standards, ownership rules, lifecycle policies, chargeback models, and dashboards that made consumption visible. The underlying server prices did not fall dramatically. What changed was the organization’s ability to see, attribute, and govern the resource.

The industry is already beginning to talk about Token Economics: budgeting token usage, forecasting spend, routing requests to less expensive models, and enforcing rate limits. Those are useful platform capabilities, much as cloud cost dashboards were useful during the rise of public cloud. They answer where tokens are consumed. They do not answer whether the reasoning performed by a workflow is economically justified.

Inference is following the identical path. Every tool call, retrieval, evaluation, and retry is a unit of reasoning.

For a large organization the aggregate cost of that reasoning is becoming a material operating expense. Most enterprises still treat it the way they once treated untagged cloud spend: as something that appears on a vendor invoice rather than as a production resource that must be owned, measured, and optimized.

3. Reasoning Is Becoming a Production Resource

Enterprises already manage electricity, network bandwidth, storage, and compute capacity as shared production inputs. They have owners, budgets, dashboards, and continuous improvement cycles. Reasoning is joining that list.

A salesperson preparing for a client meeting can now have an assistant research the account, summarize recent support cases, draft an agenda, and write the follow-up notes. A developer working in an unfamiliar code base can ask an agent to explain design choices, compare alternatives, review the pull request, suggest tests, and generate documentation.

The same pattern appears in legal review, procurement, claims handling, finance, and marketing. The work is useful, so organizations encourage it. Once encouraged, it becomes embedded. Once embedded, it becomes infrastructure.

Electricity powers physical work.

Cloud infrastructure executes software.

Reasoning now performs cognitive work: planning, drafting, comparing alternatives, retrieving evidence, classifying requests, evaluating options, and generating recommendations. As those activities become embedded inside production workflows, reasoning becomes a shared production resource rather than an occasional user interaction.

The shift from occasional assistance to continuous consumption changes the economics. Chatbots waited for a human prompt. Agents do not. They can decide to retrieve more context, evaluate additional alternatives, or retry a step without waiting for another instruction. The volume of reasoning therefore grows with the agent’s ambition, not just with the user’s deliberate choices.

But while inference is moving into the same category as electricity, network bandwidth and cloud infrastructure, most organizations haven’t started managing it that way.

Today’s dashboards can usually report how many AI licenses were purchased or how many users logged in last month. But those metrics say very little about how much reasoning the enterprise consumed, where it was consumed, or whether it created proportional business value.

4. Agents Change the Economics

As long as a human initiates every interaction, the cost of reasoning remains somewhat visible. The seller opens the assistant. The developer types the question. The lawyer uploads the contract.

Agentic systems remove that gate.

A procurement agent can compare vendors, request missing documentation, evaluate contract language, and prepare a recommendation before a buyer opens the file. A software engineering agent can explore multiple implementation paths, write tests, review its own work, fix the defects it finds, and re-run the process until it meets an internal standard. A claims agent can retrieve policy language, summarize evidence, classify exceptions, draft a decision, check consistency with prior cases, and generate an explanation for human review.

In each case the user experiences a single conversation while the back-end may execute dozens of inference operations.

As agents become more capable, workflow designers must decide how much reasoning an agent should perform, when it should retrieve more context, how long it should continue searching, and where another retry stops improving the outcome.

Those decisions are no longer made explicitly by employees. They become properties of workflows, orchestration logic, evaluation strategies, and agent design. That changes the nature of enterprise AI consumption.

The economic question is how much reasoning is worth performing before the work is handed to another agent or to a human—how long to search, how many alternatives to evaluate, how many retries to attempt. Those decisions are now made inside the workflow rather than by the person who ultimately pays the bill.

Cloud computing eventually taught enterprises that infrastructure consumption had to be designed, measured, and continuously improved.

Agentic AI is introducing the same challenge for reasoning.

5. The Next Discipline: Reasoning Economics

Six months after an agentic workflow is approved, the system that was reviewed no longer exists in the same form.

A newer model plans across tools more effectively. An additional data source is connected. A new write operation is exposed so agents can maintain records without opening a separate application. A class of low-value exceptions is automated.

The individual changes do not look like a redesign. But together they alter the volume and the path of reasoning the organization is purchasing.

Declared usage remains the same—the same agents, the same high-level permissions, the same intended outcomes. Effective consumption rises because the connections between capabilities have multiplied.

The production system has quietly expanded the number of inference steps that stand between a request and a result.

Yet, most organizations still measure AI the way they measure software adoption. They need to understand how much reasoning the workflow consumes, where it consumes it, and whether the outcome justifies the expense.

The same visibility can support financial objectives, latency targets, infrastructure capacity planning, and sustainability goals. But those all begin with the same question: which reasoning is actually creating value?

I call this emerging discipline Reasoning Economics. Governance establishes what an agent is allowed to do. Reasoning Economics examines how much reasoning a workflow consumes, where that reasoning creates measurable business value, and where additional inference no longer improves the outcome.

Organizations that develop both will have an early advantage: one protects the enterprise, and the other helps the enterprise operate efficiently as reasoning becomes part of everyday work.

6. Applying Reasoning Economics

The practical response is the same practice that works for consequential actions in agent governance: start with the outcome the enterprise cares about and work backward.

Choose one production workflow that already uses AI. Ask three questions.

First, what actually happens between the request and the outcome? Map the models invoked, the information retrieved, the tools called, the retries, the evaluations, and the human interventions. If the path cannot be described, it cannot be governed.

Second, which business result is the reasoning supposed to improve? Measure the workflow, not the agent. Track claims processed, proposal cycle time, code quality, or whatever the organization actually values. The value of any given unit of reasoning is the incremental improvement it produces in that result.

Third, where is reasoning being spent without improving the outcome? Remove or constrain the step and observe what happens. If accuracy declines, more cases require human review, or cycle time lengthens, the reasoning is earning its keep. If the metrics remain unchanged, the step is pure moral hazard—rational for the agent or the local user, expensive for the enterprise.

This approach yields a far stronger optimization target than counting tokens or active users. It also makes the boundary between useful and wasteful reasoning visible enough to manage.

7. Sovereignty Means Knowing What the Reasoning Is Costing

Today most organizations still measure adoption the way they measured the first wave of enterprise software: licenses purchased, users logged in, assistants launched, pilots running. Those metrics will matter less as AI moves into the core of how work is executed. The next competitive advantage belongs to the companies that can see the flow of reasoning through their processes—the volume, the model cost, the retries, the marginal return—and that can redesign the workflows accordingly.

Two enterprises can deploy the same models, the same agents, and the same orchestration platform. Their competitive advantage will increasingly depend on something else: how deliberately they design, measure, and continuously improve the reasoning embedded inside their workflows.

The enterprise will ultimately pay for every unit of reasoning it consumes—through operating cost, infrastructure capacity, latency, and increasingly, energy. The question is whether it also understands which reasoning is earning its cost.

Want to apply these ideas to your own enterprise?

I’m developing a small founding cohort for readers who want to apply the frameworks behind The Sovereign AI Enterprise to real architecture, governance, operating-model, and strategy decisions.

Subscribers will get the first invitation and a chance to help shape the program. Subscribe free to join the founding audience.

This article examines the enterprise implications. A future article will explore the broader macroeconomic and geopolitical consequences.

The meeting had been scheduled to determine whether the company’s recruiting technology vendor was ready for the EU AI Act.

Klara led talent systems for a manufacturer operating in Europe. Her team had purchased an AI assistant to summarize résumés, retrieve recruiting policies, and draft interview questions. The vendor’s documentation was clear: the product supported administrative work. It was not intended to rank candidates or influence employment decisions.

The company then extended the system by connecting it to the applicant-tracking system. HR supplied job requirements and historical hiring data. The AI team added instructions that compared candidates and generated fit scores. Recruiters could sort applications by those scores, and candidates above a threshold eventually moved automatically into a review queue.

Nobody trained a new model or launched a commercial product. Each change moved through the organization as normal implementation work.

Now legal wanted the technical documentation, conformity evidence, and risk controls behind the candidate-ranking system. The vendor reviewed the architecture and gave an answer nobody expected:

“That is not the system we provided.”

The vendor had supplied a summarization and drafting assistant. Klara’s company had added the data, prompts, scoring logic, integrations, workflow authority, and employment purpose that turned it into something else.

The vendor owned the model. But the company’s HR owned the process. IT owned the integrations. The AI team owned the prompts. Procurement owned the contract. Every group could explain its part, but no one could answer the larger question:

This scenario is hypothetical, but the regulatory problem is not. The EU AI Act does not reserve the word provider for companies that sell models or software. An enterprise can encounter the provider role through a system it develops or has developed for its own use. But a deployer can also become the provider of a high-risk system when it substantially modifies an existing system or changes its intended purpose so that it becomes high-risk.

Klara’s company thought it had configured a vendor tool. Instead, it may have assembled an internal AI product.

1. Provider Does Not Mean Vendor

Most companies enter an AI procurement with a simple picture of the market: The technology company provides the product; the enterprise buys and deploys it.

The EU AI Act draws the boundary differently. A provider is an organization that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. “Putting into service” includes first use for an organization’s own purposes in the European Union. An employer, manufacturer, university, bank, or public agency does not have to sell AI to fall within that definition.

That does not mean every enterprise configuring software becomes a provider. A company using a system under its authority and within the supplier’s documented purpose may remain a deployer, with obligations such as following the instructions, assigning human oversight, and monitoring operation.

Klara’s company had moved beyond that clean arrangement. The vendor designed an assistant for administrative recruiting support, but the enterprise commissioned the integrations, selected the data, defined the scoring criteria, and decided what would happen after the system produced a recommendation.

The foundation model still came from outside the company. The operational recruiting system did not.

An enterprise can therefore be the deployer of one component while potentially becoming the provider of the system assembled around it. Provider is not a permanent category of company. It is a relationship to a particular system.

Procurement can identify who supplied the model, licensed the application, completed the integration, and approved the business case. It is less prepared to determine who owns the complete system after those elements have been combined and changed.

Klara’s team entered the review asking whether its vendor could support a high-risk AI system. But the question which emerged was whether the vendor still provided the system under review.

2. The System Changed Without the Model Changing

The recruiting assistant did not become consequential in a single release.

It began by summarizing applications. Recruiters still read the source material and decided who would advance. Then the company added job descriptions and asked the assistant to compare experience with role requirements. A scoring prompt followed. The scores were written into the applicant-tracking system, recruiters could sort candidates from highest to lowest, and candidates above a threshold were later moved automatically into a review queue.

Each request looked incremental: a prompt revision, a data connection, a user-interface enhancement, an API call, a workflow rule. Together, they changed the system’s purpose and consequence.

The original assistant helped recruiters work with information. The expanded system analyzed candidates, imposed a comparative structure on them, and influenced who received further consideration. Its inputs, outputs, integrations, and operational effect had changed even though the model underneath them had not.

That distinction is key because Annex III includes systems intended to analyze and filter job applications or evaluate candidates among its high-risk employment uses. The Act also provides a narrower route out of high-risk classification for certain procedural, preparatory, or limited support systems that do not materially influence a decision. Systems that profile natural persons remain high-risk.

A résumé summarizer used only to organize information may have a credible argument that it performs a preparatory task. Candidate scoring, ranking, and automatic progression make that argument harder to sustain. The classification would still depend on the system’s actual function and context, but the enterprise could no longer rely on the harmlessness of the original use.

The model-centric view hides this transition. It treats prompts, retrieval sources, business rules, permissions, and workflow automation as implementation details around the product. But operationally, those elements determine what the product becomes.

The same model can support a policy assistant, a credit workflow, or a recruiting system. The surrounding architecture determines which evidence it receives, which decisions it influences, and what action follows.

Klara’s company had governed every enhancement as configuration because the word implied that the vendor continued to design the product while the enterprise adjusted settings around the edges. That description no longer matched reality.

The model had stayed the same. The product had not.

3. The Provider Boundary Can Move After Deployment

Most companies assign regulatory roles during procurement. The vendor is recorded as provider. The enterprise is recorded as deployer. Contracts and reviews are built around that initial division.

The AI Act does not assume those roles remain fixed.

Article 25 states that a deployer or other third party is considered the provider of a high-risk AI system when it places its name or trademark on the system, makes a substantial modification to a high-risk system, or changes the intended purpose of a system that was not high-risk so that it becomes high-risk. In those circumstances, the original provider is no longer treated as the provider of that specific system.

Intended purpose includes the use, context, and conditions specified by the provider in instructions, sales materials, statements, and technical documentation. It is more precise than a broad claim that a product improves recruiting productivity.

The vendor in the example had documented an assistant for administrative support. Klara’s company introduced candidate evaluation and workflow progression after deployment and used those functions inside a process affecting access to employment.

That difference does not settle the legal analysis. The company would still need to establish the system boundary, determine whether the new function materially influenced selection, and assess whether the change had been anticipated in the original design and assessment. It does make one assumption unsafe: the original vendor remains the provider because its model still powers the system.

When a third party changes a system’s intended purpose so that it becomes high-risk, Article 25 can transfer provider obligations to that party. The original provider is generally expected to cooperate, but that requirement may not apply in all cases.

The change that moves the provider boundary can enter through the backlog as an ordinary request: connect another data source, add a score, let recruiters sort the results, advance the strongest candidates automatically.

HR sees process improvement. IT sees integration. The AI team sees prompt work. Procurement sees an existing supplier. Each group reviews its component while responsibility changes at the level of the assembled system.

By the time legal asks who the provider is, the enterprise may already have crossed the boundary.

4. Configuration Is Becoming Product Design

The boundary is difficult to see because enterprises still divide technology work into two categories:

That separation worked when configuration meant selecting fields, setting permissions, or adjusting workflow rules inside a product whose essential behavior remained controlled by the supplier. AI weakens that division.

The recruiting assistant did not arrive with its complete operating purpose encoded inside the model. Its behavior emerged from instructions written by the internal AI team, data supplied by HR, tools exposed by IT, actions available in the applicant-tracking system, and rules governing human review:

• A new data source altered the evidence the system considered.

• A scoring prompt altered how candidates were compared.

• An integration altered where the output appeared.

• A workflow rule altered what happened next.

None of these changes required modifying the model weights, but they determined the function and consequence of the system placed into operation. The vendor contract therefore cannot define or manage the complete product boundary.

I explored the external side of this problem in an earlier article on Beijing’s agent strategy: the infrastructure around a model can determine whose identity, protocols, runtimes, registries, and evidence systems govern how an agent operates. The EU AI Act exposes the internal side. The same enterprise that depends on someone else’s operating infrastructure may become responsible for the consequential system it assembles on top of it.

In Klara’s case, that architecture crossed the model service, candidate records, job requirements, system instructions, scoring logic, identity controls, workflow automation, recruiter review, and the applicant-tracking system. Each component had an owner. The system existed only in their composition.

Enterprises govern those components separately:

• Procurement reviews the vendor.

• Security reviews access.

• Architecture reviews integrations.

• HR reviews the process.

• The AI team evaluates behavior.

The complete system can change materially while every component passes its local review.

That is the wider weakness exposed by the Act. Responsibility is assigned according to organizational ownership of the parts, while consequence emerges from how the parts work together.

Klara’s company treated the workflow as an implementation of somebody else’s product. It had also made the decisions that defined what the resulting system was designed to do.

Configuration had become product design without the organization recognizing itself as the product designer.

5. Provider Is a Lifecycle, Not a Label

The legal team’s first instinct was to update the responsibility matrix. If the company had crossed into the provider role, it needed a new classification and a list of obligations.

That made the problem sound administrative.

But provider responsibility for a high-risk system reaches much further. The Act expects providers to maintain compliance, operate a quality management system, preserve documentation, manage changes, complete applicable conformity work, take corrective action, and support post-market monitoring throughout the system’s lifecycle.

Even defining the system was difficult. The vendor documentation described an administrative assistant. The project charter described a productivity initiative. The latest release notes described candidate scoring and automated progression. No authoritative record described the purpose of the complete system in production.

The evidence was equally fragmented. The model version sat in the AI platform. Prompts were stored in a development repository. Candidate data and outcomes lived in the applicant-tracking system. Workflow changes appeared in service tickets. Supplier limitations were buried in contract documents. Evaluation results had been produced before launch, but no process connected them to later changes.

A compliance exercise assembles records at a particular moment. A lifecycle preserves the relationship between purpose, architecture, versions, evaluations, behavior, and business outcomes as the system evolves:

• When the scoring prompt changes, the enterprise should know which evaluation was repeated and who approved the result.

• When a new data source is added, it should know how the source affects risk and performance.

• When recruiters repeatedly override recommendations, that pattern should reach the people responsible for the system.

• When the vendor updates the model, the company should be able to determine whether the complete workflow still behaves within its approved boundaries.

This cannot live entirely inside legal or compliance. It depends on engineering, architecture, business operations, risk, product management, supplier management, and the systems of record that capture what happened after a recommendation was made.

The architecture has to produce the evidence by connecting model and prompt versions to releases, execution traces, evaluations, human interventions, workflow outcomes, incidents, and approved changes. The objective is not a larger repository of documents. It is a reconstructable system history.

The Act may be the reason an enterprise first asks for that capability. But the operating need extends further: any organization allowing AI to influence consequential work needs to know which system is operating, how it has changed, and who can intervene.

Provider status gives that responsibility a legal form. The management problem already exists.

But the enterprise implications are only half of the story. The same regulation that may require companies to operate internal AI systems more like products could also reshape competition between nations. Europe may gain greater control over AI deployment while becoming more dependent on the foreign providers capable of meeting those requirements. That paradox—with its macroeconomic and geopolitical consequences—deserves a separate article, one I’m already drafting.

6. Projects End. Internal AI Products Do Not.

Klara’s recruiting assistant had been delivered through a successful project. The business case was approved, the vendor selected, the reviews completed, the application tested, and the recruiters trained. The project team transferred the system to operations and moved on.

The process assumed that the important design decisions occurred before deployment. After launch, the system would be maintained through support, vendor updates, and controlled enhancements.

But then, HR changed selection criteria. The AI team revised prompts. IT added integrations. Recruiters developed new ways of using the score. The vendor updated the model. Each change altered part of the system, but no standing owner decided whether the complete product still matched its approved purpose.

The ownership model divided responsibility by function:

• HR owned recruiting.

• IT owned the application.

• Data science owned the scoring logic.

• Security owned access.

• Procurement owned the supplier relationship.

• Legal interpreted the regulation.

• Risk reviewed the use case.

Everyone owned something important. Nobody had continuing authority over the system as a whole.

Operating an internal AI product does not necessarily require a new executive title, but it does require durable decision rights. Someone must control the approved purpose, determine when a change requires renewed classification or evaluation, require evidence before release, and restrict or retire the system when its behavior can no longer be defended.

That owner needs visibility across technical and organizational boundaries. Traditional project governance is poorly suited to this problem because accountability weakens after delivery. Traditional application ownership is incomplete because the consequential behavior can span several platforms, suppliers, data sources, and business processes.

The EU AI Act is forcing enterprises to confront a category of system they have rarely been organized to own: an internal product that remains under active design while it is already operating.

Companies outside the technology industry may need product-grade disciplines for AI systems they never intend to sell.

7. The Decision Before the Next Change Request

Klara’s company traced the problem back to a series of individually reasonable approvals. No single decision created the final system. The boundary was crossed through accumulation.

Before a material change to a consequential AI system is released, the enterprise needs to reconsider the provider boundary. It should compare the supplier’s documented intended purpose with the purpose the organization now expects the system to perform. It should determine whether the change moves the system into a high-risk use, whether the supplier anticipated it, and who now controls the complete system placed into operation.

It also needs to test ownership. Who can produce the current architecture, evaluations, release history, execution evidence, and supplier documentation? Who approves the change? Who remains accountable after deployment? Who can restrict or retire the system?

Those questions belong inside architecture governance, change management, AI governance, supplier management, and business-process ownership. Asking them only during a legal review is too late.

As it turns out, the decisive moment was not the original purchase, but a subsequent feature request.

Wrap Up: The AI Providers That Never Entered the AI Market

Klara’s company has three broad choices:

1. It can return the assistant to the vendor’s documented purpose.

2. It can redesign the workflow so the AI no longer performs the consequential function.

3. It can consciously assume responsibility for the system it assembled and build the lifecycle needed to operate it.

Other enterprises will face the same choice.

Some of Europe’s next AI providers may be employers, manufacturers, banks, universities, retailers, and public institutions that have never sold an AI product. They will have assembled one from a supplier’s technology and their own data, instructions, integrations, permissions, and decisions.

The surrounding architecture therefore creates two questions enterprises must answer together: who controls the conditions under which the system operates, and who becomes responsible for what that system does?

The original system had a provider. The operational system does too. Enterprises need to know whether those are still the same organization.

Two English words buried inside a Beijing policy document deserve more attention than another model benchmark: Harness Engineering.

They appear in 《北京市关于加快智能体引领发展的若干措施》, ten measures published by Beijing’s municipal government on July 23. Measure Two was most interesting to me because governments usually write industrial policy around chips, energy, factories, research, and infrastructure. Beijing has now written it around context engineering, task persistence, multi-agent coordination, middleware, runtimes, toolchains, identity, interoperability, skills markets, software stores, and AI operating systems. The same package reaches into one-person companies (OPCs), compute vouchers, outcome-based services, intelligent devices, open-source communities, and overseas distribution.

I have been writing about the harness as an enterprise architecture issue: the layer that turns model reasoning into governed work. But Beijing is treating this same layer as an industrial-policy issue.

The document is municipal, so it should not be inflated into a complete statement of Chinese national doctrine. Yet it still carries geopolitical weight. The measures implement national AI and agent directives and show how one major Chinese policy center is trying to turn those directives into an industrial system.

What stands out is how far down the stack the state has chosen to reach.

The machinery around an agent determines whether model intelligence survives contact with real work. It decides what the agent sees, what it remembers, which tools it can call, how long a task can continue, what happens after failure, where the result lands, and whether the same capability can be reused across companies and devices.

Beijing’s policy reads like a bet that the next phase of AI power will depend on how effectively a country can organize that conversion from intelligence into production.

1. The Model Race Is Only the Visible Contest

Beijing has not lost interest in foundation models. The first measure targets online learning, autonomous improvement, long-horizon tasks, complex reasoning, planning, memory, tool use, world models, and multi-agent collaboration. As if to illustrate this point, around the time the policy appeared, Beijing-based Moonshot AI released Kimi K3, an open-weight, 2.8-trillion-parameter model with native multimodality and a one-million-token context window. The city cited K3 among its recent foundation-model advances when presenting the measures.

The model remains strategic, but it is no longer a sufficient unit of analysis. A country can produce capable models and still struggle to convert them into broad economic output. Every enterprise may have to build its own context layer, preserve its own task state, connect its own tools, define its own agent identities, create its own evaluation methods, and solve the same integration problems repeatedly. The intelligence exists, but the cost of making it operational remains scattered across thousands of firms.

The opposite is also possible. Common protocols, reusable skills, compatible runtimes, shared compute, marketplaces, and trusted deployment patterns can lower the cost of applying models throughout an economy. Models from several providers can move through the same operating environment. A capability developed in one company can be packaged for another. Developers learn conventions that make the next system easier to build than the last.

The phrase I would use for this is AI conversion capacity: the technical and institutional ability to turn model intelligence into repeatable work, products, firms, and measurable economic output.

This is also an important geopolitical consideration because model leadership can be temporary: A benchmark lead can disappear with the next release. But infrastructure, standards, developer habits, device integrations, and marketplaces can persist for years. They accumulate switching costs and network effects even when the underlying models change.

The policy’s language around “independently controllable” protocols, frameworks, and toolchains also points inward. Beijing wants domestic companies to operationalize agents without relying entirely on systems designed, governed, or withdrawn elsewhere.

That is a sovereignty objective.

Furthermore, once the same infrastructure reaches a large domestic installed base, it can become something more: a platform from which Chinese technical conventions travel into other markets.

2. Kimi K3 Makes the Missing Layer Visible

Kimi K3 is useful here because its release exposes the difference between a model’s potential and an agent’s usable capability.

Moonshot presents K3 as a frontier model for long-horizon coding, knowledge work, reasoning, and tool orchestration. But its published evaluation results are repeatedly tied to specific agent harnesses. Moonshot also instructs developers to preserve the model’s complete reasoning and tool-call history across turns, and recommends Kimi Code as the framework in which K3 works best. Those details help determine whether the capability shown in an evaluation survives inside an actual agent system.

The enterprise version of that dependency now starts to take shape:

• A million-token context window can hold years of supplier contracts, but it does not decide which contract is current, which amendment superseded it, or whether a regional exception applies.

• Tool-use capability can reach a procurement system, but it does not decide whose identity the agent uses, which fields it may change, or which approval must remain human.

• Long-horizon reasoning can build a supplier-risk case over several hours, but it does not guarantee that task state survives a failure, that the agent notices a sanctions-data update, or that its recommendation reaches the workflow where procurement can act on it.

While the model supplies reasoning capability, it is the harness that sets the operating conditions around it. That makes the harness more strategically valuable as models improve or commoditize.

If companies can change the underlying model while retaining their agent identity scheme, skills, tool interfaces, runtime, evaluation methods, and marketplace, the surrounding system becomes more durable than any single model.

The provider or entity that shapes that system gains influence across models rather than depending on one of them to remain dominant.

China would not need every foreign enterprise to use Kimi K3 or any one of their models for this strategy to matter. Chinese-origin protocols, skill formats, agent registries, runtimes, or device operating systems could spread while the models running inside them came from several countries. The model race remains important, but the emerging opportunity is to influence the environment in which many models become operational.

3. Standards Are Where Architecture Becomes Power

The geopolitical objective more clearly emerges in the standards provisions of the document.

Beijing’s measures call for domestically controlled agent-interconnection protocols, development frameworks, foundational toolchains, and standards covering interfaces, identity, performance evaluation, and security. They support agent-development platforms, software stores, AI operating systems, open-source frameworks, terminal operating systems, and hardware reference designs. They also call for globally influential open-source communities and country-specific overseas expansion through the China-SCO AI Application Cooperation Center.

China has already released a seven-part national guidance-standard series for agent interconnection. It covers architecture, identity codes, identity management, capability description, cross-domain discovery, collaborative interaction, and tool invocation. More than 2,000 agent identity codes had been issued when the standards were announced. An English version was presented internationally, with Russian and Arabic versions planned and broader promotion across partner regions.

Together, these categories describe the language through which agents interact:

• Identity standards influence how an agent proves who it is.

• Capability descriptions shape how it declares what it can do.

• Discovery standards determine how agents and tools find one another.

• Tool-invocation protocols carry model decisions into enterprise applications, workflows, vehicles, robots, and other devices.

• Evaluation and certification standards influence which systems are considered safe, trusted, or ready for procurement.

A foreign power does not need exclusive ownership of those standards to gain leverage from them. Influence can come from maintaining the reference implementation, operating the registry, defining certification, controlling a marketplace, concentrating developer expertise, or establishing the first large installed base. Then, once companies have built skills, workflows, and devices around those conventions, changing them becomes expensive even when the published specification remains open.

Open source can make that strategy more effective. It reduces the cost of adoption, gives developers working code, and lets foreign companies adapt a framework without waiting for a commercial agreement. The code may be visible while practical influence remains concentrated in maintainers, release priorities, registries, testing suites, update channels, and associated marketplaces.

The likely objective is therefore broader than exporting Chinese models. Beijing appears to be creating a path through which Chinese-origin conventions can become part of how agents are built, identified, connected, evaluated, and distributed elsewhere.

This policy shows that Beijing intents to compete for the rule-setting power of turning those conventions into global standards.

Washington also treats this layer as strategic. NIST’s 2026 AI Agent Standards Initiative promotes industry-led standards, open protocols, agent identity, and participation in international standards bodies, while explicitly connecting that work to maintaining U.S. dominance at the technological frontier.

Major powers are already treating the agent layer as strategic terrain.

For enterprises, the danger is structural:

• A protocol can be technically open and still create path dependence.

• An identity system can embed assumptions about which authorities are trusted.

• A certification regime can define what evidence counts.

• A registry or marketplace can determine which agents and skills are discoverable, approved, or removed.

• Competing Chinese, American, European, and vendor-led standards could also split markets into technical blocs, forcing global enterprises to reconcile incompatible identity, security, audit, and data requirements.

The geopolitical risk is not simply that a Chinese agent enters an enterprise system, but that the rules governing machine action harden around ecosystems whose strategic direction, certification regime, and legal authority sit outside the enterprise’s control.

4. Beijing Is Trying to Create an Agent Economy

Standards alone do not create an economy. Firms have to form, developers need infrastructure, buyers need reasons to adopt, and someone has to decide what is being sold.

The remaining measures try to address those conditions together.

Beijing’s support for OPCs, or one-person companies, focuses on the operating environment around firms in which one founder can coordinate substantial machine labor. The policy proposes low-cost compute, incubation, financing, intellectual-property services, dedicated OPC communities, links to larger enterprises, simplified registration, one-click filing, and automatically generated standardized corporate documents.

Around those firms, Beijing wants shared capability platforms, skills markets, software stores, public compute, compute vouchers, proposed Token vouchers, and agent-service vouchers. It wants agents embedded in phones, glasses, wearables, robots, vehicles, and other intelligent devices. Qualifying products can enter existing purchase-support programs. Selected technical, common-platform, and demonstration projects may receive support of up to RMB 100 million (USD$14.8 million).

The economic logic becomes clearer when the measures are read together:

• Subsidized compute lowers the cost of experimentation.

• A skills market gives small firms capabilities they do not have to build themselves. Common protocols make those skills easier to reuse.

• Devices create distribution.

• OPC services increase the supply of specialized businesses.

• Open-source frameworks lower adoption friction at home and abroad.

The commercial unit is also changing. The policy names Token as a Service, Agent as a Service, and Result as a Service, and encourages a move from billing based on Token consumption toward value-based pricing. It asks industry groups, research institutions, companies, and Beijing’s municipal statistics bureau to develop measures around quality, invocation volume, and conversion efficiency.

But results-based pricing is much harder than the label suggests. A logistics agent may recommend a better route, but fuel prices, port conditions, human approvals, carrier performance, and demand changes all affect the eventual outcome. A provider can optimize for a contractual metric while making the broader operation worse. Retries, failed attempts, reversals, and human intervention still consume resources even when the promised result never arrives.

Still, that difficulty does not make the policy language trivial: it shows Beijing trying to move the economics of agents beyond API consumption. The state wants agent activity to become measurable enough to support pricing, subsidies, investment, and industrial monitoring. In effect, it is trying to reduce friction at every point where model capability becomes economic activity: obtaining compute, finding a skill, forming a company, reaching a device, completing a task, and charging for the result.

5. The Boardroom Question Is Contestability

Enterprises neither can nor should imitate Beijing’s industrial policy. But they do need to understand the architecture it is trying to shape.

Consider a supplier-risk agent used by a global manufacturer. It reads contracts and supplier records, combines them with shipping and sanctions data, evaluates disruption scenarios, recommends alternatives, and routes a decision into procurement. The model is the visible intelligence. But the deeper dependencies sit in the standards and services around it.

Much of the agent’s operating authority sits below the model. External systems may issue its identity, define how it describes its capabilities, control where it discovers tools and skills, and determine how approved actions reach procurement. The same ecosystem may also hold task state, evaluation evidence, and decision logs. That creates leverage: a provider decision, registry change, or government restriction can change how the agent operates, or whether the workflow continues at all.

The practical output is a contestability map.

Some layers can be adopted when the specification is transparent, several credible implementations exist, and substitution has been tested rather than assumed. Other layers should remain portable, with the enterprise able to export task state, skills, policies, evaluations, and logs in a usable form. Sensitive protocols can be isolated behind an enterprise-controlled gateway that preserves identity, policy enforcement, and audit even when the external ecosystem changes. Layers that carry institutional authority may need to be controlled directly, especially agent identity, high-impact tool authorization, critical runtime continuity, and the evidence required to explain consequential actions.

The classification should not follow nationality alone. A Chinese-origin protocol may be open, well-governed, and genuinely portable. On the other hand, a U.S. vendor platform may be proprietary, concentrated, and difficult to replace. That’s not to say that origin doesn’t matter – it does, because jurisdiction, export controls, state authority, and political pressure affect continuity. The architecture should determine how much leverage those external forces acquire inside the enterprise.

The board should be able to answer a more precise question than which country or vendor it trusts:

That question changes sourcing and design decisions: it favors adapters over hard-coded dependencies, enterprise-controlled identity over marketplace identity, portable skills over proprietary memories, independent evidence retention over provider-only logs, and degraded operating modes planned before a geopolitical or commercial disruption occurs.

6. Wrap Up: A Bid for Influence, Not Proof of Victory

Beijing may not succeed.

There are many uncertainties that limit what can be concluded from the document:

• Municipal funding can create projects without creating durable markets.

• Open-source frameworks can fail to attract maintainers.

• Skills marketplaces can remain shallow.

• Result-based pricing can collapse under attribution disputes.

• Foreign companies may reject Chinese identity or certification regimes.

• Competing standards may fragment the agent economy before any one ecosystem reaches decisive scale.

But whether Beijing wins does not change what Beijing has chosen to coordinate.

The path from model intelligence to economic output now sits inside one policy frame:

1. Kimi K3 represents continued pressure at the model layer.

2. Harness Engineering addresses the operating machinery around it.

3. Protocols, standards, open source, devices, and overseas channels create a route to ecosystem influence.

4. OPC support, vouchers, marketplaces, and outcome pricing try to build the firms and demand that would make the system economically durable.

While no country has secured control of the future agent stack, Beijing has made clear that it intends to compete over who shapes it.

The visible AI race will continue through model releases, benchmark results, chips, and compute.

The more durable contest may develop in the subtler layer underneath: the standards and infrastructure that decide how models enter institutions, how agents act across systems, and whose rules travel with them.

1. The Agent Wasn’t Given Internet Access. It Found Some.

The agent was supposed to be contained.

OpenAI was testing advanced models on cybersecurity tasks in an environment designed to restrict where they could go. The models were operating autonomously toward an objective: solve the challenges. They were not supposed to have unrestricted internet access, much less access to Hugging Face’s production infrastructure.

They found a way out anyway.

According to OpenAI, the models discovered a vulnerability in the infrastructure supporting the evaluation, reached a node with internet access and kept working on the task. They identified Hugging Face as a possible source of evaluation data, then chained additional vulnerabilities until they reached production systems. Hugging Face later described thousands of autonomous actions across short-lived sandboxes, including privilege escalation, credential harvesting and lateral movement.

It makes for a great “the AI escaped!” story, and predictably attracted some fairly imaginative theories about what happened. But there is a more useful enterprise lesson buried inside it.

The boundary the system was designed to enforce was not the boundary the agent encountered.

You do not need a cybersecurity exploit to run into a version of this problem.

Imagine a procurement agent inside a large company. It can read supplier records, compare quotes, review contracts, search email and draft purchase requests. It cannot approve a new supplier or commit company funds without human authorization.

On an architecture diagram, that boundary looks reassuringly clear.

But the agent never sees the diagram. It sees an operating environment: APIs, credentials, workflows, connected applications and, increasingly, MCP servers that make enterprise capabilities callable. Its instructions describe what it should do, while permissions determine what individual systems will accept. Neither tells you, by itself, everything the agent may be able to cause once those systems are connected.

That leaves the enterprise with two different views of the agent’s authority. Declared authority is what the organization intends to permit. Effective reach is what the agent system can actually reach or cause through the environment available to it.

For conventional software, it is often reasonable to assume those are close enough to be treated as roughly the same thing. Agents make that assumption less comfortable because they can work across systems and adapt their next action to what happened in the previous one.

The OpenAI incident exposed the gap under extreme conditions. In most enterprises, it will probably be less dramatic. The systems involved may all be functioning exactly as designed.

That could make the problem harder to spot.

2. Permissions Are Local. Agent Behavior Is Compositional.

Consider the procurement agent again. Its access has been designed carefully. It can read approved supplier records, search relevant email and contracts, query pricing and inventory, and create a draft purchase request through an MCP server. Anything above its approval threshold goes to a human.

There is nothing obviously wrong with any of those permissions.

Now production is being delayed by a component shortage, and the agent is asked to find an alternative supplier. It searches the supplier system and identifies two candidates. Previous negotiations in email provide useful context, including a contract amendment showing that one supplier had temporarily received preferred status. The agent checks current inventory and has enough information to prepare the request.

Then it finds another document.

An earlier supplier email contains updated documentation showing that the supplier has completed a required compliance review. The agent also happens to have access to the supplier-management system, where maintaining routine supplier records is part of its job. It updates the supplier from “compliance review pending” to “approved.”

Nothing improper has happened. The documentation supports the change, and the agent is authorized to update the record.

The complication sits downstream. The purchasing system uses that same supplier status to determine whether a purchase request needs additional human approval. Once the supplier is marked “approved,” the extra review disappears and the request becomes eligible for straight-through processing.

The agent was never given permission to waive an approval. It did not need it. An authorized change in one system changed a condition another system used to decide whether a human had to intervene.

There are a few different ways an agent can arrive at an outcome like this.

An intended path is the route the organization actually designed: compare suppliers, prepare the request, send the exception to a manager.

A composed path is more subtle. Legitimate capabilities are used in a sequence nobody assessed as a whole. Information from one system changes state in another, and that state changes how a third system behaves.

An unintended path depends on something that should not have been available in the first place: an exposed credential, overly broad service account, misconfiguration or vulnerability.

The OpenAI incident involved the third category. The procurement example does not. Every API call can be authorized and every application can behave according to specification. The unexpected authority appears in the way those legitimate capabilities interact.

Enterprises have dealt with a human version of this for decades. Segregation of duties exists precisely because permissions that are harmless separately can become risky in combination. Agentic execution makes the old problem more dynamic. An agent can inspect what is available, act across several systems, observe what changed and continue pursuing the objective without waiting for different people to discover and assemble the sequence.

A permission tells you what an agent can do at one point in the system. It does not necessarily tell you what becomes possible several steps later.

3. Agent Teams Turn Permissions Into Capability Graphs

A reasonable response would be to divide the procurement process among several agents.

The sourcing agent identifies suppliers but cannot approve them. A contract agent evaluates commercial terms and updates the risk classification. The procurement agent creates the purchase request. Anything outside policy still goes to a human before the ERP commits the order.

This is sensible architecture. No single agent controls the whole transaction, just as the person negotiating a contract should not also approve the expenditure.

The problem is that separated responsibilities still have to reconnect somewhere.

The sourcing agent passes a candidate to the contract agent. The contract agent evaluates the terms and changes the risk classification. That classification becomes an input to the procurement workflow, which determines whether additional approval is required. If the relevant conditions are satisfied, the ERP accepts the purchase order.

No agent individually approved the transaction. One agent’s action nevertheless changed the conditions under which the rest of the system could proceed.

A capability graph is a useful way to see this. Its nodes are agents, tools, APIs, workflows, systems of record and human approval points. The edges show how requests, data, state and authorization conditions move between them, including the identities and credentials that allow those transitions.

MCP can make this graph expand quickly because every newly exposed read or write operation adds another capability an agent may be able to invoke. That is not automatically dangerous. A new read operation may simply give an agent better context. A write operation that changes a field used by another workflow’s approval logic deserves a different kind of attention.

This is where component-level access reviews begin to show their limits. Security may review the sourcing agent’s permissions. The application team reviews the MCP server. Procurement reviews its workflow. The ERP team reviews its API. All four reviews can be correct while missing a consequential route that exists only when those components are connected.

Effective reach can therefore grow without any individual permission becoming broader.

The procurement agent still cannot approve a supplier. The contract agent still cannot issue a purchase order. The sourcing agent still cannot commit funds. Yet the system as a whole may have a route that ends with a committed purchase order.

At that point, the route itself belongs in the authority model.

And unlike the architecture diagram approved at deployment, that route is going to change.

Subscribe now

4. The Graph Changes After You Approve It

Six months later, the procurement system is doing its job. Exceptions still reach managers. Purchase orders are being processed. Nobody has held a meeting to give the agent team more authority.

Plenty of smaller things have changed, though.

The sourcing agent now runs on a newer model that is better at planning across tools. Procurement has added another supplier data source. The MCP server exposes a new write operation so agents can maintain records without opening a separate application. A class of low-value exceptions that managers almost always approved now moves through an automated workflow.

None of this looks like a redesign. Collectively, however, those changes can alter the routes available through the system.

Take the new MCP operation. It allows the contract agent to update a supplier’s compliance status after reviewing new documentation. That sounds like exactly the sort of mundane efficiency improvement agents are supposed to provide: remove a manual step and let the system maintain its own records.

Unfortunately, compliance status also determines whether the procurement workflow invokes an additional approval.

The team exposing the operation may understand exactly what the field means inside supplier management without knowing every downstream process that consumes it. The procurement team may know exactly how its approval logic works without knowing that another agent recently gained a direct way to change one of its inputs.

The approval rule itself has not changed. The route to satisfying it has.

I use authority drift to describe this condition: effective reach changes materially while declared authority remains the same.

This can happen while all the familiar indicators still look healthy. The model performs well against its evaluations. Access certifications are current. API scopes are correct. The human approval step remains plainly visible in the workflow definition.

Meanwhile, a path exists that did not exist when the authority boundary was originally approved.

That is why reviewing every system change as though it carries the same risk would be both expensive and mostly useless. A new model or additional data source may improve performance without changing authority at all. A new write-capable tool, an altered approval rule or permission for one agent to invoke another is different because it may create a new route to a consequential action.

What matters is whether the relationships among capabilities have changed enough to alter what the system can cause.

5. Govern the Consequence, Then Work Backward

For the procurement team, the consequence we care about is easy to name: the ERP commits company funds to a supplier.

That gives the analysis somewhere useful to start.

Work backward from the purchase order. What conditions must be satisfied before the ERP accepts it? Which workflow, field or rule decides whether human approval is required? Which agents and tools can change those conditions? And can the same outcome now be reached without the human intervention the organization expected?

This is much more manageable than attempting to catalogue every theoretical action available to every agent. A large enterprise could produce a magnificent capability graph containing thousands of nodes and edges and still learn almost nothing useful from it. The interesting paths are the ones that terminate in consequences whose authority must remain explicit: committing money, deploying production code, changing an entitlement, issuing a refund or modifying a regulated record.

In our procurement example, working backward might reveal three routes into the ERP. Two still require human approval. The third becomes eligible for straight-through processing after supplier status changes upstream.

Now there is something concrete to investigate.

For consequential paths like that, the enterprise can maintain a record along the lines of:

Change → affected path → authority impact → approval → verification evidence

This also provides a more sensible threshold for reauthorization. A new model version should not automatically trigger it. Neither should every prompt edit or retrieval change. Adding a write-capable tool, changing the meaning of a workflow field, removing an approval step or allowing one agent to invoke another might.

Design-time analysis will only tell you so much. Once the system is operating, production evidence tells you what agents are actually doing. Tool-call traces show which capabilities they invoke. Workflow logs show which routes transactions take. Approval and override records show where humans continue to disagree with agent recommendations. Exception logs reveal cases the original workflow did not anticipate.

Business outcomes add another piece. A transaction can produce the desired result and still have arrived there through a route the enterprise never intended. Execution evidence and outcome evidence need to be read together.

That evidence can also help an enterprise decide where human review still earns its keep.

Suppose managers have approved the same low-risk procurement exception hundreds of times and almost never change the recommendation. That is worth investigating, but it is not proof that the approval should disappear. Managers might be rubber-stamping. Important consequences may not show up until months later. A rare mistake may simply be expensive enough to justify the friction.

Approval history has to be considered alongside exception frequency, downstream outcomes, transaction value, override patterns and the cost of being wrong. If the evidence supports more autonomy, the organization can expand the boundary deliberately, document the change and keep watching what happens. Repeated overrides, unusual tool sequences or the appearance of a new route to a consequential action may justify moving the boundary in the other direction.

This makes “human in the loop” less of a permanent box on a workflow diagram and more of a control whose placement can change with evidence and risk.

A useful place to begin is surprisingly narrow. Pick one action an AI agent must not take without explicit authority. Trace backward from that consequence through the systems, workflows, tools, credentials, agents and approvals capable of producing it.

Somewhere along that path, look closely at capabilities that seem harmless on their own.

The combination may be doing more than either permission suggests.

6. Sovereignty Means Knowing What the System Can Cause

The procurement company does not need to build its own foundation model, agent framework or every tool its agents use. In most cases it should not. External applications, managed platforms and third-party MCP servers will be part of enterprise agent architectures.

It still needs to know who controls the path that ends with its money being committed.

That is where this becomes a sovereignty problem.

As enterprises move from assistants that generate answers to agents that take actions, operational control depends increasingly on relationships among models, tools, identities, workflow state, approval rights and systems of record. An organization can own its data and manage every individual permission carefully while still losing sight of what those permissions make possible in combination.

Three ideas help separate the problem. Declared authority describes what the enterprise intends to permit. Effective reach describes what the operating system can actually reach or cause. Authority drift appears when that effective reach changes while the declared boundary does not.

Keeping all three perfectly aligned is unrealistic. Enterprise environments are full of reused fields, legacy dependencies, undocumented assumptions, old workflow rules and exception paths created years before anyone imagined an autonomous agent navigating them. Agents add an actor capable of finding and using those connections at machine speed.

Trying to predict every possible sequence in advance is unlikely to work. A more tractable problem is deciding which consequences must remain under explicit control, identifying the important routes to them and watching how those routes change in production.

That work will cross organizational boundaries. Security understands identities and permissions. Application owners understand APIs and data semantics. AI platform teams understand agent capabilities and tool access. Process owners know why approvals exist. Business leaders ultimately own the consequences. None of them has the whole picture on their own.

The OpenAI incident made the issue unusually visible because the path crossed such an extraordinary boundary: models expected to remain inside an evaluation environment found their way into another company’s production infrastructure.

Enterprise versions will usually be much duller. A supplier field changes and an approval quietly disappears. A route to production deployment becomes possible through tools nobody evaluated together. A customer record changes because one agent modified state that another workflow trusted.

There may be no rogue permission to find. No access-control failure. No dramatic “escape.”

The access review can describe every individual permission correctly and still miss the path that matters.

When an agent finds that path, the enterprise still owns what happens at the end of it.

Put These Ideas to Work

Want to put these ideas to work? Subscribe free to The Sovereign AI Enterprise and receive the Field Guide: five decisions to help you examine what your AI systems can do, which dependencies matter, and whether you can account for their actions. You’ll also receive my ongoing analysis of enterprise AI, governance and technology sovereignty.

1. The Vendor Update That Opened a New Door

The next AI access risk may arrive as a trusted vendor update.

A company uses a CRM platform to manage client support, account escalations, and internal response workflows. The vendor is approved, and the platform is already in production. The data already lives there. Security reviewed the application months ago.

Then the vendor ships an MCP server.

It appears in the admin console as a useful new integration option. The business case is straightforward: let approved AI assistants retrieve account context, summarize open issues, search support history, and help teams respond faster.

No one treats it like a major architecture decision: Nothing new is being bought, and no one is moving data into a strange tool. The vendor and the application are trusted. And the users are already allowed to access the records.

At first, the MCP server is read-only. An assistant can look up client records, find related tickets, summarize recent activity, and pull relevant policy notes. For a support manager or account lead, that is useful. Instead of clicking through five screens before a client call, the assistant can produce a clean summary in seconds.

Then the server expands.

A later release adds action-capable tools. The assistant can update ticket status, create escalation records, route an exception, draft a client follow-up, or trigger an internal approval workflow. Each capability is defensible on its own. Support teams already do these things manually. The vendor is exposing normal product functions through a new agent-facing interface.

But the risk soon shows up.

A client has an open production issue. In the service platform, the support ticket shows “fix package available.” The client account record shows “resolution in progress.” The standard support workflow says that once a fix package is available, the account team should tell the client the fix is ready for validation and move the escalation from “active incident” to “monitoring.”

But there is one missing fact.

Engineering has a note in a separate deployment system: this client runs a nonstandard configuration, and the patch has not been deployed to their environment yet. The MCP server connected to the service platform can see the ticket, the account record, and the standard workflow. It cannot see the engineering exception.

A support lead asks the AI assistant for a status summary and next action.

The assistant retrieves the visible records and follows the visible process. It sees “fix package available,” “resolution in progress,” and a workflow rule that says the next step is client validation. So it recommends sending the client a “fix ready for validation” update and moving the escalation to monitoring.

The recommendation looks reasonable. The assistant has the right client, the right ticket, the right timeline, and the right standard procedure. The support lead is busy and approves the update.

Now the escalation status and internal SLA handling changes, and the queue no longer treats the issue as an active production incident. The account team sees the client as validating a fix, not waiting for deployment. A follow-up message goes out saying the fix is ready for validation.

Two days later, the client escalates, because production is still broken.

There was no dramatic failure, no hacking, no rogue AI tool, and no one handed sensitive data to a consumer chatbot. The assistant used an approved server from an approved vendor against records the company already allowed employees to access.

The problem is more uncomfortable: the company enabled a new agent-facing surface without reviewing what that surface exposed, what it omitted, and which actions it allowed.

The application and vendor had been approved. But the agent-facing access path had not.

That is why MCP matters beyond the protocol discussion. It gives enterprise software a standard way to become usable by AI agents. In some cases, that means better search and faster summaries. In other cases, it means AI assistants can update records, trigger workflows, route exceptions, and change the operational state of work.

The company thought it had enabled a useful integration.

It had opened a new door into the business.

2. What MCP Actually Changes

MCP is often explained as a technical standard. That is accurate, but it hides the enterprise consequence.

At a basic level, the Model Context Protocol gives AI applications a standard way to connect to external tools, data, and workflows. An MCP server exposes capabilities an assistant can discover and use. Those capabilities might be simple: search a knowledge base, retrieve a client record, inspect a ticket, summarize a document. They might also be operational: update a record, create an escalation, send a message, call an internal API, or trigger a workflow.

In the client escalation example, the assistant did not fail because it hallucinated. It used the records and tools exposed to it. The MCP server made the service platform legible to the assistant: here is the ticket, the account, the workflow, the actions available. But the missing engineering exception lived outside that surface.

That is the shift. Enterprise software has usually exposed itself in two main ways. First, through screens for people: dashboards, forms, queues, admin panels, approval buttons. Second, through APIs and connectors for software: engineered integrations that move data between systems or trigger known actions.

MCP adds a third surface.

It gives enterprise software an agent-facing surface: a set of tools, resources, prompts, and actions designed for AI systems to discover and use. The assistant does not need to understand the whole application the way a human user does, only the capabilities the server exposes.

This is useful, which is why vendors will ship MCP servers and why teams will enable them:

• A support assistant can retrieve context faster

• A sales assistant can prepare an account summary

• An IT assistant can inspect open incidents

• A developer assistant can query tickets, code repositories, documentation, and deployment status through a common pattern

But the same design choice creates the risk. The MCP server becomes a selective window into the enterprise. It defines what the agent can and can’t see, what actions are available, and how work appears to the assistant.

In the old model, a user moved through the application and saw the surrounding context, tabs, warnings, related records, and process cues. In the agent-facing model, the assistant may see a narrower tool description, a retrieved record, and a set of callable actions. The MCP server becomes the boundary between the agent and the business.

That is why an MCP server should not be treated as a minor connector: A connector moves data. An agent-facing surface packages part of the business for AI use.

The practical questions are what the server exposes, what it omits, which actions it allows, and who reviews those choices before the assistant starts using them in real work.

3. Why This Will Spread Through Vendors, Teams, and Partners

MCP will not enter the enterprise through one door. This is what makes it easy to underestimate.

The most visible path will be vendors. Enterprise software companies have an incentive to make their products usable by AI assistants. If work increasingly starts in an assistant, then the applications that cannot be reached from that assistant become less visible in the flow of work. A CRM system, ticketing platform, code repository, documentation tool, or support platform becomes more valuable if an agent can search it, summarize it, and call approved actions inside it.

For the vendor, an MCP server becomes a product surface. It says: here are the records agents can retrieve, the tools they can call, the workflows they can trigger, and here is how our application should appear inside an AI-assisted workstream.

That is why vendor-shipped MCP servers look like product enhancements from companies the enterprise already trusts, not like rogue infrastructure.

The second path is internal teams. Developers, IT operations teams, data teams, and business technologists will build MCP servers because they solve immediate problems. A team wants an assistant to query a documentation portal, inspect a ticket queue, search a repository, pull metrics, or check the status of an internal workflow. Building a small server around that use case may be faster than waiting for an official roadmap, a centralized integration project, or a vendor-built connector.

The third path is partners. Systems integrators, implementation partners, managed service providers, and specialist consultants already build connective tissue around enterprise systems. As MCP becomes a common way to expose tools and context to agents, partners will use it inside delivery work. They may build a server that connects a client workflow to a vendor platform, exposes implementation status, retrieves project artifacts, or lets an assistant operate across a custom process.

The server may be useful but may also sit in an awkward ownership zone after go-live: The vendor does not fully own it, the partner may not maintain it forever, and the client may depend on it before it has been added to the formal architecture map.

Let’s return to the support example.

The first MCP server came from the trusted service-platform vendor. Later, an internal operations team exposed escalation notes through a small internal server. Then an implementation partner added another server for deployment status during a client rollout. Each server made sense. Each solved a real workflow problem. None looked large enough to trigger a major architecture review.

Together, they created a fragmented agent-facing access layer.

That is the practical problem. Vendor, internal, and partner-built MCP servers may look different in procurement and security review. In production, the assistant experiences them as callable tools. The enterprise has to understand the combined surface: what agents can discover, what they can retrieve and change, and who owns each path after it becomes part of work.

4. What Leaders Should Review Before They Enable It

The practical answer is not to block MCP servers that help teams retrieve context faster, reduce manual clicking, and make enterprise software easier for assistants to use. What truly matters is whether the enterprise reviews the server before it becomes part of the work.

The review should start with a simple classification: what kind of surface is this?

A read-only server that searches product documentation is one kind of exposure. A server that retrieves client records is another. A server that can update ticket status, change account fields, trigger escalation workflows, or send client messages belongs in a different category. Those are not just data-access questions. They change the operational state of work.

In the support example, the company could have enabled the read-only tools first. Let the assistant summarize the ticket, retrieve account history, and find the standard workflow. That would have saved time without changing the case. The higher-risk step was allowing the assistant to move the escalation to monitoring and generate a client update before anyone had reviewed what context the server could not see.

Which leads to the second question: what does the server omit?

Many enterprise failures do not come from one system being completely wrong. They come from one system being partly right. The service platform knew the fix package was available. It knew the standard support workflow and the account record. But it did not know the deployment exception sitting in the engineering system. The assistant was operating inside that partial view.

Before enabling an MCP server, leaders should ask which surrounding systems are required to make the exposed actions safe. If a server can recommend an escalation change, does it also see engineering status, deployment state, client-specific exceptions, entitlement rules, SLA terms, and approval history? If it cannot see those systems, the exposed action may need a warning, a narrower scope, or a human confirmation step.

Identity is the next review point.

When the assistant calls the server, who is it acting as? The user? A service account? The vendor application? A delegated enterprise identity? Authority can become blurry once a natural-language assistant sits between the employee and the application. If the support lead approves a status change suggested by the assistant, the record should show more than a generic system update. It should show who requested it, which assistant invoked the tool, which user approved it, and what changed downstream.

Tool scoping also matters. A vendor may ship an MCP server with ten tools. The enterprise may only want three. Searching tickets, retrieving client records, and summarizing history may be acceptable on day one. Updating escalation status, sending client-facing messages, or triggering workflow changes may need separate approval. The server should not be accepted as one undifferentiated bundle.

Change visibility may be the most overlooked issue.

The first version of the server may be read-only. A later version may add write tools. Another update may change a tool description, expand the fields available to the assistant, or expose a new workflow action. If the enterprise reviews the application once and treats every future server change as a routine vendor update, the agent-facing surface can expand without a matching review.

Finally, someone has to own it.

Security may review the server. Architecture may approve the pattern. The vendor manager may track the roadmap. The business owner may care about the workflow. But once the server is live, someone needs to know which assistants use it, which actions are enabled, what logs exist, what breaks if it is disabled, and how new capabilities get reviewed.

In the support example, the mistake was not enabling the server, but enabling the action path without classifying it. Ticket search and account summarization were productivity features. But escalation changes and client updates were operational actions. They deserved a different review.

That is the operating discipline MCP requires: review the server as a product surface, classify the tools by consequence, and decide which actions an assistant can take before the server disappears into ordinary work.

5. Wrap Up: Review the Server, Not Just the Software

The company in the support example was right to take advantage of the MCP server. It helped the assistant retrieve support history, summarize the client account, and follow the standard workflow. Those are real productivity gains. The mistake was treating the server like a minor feature toggle after the application had already been approved.

The application review covered the software, but did not cover the new agent-facing surface.

That difference is key: Once an MCP server is enabled, the enterprise is no longer only deciding who can log in to the application or which systems can exchange data through an API. It is deciding what an AI assistant can discover, retrieve, recommend, and in some cases change through that product.

In the support example, the safe version would have been simple:

1. Enable read-only retrieval first.

2. Let the assistant summarize the ticket, account record, and standard workflow.

3. Keep escalation changes, client-facing messages, and SLA-impacting status updates behind a separate review.

4. Require the assistant to surface missing-context warnings when engineering deployment status is unavailable.

5. Log the tool calls separately from ordinary application activity.

6. Assign an owner for the MCP surface, not just the SaaS application.

This is basic operating discipline for software that agents can use.

The first answer is a review motion. The enterprise needs a basic inventory of MCP servers, but the inventory is only the start. Each server needs an owner, a source, a hosting model, a tool list, an identity path, and a change process. The review should separate retrieval from action: searching records is one class of exposure; changing status, sending messages, triggering workflows, or calling downstream systems is another. It should also account for change over time. A server that is safe when it exposes three read-only tools may become more consequential when the vendor adds a fourth tool that can update the system of record.

The longer-term answer is a control layer.

One MCP server can be reviewed manually. Ten can be tracked in a spreadsheet. But a growing mix of vendor, internal, and partner-built servers will not stay manageable that way. At some point, the enterprise needs a way to see which agents can call which tools, through which identities, against which systems, with which logs, approvals, and exception paths.

MCP will make enterprise software easier for agents to use. That is the value. It also means the application review process cannot stop at the screen, the API, or the contract. When a vendor, internal team, or partner exposes an MCP server, the enterprise is looking at a new product surface: what agents can see, what they can call, what they can change, and who owns the trace after the call.

Review the MCP server before it disappears into ordinary work.

1. The warning from pharma

AI can now produce answers faster than most enterprises can find out whether those answers work.

That gap may become one of the most important constraints in enterprise AI. The cleanest warning comes from pharma, where the cost of learning from reality rose for decades.

Between roughly 1950 and 2010, the number of new drugs approved by the FDA per billion US dollars of research and development (R&D) spending fell by about half every nine years. Adjusted for inflation, that amounted to an almost 80-fold decline in research productivity. The industry gave the pattern a brutal name: Eroom’s Law. Moore’s Law spelled backward.

Subscribe now

The name works because the contrast is so stark. In computing, scale made the core unit cheaper, faster, and more powerful. In drug discovery, decades of better instruments, larger datasets, computational biology, automation, and management discipline did not produce the same curve. The cost of proving what works kept rising.

Imagine a specialty materials manufacturer trying to reduce defects on a high-value production line. Its AI system can analyze sensor readings, maintenance logs, supplier inputs, temperature ranges, throughput targets, and quality data. It can recommend a new process setting in seconds.

The recommendation looks precise. But the proof does not arrive in seconds.

The line has to run. The material has to cure. Quality has to be inspected. Maintenance effects may take time to appear. A client issue may not surface until the product is already downstream.

The model made the recommendation cheap. But the business still has to pay to learn whether the recommendation survives operations.

That same pattern exists across the enterprise. AI can suggest a route, a price, a maintenance plan, a supplier substitution, a credit exception, or a claims pathway almost instantly. But the expensive part is still what happens next.

Eroom’s Law is the cleanest version of a broader enterprise problem: recommendations are getting cheaper, but proof is still expensive.

2. Prediction is the cheap part now

For the materials manufacturer, the AI recommendation feels like the breakthrough.

The production team no longer has to start from a blank page. The system can scan years of batch data, compare machine settings, read maintenance history, correlate supplier lots with quality outcomes, and flag patterns that would take engineers weeks to reconstruct manually. It can suggest which process parameter to adjust, which input material looks unstable, which machine is drifting, or which production window carries the highest defect risk.

The same shift is happening across industries. Logistics teams can get route options before a planner has opened every lane constraint. Banks can summarize credit risk and surface exceptions. Insurers can classify claims and recommend a handling path. Utilities can rank asset-failure risk before maintenance teams review every record.

AI compresses the work of search, comparison, classification, synthesis, and recommendation. It can turn messy operational signals into a ranked set of options.

But that is still the front end of the loop.

A recommendation is a claim about what might work. It is not evidence that the business has learned. The model can identify the likely defect driver, the likely supplier issue, the likely route problem, or the likely credit risk. The enterprise still needs to act, observe the result, and decide whether the recommendation improved the real system.

Many companies are treating faster recommendations as faster learning. AI can reduce the cost of forming a hypothesis. The enterprise still has to test it.

3. The AI recommendation meets reality

The manufacturer accepts one recommendation.

The AI suggests a small change to a process parameter on the high-value line. Nothing dramatic. A slightly different temperature range, a tighter timing window, and a throughput target that looks achievable based on prior runs. The recommendation is backed by historical data and fits what the production team already suspects: the line is capable of more than it is producing.

The first shift looks promising. Output improves, and the dashboard moves in the right direction. The recommendation appears to have worked.

But then the second-order effects start to show:

• Scrap rises on one product variant.

• A quality inspection catches a surface inconsistency that was not visible in the first yield report.

• Maintenance sees early signs of stress on a component that usually lasts longer.

• The production team realizes the setting works better with one supplier lot than another.

• A downstream client reports variation that did not appear in the standard plant metrics.

The AI was not simply wrong. That would have made the lesson easier.

It optimized against the data it could see. But operations contained variables the recommendation did not fully price in: material variation, machine wear, inspection lag, shift behavior, supplier inconsistency, client tolerance, and the difference between a clean metric and a usable product.

That is the part many AI business cases understate. Real systems do not answer cleanly or quickly. They answer through delays, exceptions, side effects, and partial signals.

The same pattern appears outside manufacturing:

• A cheaper supplier can create quality drift three steps downstream.

• A logistics route can look optimal until port congestion or customs delays erase the savings.

• A faster claims pathway can reduce handling time while increasing leakage, complaints, or litigation.

None of those cases mean the recommendation had no value. They mean the value cannot be judged at the moment the recommendation is made.

Reality is the hidden second half of the AI system.

Until the enterprise can connect the recommendation to the operational result, it has improved the speed of advice. It has not changed the learning cycle.

4. Self-driving labs show the pattern

The manufacturer’s problem is easier to see in the place where the loop is most explicit: the lab.

Self-driving labs started in experimental domains like chemistry, materials science, and drug discovery. They are often described as robot chemists. But the useful idea is the loop: a system can form a hypothesis, run an experiment, measure the result, learn from the outcome, and choose the next experiment.

With the loop, action and measurement are connected tightly enough for the next decision to improve.

A conventional automated system runs a predefined process faster. But a self-driving lab changes the next experiment based on what the last one revealed. It can reduce the time between idea, evidence, and adjustment.

The plant does not need to become a lab in the literal sense. It needs to copy the useful part: treat the AI recommendation as the start of a controlled test, measure what happens, and use the result to improve the next decision.

The company can take one process setting and test it on a defined product variant, shift, machine, or batch window. It can watch not only throughput, but scrap, rework, machine stress, quality variation, and downstream client issues. It can compare the result against the prior setting and record which conditions made the recommendation work and which conditions made it fail. Then the next recommendation has a better picture of the line.

Outside science, the self-driving lab idea gives leaders a pattern for turning AI from a recommendation engine into a learning system.

Many industries have their own version of the lab. In another business, the “lab” may be a factory floor, a logistics network, a claims operation, or an IT estate.

The lab is just the visible version of what every operating business wants: a shorter path from idea to evidence.

5. Most enterprises waste their failures

After the production issue, the manufacturer looks back at previous attempts to improve the same line.

The useful evidence is everywhere and nowhere:

• One engineer remembers that a similar temperature change caused problems last year.

• A maintenance ticket mentions unusual wear after a prior throughput push.

• A quality report shows a defect pattern that appeared for only one product variant.

• Procurement has notes on a supplier lot that behaved differently from the others.

• A shift supervisor remembers that the setting worked better at night, when the line ran with a different crew and fewer changeovers.

Most of this is exactly the kind of evidence the next recommendation needs.

But the business did not preserve it as learning data. It preserved it as fragments: ticket comments, meeting notes, dashboard anomalies, email threads, local memory, and after-action explanations.

Successful changes made their way into the process. But failed attempts stayed in those fragments.

Most companies are better at recording transactions than experiments. They know what was ordered, approved, shipped, paid, closed, repaired, or escalated. They are less disciplined about preserving what was tried, what was rejected, what almost worked, what failed under specific conditions, and what an experienced operator overrode before it became visible in the metrics. And sometimes organizational politics get in the way of understanding why something failed.

If AI only learns from completed transactions and approved decisions, it sees a cleaned-up version of the business. It sees what survived the process, not the rough terrain around it:

• It may know the final supplier, but not the rejected substitute that failed quality review.

• It may know the approved maintenance plan, but not the workaround that prevented a larger outage.

• It may know the successful production setting, but not the boundary conditions that made nearby settings fail.

Failure data is not operational debris. It is the map of the terrain.

The question for leaders is:

Where does the business already pay for failed attempts, but fail to keep the learning?

That is where AI’s value is capped. A company that cannot remember its failed experiments will keep asking AI to make recommendations inside a partial picture of reality.

6. The practical question: where is your learning loop slow?

Eventually, the manufacturer’s attention shifts from the model to the loop.

The company has to stop treating AI adoption as the question. It already added AI: the system can analyze data, surface patterns, and recommend changes faster than the production team could do manually.

The next question is: where does the business learn too slowly?

On the high-value line, the team changes process settings constantly. When the setting is wrong, the cost shows up in scrap, rework, downtime, warranty exposure, and dissatisfied clients.

But the evidence arrives in pieces. Yield shows up quickly. Machine stress takes longer. Supplier variation may take several batches. Client impact may come later still.

The same test applies across the enterprise. The best candidates are repeated decisions with measurable consequences: pricing changes, maintenance deferrals, supplier substitutions, logistics reroutes, credit exceptions, claims pathways, and production settings.

Start with five questions.

1. Where do we make repeated decisions under uncertainty?

2. Where does the outcome arrive late, indirectly, or in another system?

3. Where do failed attempts, operator overrides, and near misses disappear?

4. Where can we test a recommendation on a smaller slice before scaling it?

5. Where would faster learning improve margin, uptime, quality, safety, capital efficiency, or client experience?

That last question is key because not every loop deserves the same attention. Some decisions are too rare or too hard to measure. Some changes take too long to evaluate. And some use cases are interesting but operationally trivial.

The best candidates usually have four traits:

• The decision happens repeatedly

• Mistakes are expensive

• Outcomes can be measured

• The business can compare alternatives without redesigning the whole operating model

The company can turn each recommendation into better evidence for the next decision.

The best AI use case may be the loop where the company is already paying too much to learn too slowly.

7. What leaders should build first

The manufacturer does not need to redesign the whole plant.

It starts with one repeated decision on one production line: which process setting to use for a specific product family. The scope is small enough to manage and important enough to matter. The line runs often, the cost of mistakes is visible, and the company already has the data. The problem is that the data is organized around production, quality, and maintenance, not around learning from each recommendation.

The first build is a simple learning loop:

1. Define the decision. In this case, the decision is the process setting the AI recommends before the run.

2. Define the action. The action is the controlled change made on the line: machine, shift, batch window, product variant, supplier lot, and operating conditions.

3. Define the outcome. The outcome is not one metric. It includes yield, scrap, rework, inspection results, machine stress, maintenance notes, and downstream quality signals.

4. Capture the exceptions. Record when operators override the recommendation, when the setting is rejected, when the result is mixed, and when the apparent win creates a later problem.

5. Compare alternatives. Don’t just ask whether the AI recommendation worked, but where it worked, under which conditions, compared with what previous setting, and at what downstream cost.

6. Feed the result forward. The next recommendation should be shaped by the prior result, including the failed attempts and boundary conditions.

Implementation starts with a shared record of the loop. Each recommendation needs a trace: what the system recommended, what evidence it used, who approved the test, where the change was applied, which conditions were present, what outcome followed, which exceptions appeared, and what changed for the next decision. The evidence will usually sit across production systems, quality reports, maintenance tickets, supplier records, operator notes, and downstream client issues. The work is to connect those signals around the decision. Without that record, the company is only running faster recommendations, not building memory.

That same pattern applies outside manufacturing. Pick one decision that repeats, costs money when wrong, and produces observable outcomes. Do not start with a portfolio of AI pilots. Start with one loop where better feedback can change the next decision.

The useful metric is learning cycle time: how long it takes to move from recommendation, to action, to observed result, to a better next decision.

Make one loop learn faster.

8. Wrap Up: The advantage is learning speed

The manufacturer does not win because the model generates more recommendations.

It wins when each recommendation makes the next one better:

• The process setting is tested

• The result is measured

• The exception is captured

• The failed condition is preserved

• The next decision carries more evidence than the last one

That is the practical lesson behind Eroom’s Law. Pharma gave the pattern a name because its productivity crisis was impossible to ignore. Other industries may not call it Eroom’s Law, but many live with their own version: rising cost, slow experimentation, fragmented feedback, and wasted failure data.

AI will keep making prediction cheaper. That’s important, but prediction is only the start of the operating cycle.

The larger advantage belongs to companies that reduce the cost of learning from the real world.

AI will make answers cheaper. The companies that win will make learning cheaper too.

1. The code is done. The work is still stuck.

The pull request is ready before lunch.

A developer opened an issue in the morning, pointed a coding agent at the repo, and asked for the change. The agent read the surrounding code, proposed an approach, wrote the first version, generated tests, explained the diff, and opened the PR. Work that might have taken a day now took an hour.

That is real progress. It changes the developer’s day. It reduces the blank-page problem, makes unfamiliar code easier to approach, and helps teams clear routine work that used to sit in the backlog for weeks.

Then the pull request waits.

It waits for an environment that has not been provisioned. It waits for access to a service account. It waits for dependency review, security findings, test data, network configuration, architecture approval, compliance evidence, or a release window. The code moved quickly. The delivery system did not.

Software does not reach production because code exists. It reaches production through controls, handoffs, and evidence. Some of those controls are technical: CI/CD pipelines, secrets management, vulnerability scans, infrastructure templates, deployment policies, rollback plans, observability hooks, and integration tests. Others are organizational: ownership, approval rights, change records, operational readiness, funding, and accountability.

In large enterprises, those controls are slow for a reason. Production software touches clients, employees, regulated data, critical infrastructure, revenue, and operational continuity. A bank cannot treat a credit-risk change like a personal script. A healthcare platform cannot ship a dependency upgrade without knowing what patient workflow it touches. An airline cannot modernize a scheduling service without understanding downstream systems, batch windows, and operational fallbacks.

AI coding agents make implementation faster. They do not automatically make the enterprise delivery system faster.

In some cases, they create more pressure downstream. More pull requests arrive. More fixes are proposed. More modernization candidates appear. Security, platform, compliance, architecture, and operations teams still have to decide what is safe to release, what needs more evidence, and who accepts the risk.

The code may be ready in an hour.

The software is not shipped until the enterprise can trust the path it took.

2. Coding assistants and agentic SDLC are different categories

The market still talks about AI software tools as if the main contest is code generation.

Most AI software tools are evaluated at the coding surface: Which tool writes the better function? Which one understands the repository faster? Which one produces cleaner tests? Which one fits best inside the IDE? Those questions are important, but they measure the part of software delivery closest to implementation.

That is the coding-assistant category.

A coding assistant lives inside the developer’s loop. It helps a developer understand the task, inspect the codebase, modify files, generate tests, explain the diff, and prepare the pull request. Its useful context is local: the repo, the issue, the surrounding code, the developer’s instructions, and the immediate build or test result.

The next category is larger.

Call it agentic SDLC: AI systems that help software work move across planning, coding, review, testing, security, release, modernization, and operations. In that category, the agent is judged by more than its ability to generate code. It is judged by whether it can understand the path a change has to travel before the enterprise can release it.

That changes the design problem.

An agent working across the SDLC needs to understand more than the repository. It needs enough delivery context to know what kind of change this is, where risk enters, and which controls shape the path forward.

It also needs to know when to slow down.

A routine internal fix may move through a lightweight path. A change touching regulated data, identity, payments, client-facing workflows, brittle integrations, or critical infrastructure requires a different chain of checks. The agent has to recognize that difference before the work reaches the final review queue.

In practice, that means the agent should do more than open a pull request. It should classify the change, surface affected services, attach relevant security findings, identify the approval path, check release readiness, and capture the evidence the next reviewer will need.

A well-written patch can still be blocked. It can pass unit tests and still miss a dependency. It can modernize a local component and still break a downstream workflow. It can close the issue and still fail the release process.

That is why the enterprise evaluation cannot stop at code quality.

The stronger system is the one that understands the route from change to production, not only the code inside the pull request.

For individual developers, the coding loop is the natural starting point.

For enterprises, the larger contest is the SDLC itself.

3. The harness is the missing layer between model and delivery

The model gets most of the attention because the model is the visible intelligence. It writes the function, explains the error, drafts the test, and proposes the fix.

But enterprise software delivery is not shaped by model capability alone.

The agent needs a surrounding system that determines what it can see, what it can touch, what it must check, and what record it leaves behind. That surrounding system is the harness.

In this context, the harness is the operating layer around the agent: context retrieval, tool permissions, workflow state, policy checks, CI/CD integration, evidence capture, evaluation, logging, and audit. It connects the model to the delivery system without letting the model become an unmanaged actor inside it.

A personal coding setup can run with a light harness. The agent sees the repo, follows a few local instructions, calls a command-line tool, and depends on the developer to catch what is missing. The developer supplies the institutional memory: which shortcut is safe, which test is meaningful, which service is fragile, which reviewer will care, which deployment pattern has caused trouble before.

Enterprise SDLC cannot depend on that much personal interpretation.

The harness has to carry enough of the delivery system to make the agent useful beyond code generation. It should know the work item, the approved engineering patterns, the relevant policies, the pipeline state, the release process, and the evidence expected by reviewers, auditors, and operations teams.

This is where many coding-agent deployments will hit their limit.

A stronger model may produce a cleaner patch. It may explain the diff more clearly. It may generate better tests. But if the harness cannot connect the work to dependency posture, security review, release readiness, change records, rollback planning, and operational handoff, the agent is still producing output at the edge of the delivery system.

The harness determines whether the agent is merely writing code or participating in controlled work.

For a routine fix, the harness may only need to confirm ownership, run tests, attach evidence, and prepare the pull request. For a sensitive change, it may need to check data classification, affected services, approved patterns, vulnerability findings, policy exceptions, release windows, and required approvers before the work can move.

That is why model improvement does not remove the need for the harness. It increases it.

As agents become more capable, they need richer context, clearer permissions, stronger evaluation, and a better record of what happened. The enterprise has to know which systems shaped the recommendation, which tools were called, which checks passed, which exceptions were raised, and where human judgment entered the path.

The model may write the code.

The harness determines whether the work can move through the enterprise.

4. Modernization proves code generation is insufficient

The waiting pull request becomes even more revealing when the work is modernization.

A coding agent can translate a function, update a syntax pattern, explain an unfamiliar class, or draft the first pass of a migration. In an old codebase, that is useful. Many enterprise systems contain logic that survived multiple owners, expired documentation, uneven naming conventions, and years of urgent fixes. Even basic comprehension can save time.

But modernization rarely fails because one function could not be rewritten.

It fails when the rewritten code changes behavior the enterprise did not understand.

A Java upgrade can change a serialization pattern that a downstream service quietly depends on. A framework migration can alter an authentication flow that behaves differently under production traffic. A dependency replacement may pass unit tests and still break the month-end batch job. Mainframe modernization can produce cleaner code while stripping out the operating assumptions that made the old system safe to run.

That is why the opening pull request waits.

The enterprise has to know what the change connects to, which systems depend on the current behavior, which data formats and integration contracts are exposed, which performance assumptions are buried in the old implementation, and which tests prove equivalence. It also has to know who owns the cutover, what rollback path exists, which operations team needs to prepare, and what evidence will satisfy audit, resilience, and risk.

The coding work may be the most visible part of modernization. It is rarely the whole job.

A coding assistant can help the developer move faster through the codebase. But agentic SDLC has a harder assignment: help the organization move safely through the change. That requires dependency awareness, approved migration patterns, security checks, test strategy, release planning, rollback paths, and evidence captured as the work progresses.

This is where the harness becomes practical. The agent needs enough context to see modernization as a delivery change, not a code rewrite: architecture, dependencies, deployment history, operational constraints, and the policies that determine whether the work can move forward.

Without that layer, modernization becomes a faster way to produce uncertain software.

The code may be cleaner. The syntax may be current. The tests may pass. But the enterprise still has to answer the more difficult question: whether the new implementation preserves the behavior, obligations, and operating assumptions that made the old system safe to run.

Modernization is controlled change, not translated syntax.

5. Runtime governance is too narrow for SDLC

A coding agent can be governed at the moment it acts.

The enterprise can control who invokes it, which repository it can reach, what tools it can call, which logs are captured, and which actions require approval. Those controls are important. Without identity, permissions, logging, and auditability, the agent becomes another unmanaged actor inside the software estate.

But SDLC risk does not end with the agent action.

The agent may have permission to write code and still produce a change that is unsafe to release. The pull request may be legitimate. The developer may be authorized. The repository access may be approved. The logs may show exactly what happened. None of that proves the change moved through the right delivery path.

The risk lives in the change itself.

A small UI fix, a dependency upgrade, and a modification to an identity workflow may all begin as code changes. They should not move through the same controls. One may need only tests and review. Another may require vulnerability evidence, architecture review, operational signoff, or a release window. A third may need stronger scrutiny because it changes how access is granted, logged, or revoked.

Runtime governance can tell the enterprise what the agent did.

SDLC governance has to tell the enterprise whether the change received the right level of scrutiny for the risk it introduced.

That requires governance to move with the work across planning, coding, review, testing, release, and operations. The enterprise needs to know whether the requirement was understood, whether the architecture was respected, whether dependencies were checked, whether security findings were resolved, whether test evidence is sufficient, whether the release path is valid, and whether operations can support the change after it ships.

Faster code generation pushes more unfinished decisions into the same review queues.

When coding agents generate more pull requests, more fixes, and more modernization candidates, they increase the volume of work entering the delivery system. If governance remains concentrated at execution time, the enterprise may see the agent’s actions clearly while still lacking confidence that the software is ready to ship.

That means risk classification, policy checks, approval paths, test evidence, release readiness, exception handling, and operational ownership should be attached to the work itself. The change record should not become a reconstruction exercise after the useful context has already scattered across tickets, pull request comments, chat threads, and meetings.

The point is not to add another review queue, but to make the path visible enough that the enterprise can distinguish routine work from sensitive work, lightweight review from required escalation, and a clean release from an unexamined shortcut.

Runtime governance records the agent’s action.

SDLC governance records whether the change passed the controls required for its risk.

6. The governed path has to become faster than the workaround

The goal is not to help agents route around enterprise controls. That would create a faster version of shadow IT: more code, more undocumented exceptions, more release pressure, and more risk pushed downstream.

The goal is to make the governed path easier to use than the workaround.

Return to the pull request from the opening. The code is ready before lunch, but the work is waiting on an environment, service account, dependency review, security findings, test data, architecture approval, compliance evidence, or a release window.

An agentic SDLC system should make those blockers visible while the work is still moving. It should recognize that the change touches a payment service, identify affected downstream systems, attach relevant vulnerability findings, prepare the change record, generate the test evidence request, find the right approver, and explain why the release path is blocked.

Governance shows up before the pull request reaches the final queue.

The developer does not have to chase five systems to understand why the work is stuck. The security reviewer does not have to reconstruct context from a diff and a vague ticket. The compliance team does not have to assemble evidence after release, when the useful details have already scattered across chat threads, pull request comments, and meeting notes.

The agent should capture the evidence while the work is happening.

For routine changes, the path can be lighter: confirm ownership, run tests, attach evidence, and move the pull request forward. For sensitive changes, the path can require more evidence, clearer escalation, and explicit risk acceptance. The value is that the path becomes visible, risk-adjusted, and harder to bypass.

The agent can help generate test evidence, draft the rollback plan, prepare release notes, surface affected services, route exceptions, and explain what still prevents the change from moving forward. Done well, the governed path becomes the easiest path because it is the clearest path.

If the workaround is faster, people will use the workaround.

Enterprise software delivery will not get meaningfully faster until the controlled path becomes easier to follow than the shortcut.

7. Wrap Up: Once embedded in SDLC, the agent becomes infrastructure

A coding assistant can remain a tool at the edge of the developer’s day.

An agent embedded in the SDLC becomes something else. It starts to learn how the enterprise builds software: which systems are fragile, which reviews matter, which exceptions recur, which teams own the risk, which release paths are trusted, and which evidence has to exist before a change can go live.

That knowledge is more strategic than code suggestions.

Once delivery memory lives inside the agent, vendor choice becomes harder. The enterprise is no longer moving only a model, an IDE plugin, or a chat surface. It is moving release logic, approval patterns, policy interpretation, modernization history, and operational memory.

Those are sovereignty questions inside the SDLC.

Delivery memory has to live somewhere. If it disappears into one agent surface, the enterprise loses more than prompts or chat history. It loses release logic, approval patterns, policy interpretation, modernization history, and the record of how risk was accepted.

That becomes a hard question after the fact: can leaders reconstruct how the agent shaped a release, why the work moved forward, why it stopped, and who accepted the risk?

This is where my previous article’s shared-agent problem becomes concrete:

Once agents become shared, personal behavior can become institutional behavior. In software delivery, that institutional behavior can shape how code is reviewed, how modernization happens, how exceptions are handled, how releases move, and how risk is accepted.

The coding agent may start as a productivity tool.

But the moment it becomes part of the governed path to production, it becomes part of the enterprise’s delivery infrastructure. It should be treated that way: with clear ownership, portable context, observable behavior, lifecycle controls, and an audit trail that survives the tool surface where the work began.

The code can be ready before lunch.

The release still waits for something harder: trust in the path from change to production.

That is where the next software contest moves: from who can generate the most code to who controls the path from change to production.

1. The personal agent worked because it was personal

The first version felt almost harmless.

A product lead built a small agent around her own work. It read her backlog notes, scanned customer calls, checked the roadmap, looked at open engineering issues, and drafted a product review before every planning meeting. Over time, she tuned it to her taste. It learned that she cared about adoption signals more than internal excitement. It knew she wanted engineering risk called out early. It knew vague customer demand should be treated differently from a signed expansion opportunity. It knew which executives needed a crisp summary and which architects wanted the underlying tradeoff.

It was useful because it was personal.

The agent acted inside one person’s working style. It used her access, her context, her habits, and her judgment. When it was too optimistic, she corrected it. When it missed a dependency, she added the note. When it drafted something clumsy, she rewrote it. The feedback loop was informal, but it worked because the person closest to the work was also the person closest to the agent.

Then the team wanted to use it.

The request sounded reasonable. Put the agent in Slack. Let anyone ask it to review a feature plan. Connect it to Linear, GitHub, and the shared customer folder. Let it prepare the same kind of review for every product pod.

That is where the agent changed categories.

The agent was no longer reflecting one person’s judgment. It was starting to shape the team’s judgment. The same review pattern that had been a private shortcut could now influence how features were prioritized, how risks were described, which customer signals were treated as strong evidence, and which engineering concerns were escalated before release.

Helpfulness was no longer the only operating issue. The harder issue was whose standards the agent was applying.

A personal agent can be governed by proximity. The user invokes it, watches it, corrects it, rejects the weak parts, and owns the consequence when it gets something wrong. That does not make personal agents safe. But it keeps the failure surface closer to one person’s access, attention, and judgment.

Once the agent moves into the places where teams coordinate work, it becomes part of the operating environment.

The first enterprise agent problem begins before full autonomy.

It begins when the agent becomes shared.

2. The model is not the system

The first governance mistake is to look only at the model.

The model may be impressive. It can reason through a product brief, summarize a customer call, inspect a pull request, find contradictions in requirements, and draft a cleaner plan. But inside an enterprise, the model is only one part of the working system.

The more important question is what surrounds it.

What context does the agent receive before it starts? Which documents does it trust? Which tickets, repositories, dashboards, and meeting notes can it reach? What tools can it call? What systems can it write to? What memory does it keep? What evidence does it preserve before its work becomes visible, actionable, or reusable?

That surrounding system is the harness.

The model reasons, but the harness determines how reasoning becomes work. It supplies context, limits tools, controls write access, manages memory, routes output, captures evidence, and enforces when a human has to review the result.

This is why two teams can use the same model and get very different outcomes.

One team has a fragile personal setup. A user opens a chat window, pastes context, asks for a review, copies the answer into Slack, updates the ticket manually, and tries to remember which corrections should be reused next time. The model may be strong, but the workflow depends on individual discipline.

Another team has the same model inside a governed workflow. The agent pulls from approved sources, checks the right tickets and documents, records which evidence it used, drafts the review in the right workspace, flags uncertainty, asks for approval when the risk crosses a threshold, and preserves the correction for future use.

Same model. Different system.

For a personal agent, the harness can be loose because the user fills the gaps. The user remembers the context, filters the answer, applies judgment, and catches many of the mistakes. In shared work, those gaps become institutional risk. The agent is no longer just helping one person think. It is helping the team move work through a repeatable path.

That is why the enterprise cannot govern only the model. It has to govern the system that makes model reasoning operational.

Once the harness becomes shared, private working style can become organizational machinery.

3. Preferences become policy

The risk shows up in the reusable skill.

A product lead creates a command for herself: /plan-pm-review.

The command reviews a feature plan before the weekly product meeting. It checks whether the client evidence is strong enough, whether the engineering dependency is real or speculative, whether the release risk is being softened, whether the success metric is meaningful, and whether the plan needs executive attention before the team spends another sprint on it.

Over time, the command gets sharper. The product lead corrects it. She tells it which customer signals count. She teaches it that three enthusiastic comments from sales are not the same as demand from a committed buyer. She reinforces that architectural debt should be named plainly. She pushes it to separate urgency from importance.

The command becomes useful because it carries her judgment.

Inside her own workflow, that is fine. It is a private review habit encoded into a personal agent. She still reads the output, makes the call, and owns the consequences.

Then the command becomes shared.

Someone adds it to the team agent in Slack. Now anyone can drop in a feature plan and ask for a product review. The agent responds with the same structure, the same weighting, the same escalation logic, and the same language for describing risk.

At first, this feels like leverage. The team gets more consistent reviews. Junior product managers learn what a strong plan looks like. Engineering gets clearer signals. Leadership sees a cleaner summary.

But the organization has also changed something important.

One person’s review style has become a reusable pattern for the team. Her preferences about evidence, risk, urgency, architecture, and escalation are now embedded in a shared workflow. They may be good preferences. They may even be better than the old process. That does not make them neutral.

A shared agent can make a judgment pattern feel procedural. It can make one way of seeing the work feel like the standard way. Over time, people may stop asking where the pattern came from. They may treat the output as the team’s review logic rather than one person’s encoded judgment.

The enterprise does not need to turn every prompt into a policy artifact. Most personal shortcuts should stay lightweight. But reusable skills that shape shared work need a different standard. If a skill affects prioritization, risk classification, release readiness, escalation, customer impact, security review, or financial analysis, it needs ownership.

Someone should know who created it, what judgment it encodes, when it was last reviewed, what evidence it uses, and when it should be revised or retired.

In a personal agent, a preference is a preference.

In a shared agent, a preference can become policy.

4. Memory becomes governance

If a shared skill can turn preference into policy, shared memory can make that policy durable.

A personal agent remembers for one person. It may remember how that person likes a briefing structured, which accounts matter this quarter, which risks should be called out, or which product assumptions have already been challenged. The memory is useful because it saves the user from restating the same context every time.

A shared agent remembers differently.

It may preserve a correction from one review and apply it to the next team’s work. It may learn that certain customer signals are strong, that certain security risks deserve escalation, that a particular architecture pattern is preferred, or that a class of objections should be treated as low priority. Some of that memory will improve the system. Some of it may quietly distort it.

The risk is not only that the agent gets something wrong once. The risk is that the wrong pattern becomes reusable.

A weak assumption can become part of the next recommendation. An outdated compliance interpretation can appear in future reviews. A shortcut used under deadline pressure can become normal. A product leader’s preference can be remembered as if it were a team standard. A temporary exception can survive long after the reason for it disappeared.

At that point, memory becomes part of the governance surface.

Enterprises should not treat shared agent memory as a bottomless notes field. They need to know what kind of memory is being created and who it is allowed to influence. A private correction should not automatically become team memory. A team pattern should not automatically become enterprise memory. A project-specific exception should not become a general rule.

At minimum, shared memory needs provenance. Who contributed it? What evidence supported it? Was it inferred by the agent or approved by a person? When was it last validated? Where has it been reused? How can it be corrected, rejected, superseded, or retired?

These questions are practical. Without them, the enterprise has no reliable way to tell whether the agent is improving with use or accumulating institutional noise.

The appeal of shared memory is obvious. A team agent that learns from repeated work can reduce friction, preserve judgment, and make good practices easier to reuse. But the same mechanism can preserve bad judgment with equal confidence.

In a personal agent, memory is convenience.

In a shared agent, memory is governance.

5. Seven checks before a shared agent scales

The practical test is simple: before a personal agent becomes a shared agent, the enterprise should know what kind of institutional behavior it is about to create.

That does not require a large governance ceremony for every experiment. It does require a sharper review before the agent becomes part of shared work.

Start with seven questions.

Who does the agent act as?
A personal agent usually acts with one person’s access. A shared agent may act for a requester, a team, a service account, or a bounded agent identity. That choice changes everything downstream. It determines what the agent can see, what it can touch, and who is accountable when it acts.

What authority does it have?
The enterprise should know whether the agent can only summarize, whether it can recommend, write to systems, open tickets, trigger workflows, and whether it can make changes that affect clients, employees, infrastructure, money, or compliance.

What can it remember?
Memory should have scope. Private memory should stay private. Team memory should not automatically become enterprise memory. A project exception should not become a general rule. The enterprise needs a way to correct, reject, supersede, or retire memory when it is wrong, outdated, or too narrow for broader reuse.

Who owns the skills?
Reusable skills should have owners when they affect shared work. A skill that drafts a meeting summary may not need much oversight. A skill that shapes release readiness, risk classification, escalation, financial analysis, client prioritization, or security review needs more discipline. Someone should know who created it, what it encodes, when it was last reviewed, and how it is changed.

How is behavior evaluated?
A shared agent needs more than user satisfaction. It needs tests for quality, drift, regression, policy adherence, cost, and recurring failure patterns. The enterprise should be able to tell whether the agent is improving with use or simply becoming more confident in its own habits.

When does it stop or escalate?
A shared agent should have clear limits. It should know when to ask for approval, when to route work to a human, when to flag uncertainty, and when to stop because the action is outside its authority. Escalation is not a weakness. It is how the enterprise keeps judgment attached to accountable people.

Who owns it over time?
Shared agents need stewardship. Without ownership, memory bloats, skills drift, access exceptions accumulate, costs rise, and shortcuts become hidden operating rules. An agent steward does not babysit every task. The steward owns the health of the shared agent as an institutional system.

This is the line enterprises should watch. A shared agent can begin as a helpful assistant and slowly become shadow infrastructure. It may sit in the channels where work is assigned, the tools where decisions are recorded, and the systems where actions are triggered. If no one owns its identity, authority, memory, skills, evaluation, escalation, and lifecycle, the organization may not notice when the agent stops reflecting an approved way of working.

The question is not whether the agent works once.

The question is whether the enterprise can govern how it keeps working.

6. The control plane becomes the consequence

The seven questions point to the same conclusion: once agents become shared, governance cannot live only inside prompts, skill files, or team habits.

A personal prompt can be messy because one person absorbs the mess. A shared agent needs a more durable layer around it. The enterprise has to know who the agent is acting for, what it is allowed to do, which memories it can reuse, which skills are approved, what evidence it must leave behind, and when it has to stop.

That is the role of the control plane.

The control plane is not another agent. It is the layer that governs the conditions under which agents can act. It should make identity explicit, bind authority to role and context, preserve traces, enforce policy, route exceptions, monitor behavior, and support shutdown when an agent no longer meets the standard.

This becomes more important as models improve.

A smarter model may need fewer brittle chains and less hand-holding. It may plan better, recover from failure, summarize more accurately, and carry longer tasks across more context. That does not remove the enterprise’s need for control. Identity, authority, auditability, escalation, rollback, and ownership are responsibility problems. Better reasoning does not make them disappear.

In fact, better reasoning can make the control problem sharper. A weak agent fails close to the user. A capable shared agent can move farther before anyone notices the pattern it is applying. It can touch more systems, reuse more memory, route more work, and make its output feel more procedural because it is coherent.

That is why shared agents need controls outside the agent’s own judgment.

Some controls can be flexible. Others have to be deterministic. A product review agent may be allowed to summarize evidence, identify risks, and propose next steps. It should not be able to rewrite the team’s release criteria, change a client commitment, approve an exception, or commit a new reusable rule without review.

The control plane exists to make those boundaries enforceable.

It also protects the future. Shared agents will change. Models will change. Skills will change. Teams will change. Regulations, costs, vendors, and operating requirements will change. If institutional memory, authority, and workflow logic are buried inside local prompts or one vendor’s agent surface, the enterprise loses leverage.

Once the agent becomes shared, governance has to move out of the prompt and into the control plane.

7. Wrap Up

This is the part of enterprise AI that can look ordinary while it is still small.

A useful personal agent becomes a shared team agent. A shortcut becomes a skill. A correction becomes memory. A preference becomes a pattern. The agent starts showing up in the places where work already happens, and the organization gets the benefit before it fully understands the dependency.

That is why the first governance threshold is not full autonomy.

It is sharing.

Once an agent becomes shared, it can shape how teams review work, classify risk, preserve judgment, escalate issues, and reuse prior decisions. Some of that will make the enterprise better. It will reduce repeated work, spread good practices, and help teams move with more consistency.

But shared agents also create a new kind of institutional machinery. They can carry old assumptions forward. They can make one person’s judgment look procedural. They can preserve a temporary exception as if it were a rule. They can quietly normalize patterns no one formally approved.

The point is not to slow every agent down with process. The point is to know when an agent has crossed from personal productivity into shared infrastructure.

That is the line enterprises need to see clearly.

The next version of this problem shows up in software delivery. Coding agents can help developers move faster, but production still runs through provisioning, security, compliance, network configuration, testing, deployment automation, rollback, and operational ownership.

The next article will look at that gap.

Coding agents can write the code.

They still cannot ship the enterprise.

1. The Enterprise Buys Software. The State Sees Infrastructure.

Enterprise procurement has long been built around vendor risk. Frontier AI adds a deeper exposure: dependence on capabilities shaped by compute, infrastructure, regulation, and state interest.

Procurement becomes harder when the dependency is shaped by power outside the contract.

Imagine a global bank evaluating a frontier AI security system. On paper, the purchase looks familiar. Procurement sees a vendor review. The CISO sees faster vulnerability detection. The board sees a cleaner cyber-risk story: fewer blind spots, faster remediation, better evidence, stronger resilience.

Everyone around the table thinks they are evaluating software.

But the same capability may look very different from outside the enterprise.

A model that can map dependencies across critical systems, reason through access paths, identify brittle infrastructure, and accelerate remediation belongs in a different category from dashboards and scanners. In the right hands, it can help defend critical infrastructure. In the wrong hands, it can expose it.

At that point, the product stops looking purely commercial.

The more difficult procurement consideration begins after purchase: what happens when the capability becomes part of how the enterprise defends itself? Once vulnerability discovery, exposure mapping, remediation planning, and incident response begin moving at machine speed, the system becomes part of the enterprise’s defensive posture rather than an occasional tool.

The enterprise may want to consume the capability commercially. The vendor may want to sell it at scale. But a government may see something else: a strategic cyber capability sitting inside the private market.

That tension is easy to miss because enterprise AI still arrives wearing familiar clothes. It comes through sales decks, pilots, procurement workflows, security reviews, integration plans, and subscription terms. It looks like the next generation of enterprise software.

But frontier AI does not behave like ordinary software.

It depends on scarce chips, energy, data centers, cloud capacity, model access, security restrictions, jurisdiction, and national-security pressure. The deeper it moves into security, finance, industrial operations, and critical infrastructure, the less credible it becomes to treat it as just another product category.

The risk is not only vendor lock-in. It is strategic dependency: the point where an enterprise can buy, integrate, and depend on a capability, but still not control the forces that determine whether it remains available, unrestricted, affordable, commercially usable, or governed only by contract.

That is the end of innocent AI procurement.

2. The SaaS Mental Model Is Breaking

Enterprise software used to hide its machinery.

That was part of the appeal. A vendor delivered the application. The enterprise evaluated the features, negotiated the contract, reviewed the security posture, checked the integrations, and monitored the service level. If the product worked, the machinery behind it mostly stayed out of view.

That mental model shaped a generation of technology procurement:

• Could the vendor deliver?

• Would the system integrate?

• Was the data protected?

• Could the contract manage uptime, liability, support, renewal, and exit?

Frontier AI adds questions that traditional SaaS procurement was not built to answer. It brings the hidden machinery back into the open because the capability depends on things enterprise buyers cannot treat as background assumptions: advanced chips, concentrated data centers, electrical capacity, cloud regions, model access, inference economics, cybersecurity controls, data residency, export restrictions, and government scrutiny.

It also breaks a basic assumption of enterprise control: that change can be isolated. Traditional procurement assumes the enterprise can evaluate a product, test the integration, monitor the vendor, and manage changes through release cycles. Frontier AI makes that harder because the model, policy layer, training data, inference environment, cloud region, pricing, safety restrictions, and regulatory posture may all change while the enterprise is changing how it uses the capability.

That makes frontier AI different from most SaaS products the enterprise has purchased before.

Most enterprise buyers encounter AI through the application layer: a chatbot, a copiloted workflow, a security assistant, a planning tool, a search interface, a code assistant. That visible layer makes frontier AI feel like software.

But the capability underneath is industrial. The application may arrive through a procurement workflow, but the capability depends on infrastructure the enterprise does not directly control.

CRM, productivity suites, and many cloud platforms could usually be evaluated through application fit, service reliability, integration, security, and commercial terms.

Frontier AI is harder to contain inside that frame because the product is only the visible surface. Beneath it sits a supply chain of compute, energy, jurisdiction, policy, and strategic pressure.

This is critical when an enterprise starts depending on AI for work that can’t be paused: fraud detection, vulnerability management, supply chain planning, claims routing, customer operations, industrial scheduling, or incident response. In those domains, degraded access is more than a convenience problem.

So in addition to considering whether the vendor has the right feature set, procurement now has to also ask what has to remain true for that capability to keep working:

Does the vendor have reliable access to compute? Can the workload run in the jurisdictions where the enterprise operates? Can logs, prompts, model outputs, and evidence be retained under the right controls? Can capability be throttled, restricted, or tiered? Can the enterprise continue operating if the frontier model becomes unavailable or politically constrained?

This is the part the SaaS playbook trained enterprises not to see. For years, the infrastructure layer disappeared from the application buyer’s view. Frontier AI reverses that. The visible product may be a security assistant, a fraud model, or an operations planner, but the real dependency may be electrical capacity, chip allocation, data-center geography, model access, and the government policies shaping all of them.

SaaS allowed many buyers to treat infrastructure as background. Frontier AI makes infrastructure part of the procurement risk.

3. Mythos Was the Warning Shot

Mythos showed how quickly a security tool can become a strategic capability.

A normal cybersecurity product helps an enterprise see more of its environment. It scans assets, flags vulnerabilities, ranks findings, and gives security teams another queue to manage. That is familiar: the enterprise understands the product as software operating inside a security workflow.

A frontier AI security model points to something different.

If a model can reason across software dependencies, access paths, misconfigurations, exploit chains, aging libraries, exposed services, and brittle infrastructure, it compresses expertise that used to be scarce, fragmented, and human-intensive.

This capability is valuable for defense precisely because it is sensitive: the same model that helps a bank identify the weak path into a payments system could help an attacker understand where to look. The same capability that helps an insurer prioritize claims-platform remediation could expose how older systems are stitched together. The same capability that helps a manufacturer find risk inside plant operations could reveal where digital fragility meets physical infrastructure.

There is another lesson inside Mythos: even the frontier AI company itself can lose control of its own warning label.

For months, the vendor (in this case, Anthropic) may describe the capability in the language of safety research, threat modeling, red teaming, and responsible disclosure. That language is meant to show seriousness. It tells clients the vendor understands the risk.

But the same language can also become evidence for regulators, national-security officials, and foreign governments. If a company spends months explaining that a model can accelerate cyber discovery across critical systems, the state may eventually treat that claim as operationally real.

That is what makes Mythos more than a product controversy. It shows that frontier AI risk is not only technical. It is interpretive. The same model can be described by the vendor as responsibly constrained, by clients as commercially useful, and by the state as strategically sensitive.

That is also where ordinary model risk becomes capability risk. A hallucinated vulnerability or noisy recommendation can usually be handled as model risk through testing, monitoring, tuning, and governance. But a capability that accelerates discovery across critical systems creates a different exposure: capability risk.

This changes the testing considerations. The enterprise cannot only check whether the model finds the right vulnerability or ranks the right exposure. It has to consider whether the capability can be misused, overextended, redirected, or induced to reveal more than the enterprise intended. In a frontier security system, regression testing is not only about proving that old controls still work. It is about proving that the new capability has not created a faster path to misuse, misclassification, data exposure, or operational overreach.

Correct model behavior is only one part of the question. Access, terms of use, sector restrictions, country restrictions, monitoring, and obligations to regulators or governments also matter.

That is why Mythos should not be understood only as a cybersecurity story, but rather as an early signal that frontier AI may create capabilities enterprises want to buy, vendors want to monetize, and governments may not want treated as normal software.

My previous article, Mythos Didn’t Create the Crisis. It Exposed the Ungoverned Enterprise, was about what happens when AI exposes enterprise risk faster than institutions can respond.

This article is about what happens when the capability that exposes the risk becomes strategic in its own right.

4. When Automation Becomes Mandatory

The most uncomfortable part of this shift is that some automation may stop being optional.

In ordinary procurement, automation is treated as an efficiency choice. The enterprise decides where it wants speed, where it wants human review, and where it wants manual fallback. But in cybersecurity, fraud detection, infrastructure remediation, and incident response, that assumption weakens. If adversaries, vulnerabilities, and operational failures move at machine speed, the enterprise may not be able to preserve human review as the primary control.

Human accountability remains, but governance has to move into the operating design: bounded autonomy, approved action classes, policy enforcement, observability, rollback, and degraded-mode plans.

Procurement has to consider whether the enterprise can rely on the capability when response time collapses, and whether it can constrain the system when autonomy becomes necessary.

That is where the procurement relationship stops being purely commercial, which leads us to “The New Triangle.”

5. The New Triangle: Enterprise, Vendor, State

For most of the SaaS era, the enterprise-vendor relationship was commercially legible.

The enterprise bought a product. The vendor delivered a service. The contract defined the operating boundaries: uptime, security, privacy, support, liability, data handling, renewal, and termination. Regulators could intervene, but they usually sat outside the core transaction.

Frontier AI changes these relationships.

The enterprise still wants a product it can use. The vendor still wants a market it can sell into. But the state, meaning government, regulators, national-security agencies, and industrial-policy actors, is no longer just a distant rulemaker. In the most sensitive AI categories, the state becomes a live actor in the system.

The transaction now has three centers of gravity.

The enterprise wants capability, reliability, auditability, continuity, and commercial leverage. It wants the model to work, the service to remain available, the data to stay protected, the outputs to be explainable enough for its risk posture, and the cost to be predictable enough for planning.

The vendor wants scale: clients, revenue, infrastructure access, market defensibility, regulatory permission, government credibility, and freedom to keep improving the model. It may present itself as a commercial supplier, but in frontier AI its most important assets may depend on scarce compute, privileged infrastructure partnerships, government contracts, and permission to commercialize sensitive capabilities.

The state wants national advantage, cyber defense, industrial capacity, energy security, domestic infrastructure, restricted adversary access, and influence over capabilities that may affect critical systems. It may want rapid commercialization for competitiveness and tighter control over the most sensitive versions.

Those interests can align for a while. A bank wants stronger cyber defense. The vendor wants to sell an advanced model. The government wants the financial system better protected.

The alignment becomes fragile when the capability moves from experimental to operationally necessary.

Export rules change. A model is judged too sensitive for broad access. A regulator asks where inference happens and whether evidence can be retained. A government directive targets one class of users, and the vendor’s practical response can affect clients beyond the original target.

Suddenly the enterprise has to consider whether it can still rely on a capability whose operating conditions are being shaped outside the contract.

That is the point where ordinary procurement language starts to fail, because the vendor is no longer just a supplier.

The Anthropic Mythos/Fable access dispute made the triangle visible.

A client may believe it is buying access from a vendor. Operationally, that is true. Commercially, that is true. But strategically, access may still depend on the jurisdiction that governs the vendor, the infrastructure, the model weights, the employees, the cloud region, or the export regime around the capability.

That is a different kind of dependency.

For a non-U.S. enterprise, the lesson is blunt: a frontier model supplied by an American vendor may remain subject to American national-security judgment even when the customer, workload, regulator, and business process sit somewhere else.

The same logic applies in reverse for any country trying to build sovereign AI capacity. Local control is not only about data residency. It is about who can interrupt access, who can narrow the capability, who can inspect the evidence, and who has authority over the infrastructure that keeps the model running.

Most AI products will remain ordinary commercial tools, not national-security issues. But the closer AI moves to cybersecurity, finance, industrial operations, critical infrastructure, intelligence, defense, or large-scale automation, the more this triangle matters.

The enterprise may still sign a commercial contract. But the real operating environment may be shaped by conditions beyond the contract: power, policy, infrastructure, and strategic priority.

6. Strategic Dependency Is Not Vendor Lock-In

Enterprises understand vendor lock-in.

Data becomes hard to move. Integrations become expensive to rebuild. Workflows become customized around one platform. Pricing power shifts to the supplier. The exit path exists mostly in theory.

That can be frustrating and strategically dangerous, but it is still a market problem.

Strategic dependency is a power problem. It begins when the capability itself becomes so important that normal vendor-risk controls no longer describe the exposure.

This dependency is complex because the enterprise may not be the actor changing the system. A model update, safety restriction, cloud-region change, API policy, government rule, compute constraint, or vendor roadmap shift can alter the capability from outside the enterprise’s own change-control process. The enterprise may not have changed its workflow, but the capability underneath the workflow may have changed anyway.

Switching vendors is only one part of the exposure. The deeper issue is whether the capability remains available, unrestricted, affordable, legally usable, operationally stable, and governed by commercial terms when larger forces act on it.

A company may be able to negotiate better support terms. It may be able to demand data portability. It may even maintain a credible second vendor. But those controls may still not fully answer the deeper issue: what happens when the more capable versions of the system depend on scarce compute, sensitive model access, export restrictions, energy availability, government scrutiny, or national-security priorities?

That is not traditional lock-in, but dependency on a capability shaped by power.

Consider cybersecurity. An enterprise may want the most advanced AI model available to reason across vulnerabilities, access paths, misconfigurations, legacy systems, and exploit chains. But if that capability becomes sensitive enough, it may not be distributed like an ordinary product feature. Access could be tiered. Usage could be monitored. Certain sectors could receive priority. Certain countries could face restrictions. The most capable version may be available only under special conditions, while the commercially available version becomes safer, narrower, or delayed.

Consider finance. A bank may rely on AI to detect fraud patterns, stress liquidity signals, monitor transaction anomalies, or accelerate investigations. But once that system becomes embedded in risk operations, the enterprise is no longer only dependent on a vendor. It is dependent on the continuity of model access, the jurisdiction where inference happens, the auditability of outputs, the availability of logs, the regulator’s acceptance of the system, and the vendor’s ability to keep serving that capability under pressure.

Consider industrial operations. A manufacturer may use AI to optimize production schedules, supplier substitutions, energy consumption, and maintenance decisions. The system may look like software, but its performance depends on compute capacity, real-time data flows, industrial connectivity, local regulations, and the availability of models trained or tuned for operational complexity. If those constraints change, the business may lose part of its operating rhythm, not just a feature.

This is the change:

• Vendor lock-in asks whether the enterprise can leave.

• Strategic dependency asks whether the enterprise can continue to operate when the capability it depends on is constrained by forces outside the contract.

While commercial contracts are good at defining obligations between parties, they are inherently weak at neutralizing scarcity, jurisdiction, geopolitical pressure, infrastructure limits, or national-security intervention.

The enterprise still owns the use case, including the data, workflow, and even the governance model around the deployment.

But if the underlying capability sits inside a larger system of compute, energy, data-center capacity, policy, jurisdiction, and state interest, ownership and control become partial.

Vendor lock-in is a market problem.

Strategic dependency is a power problem.

7. Wrap Up: What Enterprise Leaders Should Ask Now

The practical response is to separate ordinary AI procurement from critical capability procurement.

An assistant that summarizes internal documents is one kind of risk. A model embedded in fraud detection, vulnerability management, trading surveillance, claims routing, engineering workflows, industrial scheduling, or incident response is another. Once AI enters the operating rhythm of the enterprise, access is no longer a convenience. It is continuity.

In this environment, there are five questions enterprise leaders should be asking.

1. Criticality: is the capability becoming operationally critical?

That requires a more precise view of where AI sits in the business. Is it assisting a user, or is it becoming part of how work gets routed, investigated, approved, optimized, defended, or recovered? Is it a productivity layer, or is it becoming part of the operating rhythm?

2. Dependency: what does the capability depend on?

That dependency may include frontier model access, scarce compute, a specific cloud region, cross-border inference, security logs, real-time operational data, specialized cyber reasoning, vendor-managed logs, regulatory acceptance, or government tolerance for where and how the system is used. Those dependencies define the real operating boundary of the deployment.

Procurement should ask who can interrupt access besides the vendor. That includes the vendor’s government, the workload’s jurisdiction, the cloud provider’s jurisdiction, regulators, export-control authorities, and any contractual or legal regime that can alter who may use the model. It is not just about whether the vendor promises uptime, but about who has authority to make the service unavailable, narrower, slower, more expensive, or legally unusable.

3. Change: what can change outside the enterprise’s control?

Traditional procurement assumes change can be managed through release notes, service reviews, testing cycles, contract terms, and change windows. Frontier AI weakens that assumption. The enterprise may not change its workflow, but the capability underneath the workflow may change anyway.

The model may change. Access may narrow. Logging may shift. A cloud region may become unavailable. A regulator may alter where the system can operate or which clients can receive the most capable version.

The shifting consideration is this: what parts of this capability can change without our approval, how will we know they changed, and what proves the system still behaves within our risk tolerance?

For critical AI deployments, change control cannot stop at the enterprise boundary. It has to include model updates, access policy, inference location, logging, data retention, safety restrictions, pricing tiers, throttling, and regulatory constraints.

4. Degradation: what happens when access changes?

Leaders should treat human review as one fallback option, not the universal answer. In some domains, the environment may move too quickly for humans to review every decision before action. The relevant question is whether the enterprise has defined which actions require human approval, which can be automated within bounded limits, which require sampling or audit, and which must fall back to slower deterministic or manual paths.

Every critical AI deployment needs a degraded-mode plan. If the best model becomes unavailable, access is throttled, jurisdictions diverge, or the vendor narrows the capability, the enterprise should already know the fallback.

That fallback might be a smaller model, another provider, a deterministic workflow, or a slower human process.

The point is simple: do not design the fallback during the outage.

5. Ownership: who owns the risk?

Strategic dependency has to be owned across procurement, CIO, CISO, risk, legal, compliance, operations, finance, and the board. Procurement can negotiate terms. Security can review controls. Architecture can design fallback paths. Compliance can define evidence requirements. But none of those functions alone can answer the larger question: when does an AI capability become important enough that the enterprise must manage it as infrastructure, not software?

For the most critical capabilities, that question belongs at board level.

The board does not need to manage model architecture, vendor architecture, or technical fallback design. That belongs with the CIO, CISO, CRO, legal, compliance, procurement, and operations.

But when an AI capability becomes material to resilience, cybersecurity, regulated operations, or business continuity, it becomes an oversight issue. Directors should know which capabilities are becoming operationally critical, what external dependencies sustain them, and what happens if access is degraded, restricted, delayed, repriced, or politically constrained.

[Downloadable field checklist: I turned these five questions into a short PDF for enterprise leaders evaluating critical AI capabilities.]

AI Dependency Map Checklist

6.6KB ∙ PDF file

Download

THE AI DEPENDENCY MAP Five questions for critical AI procurement when frontier AI starts behaving like infrastructure.

Download

SaaS made software feel commercially contained. The product lived inside the contract. The vendor relationship could be managed through service levels, data terms, security reviews, pricing, and exit provisions.

That is no longer sufficient for the most consequential AI systems.

Enterprises that miss this shift will think they are managing vendor risk while they are accumulating strategic dependency.

When a capability becomes operationally necessary, externally shaped, and strategically sensitive, procurement is no longer just buying software. It is choosing a dependency structure.

That is the end of innocent AI procurement.