On the evening of June 12, 2026, Anthropic received an export control directive from the U.S. Commerce Department and, within hours, pulled its two most capable models, Claude Fable 5 and Mythos 5, offline. Not just for the foreign nationals the order targeted, but for every customer. Selective compliance was impossible, so the whole thing went dark.

If your product, your workflow, or your company depended on Fable 5 that Friday night, you did not get a migration window. You did not get a deprecation notice. You got a switch flipped by someone who is not your vendor and does not answer to your roadmap.

This is the first time a leading AI company has taken a publicly deployed model offline because the federal government told it to. It will not be the last. And it is the clearest argument yet for a principle that should already be at the center of every serious AI strategy: do not tie yourself to one provider.

This was not a fluke, and it was not Anthropic’s fault

It is worth being precise about what happened, because the lesson is in the details. The directive came from Commerce Secretary Howard Lutnick, written with the Bureau of Industry and Security. It cited national security concerns reportedly tied to a jailbreak another company claimed to have found. Anthropic disagreed with the government’s reading of the risk, but it complied anyway, because that is what you do when the federal government hands you an export control order at 5:21pm.

Notice what is missing from that chain of events: you. The customer had no seat at the table. The model you built on disappeared because of a dispute between a regulator and a vendor over a vulnerability you had nothing to do with. Your uptime became collateral.

That is the real exposure of single-provider dependence. It is not that any one company is unreliable. Anthropic acted responsibly and fast. The problem is structural. When your strategy routes through exactly one provider, every risk that provider carries becomes your risk, and most of those risks are completely outside your control.

The Fable 5 shutdown is just one item on a long list

Government intervention is dramatic, so it makes the news. But it is only one of many ways your preferred model can vanish on a random Tuesday. A provider-agnostic strategy is not insurance against one rare event. It is insurance against an entire category of events that happen constantly:

A model gets deprecated. Providers retire older versions on their own schedule, and the replacement often behaves differently enough to break your carefully tuned prompts.

Pricing changes overnight. The economics that made your use case viable can be repriced at the vendor’s discretion, and you have no leverage to negotiate if you cannot credibly walk away.

Rate limits and capacity crunches hit. During peak demand, single-provider users get throttled while the provider prioritizes its largest accounts. You wait in line.

An outage takes the API down. Every provider has bad days. If theirs is your only option, their bad day is your outage too.

Terms of service shift. Acceptable-use policies tighten, sometimes retroactively, and a use case that was fine last quarter is suddenly prohibited.

Geopolitics and export controls bite. As Fable 5 just proved, your access can be revoked based on where your users are located or what passport your employees hold, with no notice and no appeal.

A model regresses. A new version is supposed to be an upgrade, but it quietly gets worse at the one thing you actually needed it for, and the old one is gone.

Any single one of these can take you offline. Tie yourself to one provider and you are exposed to all of them at once, permanently.

Provider-agnostic is the only future-forward posture

The lesson is not “pick a different provider.” Swapping one single point of failure for another solves nothing. The lesson is to build so that no single provider can take you down in the first place.

A provider-agnostic platform treats models as interchangeable components rather than load-bearing walls. When one model becomes unavailable, whether because a regulator pulled it, a vendor retired it, or a price hike made it uneconomic, you reroute to another and keep running. The switch is a configuration decision, not a rebuild. Your prompts, your business logic, and your users never see the seam.

This posture buys you more than survival. It buys you leverage. When you can move between providers freely, you negotiate from strength, you route each task to whichever model does it best and cheapest, and you adopt new capabilities the day they ship instead of being locked to one vendor’s release cycle. Optionality is not just defensive. It is a competitive advantage.

The companies that treated multi-provider flexibility as a nice-to-have spent Friday night scrambling. The ones that built agnostic from the start changed a setting and moved on.

The takeaway

Fable 5 going dark was not a freak accident. It was a preview. The specific cause this time was an export control order, but the underlying truth is permanent: the availability of any single model is not something you control, and building your AI strategy as if it were is a bet you will eventually lose.

Treat model providers like cloud regions or payment processors. You use the best one available, you keep more than one wired up, and you can fail over without drama. That is not pessimism about AI. It is the only way to build on it with confidence.

Anchor your strategy to a platform, not a provider. Everything above the model layer is yours to keep. Everything tied to a single vendor is theirs to take away.

And that capability is exactly why the fine print changed.

A model this strong can be misused in ways weaker models can’t. Some attacks only become visible across many requests: send hundreds of prompt variations and hope one slips through. You can’t catch that by looking at requests one at a time. So Anthropic now retains all Fable 5 traffic for 30 days to analyse patterns of misuse. On every platform: direct API, Bedrock, Google Cloud, Azure. Zero-retention agreements don’t apply to this model class. Anywhere.

I think Anthropic is being honest here, and that matters. Capability and safety analysis come as a package now.

Which means this is not an Anthropic story. Every provider shipping frontier models will face the same trade-off, and I expect they’ll land in the same place. Retention windows are becoming a structural part of using the best AI.

So the question changes. It’s no longer “which provider promises not to keep my data”. That promise is expiring. The question is: what do they receive in the first place?

That’s why we built Aimable the way we did. Sensitive data, names, client information gets filtered out before anything reaches the model. You keep a logbook of exactly what was sent. And work that should never leave your environment runs on an EU-hosted or local model instead, while your team works in the same environment either way. A 30-day window at the provider becomes a manageable risk instead of a blocker.

The best models will keep getting better. The terms will keep getting stricter. Controlling your data is no longer a compliance checkbox. From today, it’s the price of admission to the frontier.

• 9 out of 20 systems fabricated information and invented treatment suggestions that were never discussed.

• 12 out of 20 inserted incorrect drug information into patient notes.

• 17 out of 20 missed key details about patients’ mental health.

• And in the procurement scoring? Accuracy of medical notes was worth 4% of the total score. Having a domestic presence in Ontario was worth 30%.

Read that again. The accuracy of the medical record, the thing the entire tool exists to produce, was worth less than whether the vendor had a local office.

The real problem isn’t that AI hallucinates

Everyone knows AI hallucinates. That’s not news. The real problem is that most organisations are deploying third-party AI tools as black boxes. The model runs somewhere else. The prompts are hidden. The outputs go straight into a system of record (a patient chart, a contract, a financial report) with no log, no diff, no review trail, no way to ask “what did the model actually do here, and on what basis?”

When a human makes a mistake in a medical note, there’s a paper trail. A timestamp. A signature. An audit you can run.

When an AI scribe inserts a drug the patient never took, what do you have? Usually nothing. The vendor’s API returned a string. The string got saved. End of story.

OntarioMD’s recommendation was that doctors should manually review every AI-generated note. Sure, except the report also points out that none of the approved systems even have a mandatory attestation feature. The oversight isn’t built in. It’s an honour system layered on top of a black box.

What “oversight” should actually look like

This is the gap we built Aimable to close. Not as a model itself, but as the layer underneath the models. The plumbing that records what was asked, what was answered, what context was used, what was changed, and by whom.

The principles are not exotic:

1. Every AI interaction is logged. Input, output, model version, prompt, retrieved context. All of it. Queryable.

2. Every output that touches a system of record is attributable. You can point at a sentence in a patient note, a contract clause, a generated report, and trace it back to the exact model call that produced it.

3. Evaluation is continuous, not procurement-only. Ontario evaluated these systems once during procurement, using simulated recordings, and then sent them into production with 5,000+ physicians. A central oversight layer lets you keep evaluating against real outputs by sampling, flagging drift, catching the 12-out-of-20 drug error problem before it becomes a coroner’s report.

4. The choice of model is a governance decision, not a vendor lock-in. When the underlying model is configurable rather than fused into the product, you can swap, A/B test, or roll back without rebuilding the application. You can route sensitive workloads to models that pass your bias and accuracy tests.

The Ontario scoring rubric (30% domestic presence, 4% accuracy, 2% bias controls) is what happens when you treat AI as a procurement problem instead of an operational one. Procurement is a one-shot evaluation. Operations is forever.

The uncomfortable conclusion

If you’re a hospital, a law firm, an insurer, a bank, a government department, anywhere a wrong word costs real money or real harm, and you’re letting a third-party AI tool write directly into your records without a central log and an evaluation layer in between, you are operating without supervision. Not the model. You.

Ontario didn’t get unlucky with bad vendors. They got the inevitable result of buying AI the way you’d buy a fax machine: pick one, plug it in, hope it works.

The lesson from this audit isn’t “AI scribes are bad.” Some of them, presumably, are fine. The lesson is that without a central system watching the watchers, logging, attributing, evaluating, and giving humans a real surface to inspect, you have no way of knowing which is which until the damage is in someone’s chart.

We can keep treating AI as magic that lives inside vendor products. Or we can treat it like every other piece of critical infrastructure: with logs, audits, and an oversight layer that doesn’t trust anyone by default.

I know which side of that line I want our healthcare system on.

Primary source: Office of the Auditor General of Ontario, Special Report on AI in the Public Sector (2026). Press coverage: CBC News, 13 May 2026.

Both vehicles do the same thing. They take the Palantir playbook off the shelf. Capital from asset managers, deployed as engineers who sit next to clients and build the workflows the model is supposed to inhabit. Anthropic’s own description is honest about it: “an engagement might begin with the company’s engineering team sitting down with clinicians and IT staff to build tools that fit into the workflows staff already use.”

This is a real shift. The labs that spent two years insisting they were just APIs are now showing up with people. Which is, finally, an honest answer to the question every enterprise buyer has been asking. Who is going to make this actually work in our environment?

We built Aimable on the same observation. Software alone does not get a regulated bank, a healthcare provider, or a 200-person SaaS to run AI on their real workflows. You need the software, and you need humans who can sit in the room and configure it for what the team actually does. So we agree with the bet. Software plus services is how AI lands in organisations that have something to lose.

Where we diverge is the line of trust.

If your forward-deployed engineer works for Anthropic, the trust sits on Anthropic’s side. If they work for OpenAI’s new entity, the trust sits there. You inherit a model roadmap, a data-handling posture, a zero-retention promise, and an exclusivity gravity that gets stronger every quarter. When that model is deprecated, when the pricing changes, when the legal posture shifts, the cost of unwinding is whatever your team built on top of it.

We start from the other side. Aimable installs in your environment. The Workbench is what your team opens instead of ChatGPT. The Platform behind it sits between your people and any AI model. OpenAI today, Anthropic tomorrow, a local model when the conversation is too sensitive to leave the building. Your services come from us, but your data, your logbook, and your rules stay on your side. Switching the model underneath is two lines of code, not a migration.

That is the part of the bundle worth being model-agnostic about. The model is a component. The trust layer is not.

This is not a critique of the JVs. They are going to do well, and forward-deployed engineering is the right shape of the work. We just think the engineers should be on a team that doesn’t also own the model.

The same day, Ming-Chi Kuo reported that OpenAI is building its own phone, with MediaTek and Qualcomm on the chips and Luxshare on manufacturing, targeting mass production in 2028. This is a second, parallel hardware track on top of the Jony Ive program announced last year. The Ive lineup, reportedly speaker first at $200 to $300, then glasses and a lamp, has consistently been described as not a phone, and possibly screenless. The phone is something else. Sam Altman hinted at the shift on X the day before, posting that it “feels like a good time to seriously rethink how operating systems and user interfaces are designed.”

OpenAI just gave up one kind of exclusivity. On the same day, it told the world it is racing to build a much deeper one.

Microsoft was relaxed about giving up its lock because Microsoft has Office, Azure, Windows, GitHub, and more than 400 million enterprise seats with their hands on its products every day. OpenAI does not have any of that. What OpenAI has, and what its valuation depends on, is the relationship people are forming with ChatGPT. That relationship has so far lived inside someone else’s browser, on someone else’s phone, billed through someone else’s app store. That is a problem if you want to be the company that owns the next computing platform.

If you cannot keep one cloud as your exclusive distributor, you become the distributor. You build the device. You make the model the operating system. You put a microphone on the desk, a camera on the wall, glasses on the face, and a phone in the pocket. You stop being a feature inside someone else’s stack. You become the stack.

This is not a phone story. It is a runtime story.

A phone is a microphone, a camera, a screen, a calendar, a contact list, a location feed, a payment method, and a permanent companion. Owning a phone OS means seeing every app the user opens, every conversation they have near it, every place they go, every meeting they take. The model that lives there does not need to be jailbroken into the user’s life. It is the user’s life by default. Cloud exclusivity could never give you that. Microsoft just sold the cheap kind of lock-in. OpenAI is trying to build the expensive kind.

Who actually wants a phone owned by OpenAI?

Apple has spent twenty years earning the right to be trusted with the device people sleep next to. They have made themselves boring on purpose. They publish privacy whitepapers. They put the secure enclave on the silicon. They have been sued by their own government over encryption and held the line. None of that is an accident. It is what it takes for a normal person to feel okay about a microphone-equipped supercomputer in their pocket.

OpenAI does not have any of that. It has roughly three and a half years of brand, since ChatGPT launched in November 2022. It has a famously volatile board. It has shipped more than one policy reversal on data retention. It has a CEO who has been fired and rehired by his own company inside a fortnight. It is, by every measure that matters for a device buyer, a young company in a hurry, building a category that depends entirely on trust it has not yet earned.

The 9to5Mac comment thread wrote itself. “There is a graveyard filled with iPhone competitors.” True, and worth saying, but not the point. The graveyard is full because the iPhone’s moat was never the chips or the camera. It was, and is, structural trust. A device people are willing to live with. OpenAI cannot acquire that kind of trust faster than it can manufacture a phone. And the people most likely to skip the OpenAI phone are not techies. They are everyone else.

When that phone ships, some of your employees will buy it. So will some of your customers. They will walk into your meetings carrying a device that is, by design, capturing the room and feeding it to a model trained, owned, and updated by a company on the other side of the Atlantic that may or may not still exist in its current form by the next funding round. Most organisations have no policy for that. Most are not going to have one in 2028 either, until something goes wrong with a recording of a board meeting, a customer call, or a clinic appointment.

Microsoft’s exclusivity ending was, in itself, good news. The world is multi-model. Your AI strategy can stop being your cloud vendor’s strategy. OpenAI’s response, owning the device, points the other way. One company trying to become the entire stack at the same moment the rest of us are concluding that no single stack should win.

The answer is the same as it was on Monday. Your model can change. Your cloud can change. Your device can change too. None of that is yours to control. What can be yours, what has to be yours, is the layer between any of those things and the people in your organisation. Your data, your verified knowledge, your rules, your record of what happened. The thing that holds while everything else is being rebuilt around it.

Microsoft has given up trying to own the user through the cloud. OpenAI is trying to own the user through the phone. Neither of them is going to govern your organisation’s AI for you.

That is the work.

They asked it a simple question. It got the answer wrong.

The information was there. The model could read it. The relevant fact was sitting somewhere in the middle of 180,000 tokens of history, and the system never found it.

This is well documented now. Drop the same fact in the middle of a long context and accuracy can fall by more than 30 percent. Researchers call it “lost in the middle.” Anyone who has actually shipped these systems calls it Tuesday.

I bring it up because it is exactly the trap most organisations are walking into with AI right now, only on a much bigger scale.

More is not the same as better

The pitch from the big platforms keeps getting bigger. Bigger context windows. Bigger models. Bigger document upload. Throw it all in. The AI will figure it out.

It will not. Not reliably. Not at the moments that matter.

Storage without retrieval is a library with no catalog. You can have every document the organisation owns sitting in a vector database. Every policy. Every email. Every contract. If the system cannot find the connecting piece between three facts, it cannot answer a question that crosses two of them. And almost every real question crosses at least two.

“Was the project Alice runs affected by Tuesday’s outage?” The system has the fact that Alice leads Project Atlas. It has the fact that Project Atlas runs on the database that went down. It has the incident report. None of these facts share keywords with the question. None of them know about each other. The connective tissue is missing.

That is not a model problem. No bigger model fixes it. It is a structure problem.

The same problem, one floor up

Now zoom out from a single AI tool to the organisation that wraps it.

Compliance teams are doing the same thing. Procurement keeps adding vendor lists. Legal keeps adding contract templates. Risk keeps adding control frameworks. IT keeps adding tools. Everything is filed. Everything is searchable. None of it is connected.

When an auditor asks who approved which AI tool for which department under which policy, the answer is somewhere in the pile. Good luck finding it before the meeting ends.

Bigger does not equal clearer. A flat pile of policies is a library with no catalog. A flat pile of AI tools is the same thing. A flat pile of conversations between your team and ChatGPT is the same thing again, with the added problem that it is not even your pile.

Trust comes from structure, not from volume

This is the reason we built Aimable around a platform rather than around a chat interface. People keep asking us why we did not just put a nice frontend on top of GPT and call it a day. The answer is that the frontend is the easy part. The hard part is the structure underneath.

Spaces are not folders. They are the thing that says: this team, this purpose, this knowledge, these rules.

Collections are not document stores. They are verified, indexed, attributed sources that an AI can ground an answer in and cite back to.

Policies are not a PDF in SharePoint. They are enforced at the moment a request is made, before any data leaves your environment.

A logbook is not a list of events. It is the connective tissue that ties a question, the data it touched, the rules that applied, and the answer that came out, into one tamper-resistant record.

None of this is glamorous. None of it goes viral on LinkedIn. But it is the difference between an organisation that can actually use AI on its real work and an organisation that has a chat tab and a growing pile of risk.

Memory that learns, instead of memory that piles up

There is a second insight worth borrowing from how serious AI systems handle memory.

A good memory system does not just store events. It consolidates them. Repeated specific moments distil into general knowledge. The system notices that users keep asking for the same kind of summary, that one knowledge source keeps producing good answers and another keeps producing nonsense, that a particular policy keeps getting in the way for no real reason. Those patterns become rules of their own.

Most organisations do not have anything like this. They run AI pilots for a year and end up with the same set of guesses they started with, plus a folder full of slide decks. There is no compounding. Every project starts from scratch.

A trusted AI platform should make this kind of compounding happen by design. The more your people use it, the more your organisation learns about how it actually wants AI to work. Which purposes pay off. Which sources matter. Which rules need sharpening. That learning sits with you, in a structure you control, not in a transcript inside someone else’s product.

Where this goes

Building with AI keeps getting easier. A consultant on site for a week can ship an internal tool. An intern can spin up an agent over the weekend. Marketing teams are running their own assistants. Sales has three different AI note takers in the same call. This is, on balance, good. The barrier to creation has fallen and that energy should not be wasted.

But every one of those tools is a fact in a growing pile. Without structure, the pile gets bigger and the organisation’s grip on what it owns gets weaker.

The question for the next two years is not which model you pick. It is whether the things you build with AI are connected to anything. To your knowledge. To your rules. To each other. To a record you can stand behind.

Storage is not intelligence. Structure is.

That is the work.

When I went looking, our meeting-analysis agent had been silent for five days.

It turns out this is where most of my agent work actually happens. Not in the build. In the weeks after.

The setup is the seductive part. You wire up an agent, give it a clear job, and on day one it works. Within a week your team is using it as if it had always been there. That trust is the thing you build a product on. It’s also the thing you can lose in a single quiet week.

What actually broke

What had actually happened was a small cascade. The agent connects to a tool we built ourselves, our internal Startup OS, where keeps the threads of how we run the company. It reads recent meeting transcripts, pulls candidate roadmap ideas, posts them back into the OS for us to react to. Our own code, which we’d generated with agentic engineering, had a key structure baked in. The key expired. The OS started rejecting the agent’s writes. The agent got stuck in a retry loop. The retry loop wrote logs. The logs filled to two gigabytes. The host the agent was running on stopped functioning. Other things on the same host got pulled down with it.

None of this was an AI model problem. None of it was an agent design problem. It was a chain of small operational things, the kind that sits between people and code and credentials.

Same thing, at home

A separate example, more domestic.

We have a household agent at home, Rosie, in our family WhatsApp (Rosie and our other family agents have a whole podcast episode. She hasn’t heard it). My wife, our kids and I use her to track who’s doing what around the house. She works. The kids have started talking to her like she’s part of the household. A few weeks ago, Anthropic had an outage. For about an hour, Rosie kept replying, but with strange model error messages instead of useful answers. The kids didn’t read it as “Rosie is down.” They read it as “Rosie is being weird.” A magical agent interaction doesn’t degrade gracefully in a child’s mental model. It just feels broken.

A few days after that, Rosie had drifted slightly in how she handles repeated tasks. Nothing dramatic. She just made more mistakes than she used to. We hadn’t changed anything. The AI model behind her had moved.

A third one, smaller.

We use a database that’s part of our internal stack. Recently a security issue was disclosed in it. We caught it because we have a dedicated channel for that sort of thing (part of our ISO and SOC2 certification). One of our agents quietly uses that database in the background. If we hadn’t known about that dependency, we’d have had a security issue running in production every night without anyone noticing.

Three different agents, three different modes of failure. None of them dramatic. None of them about the AI model itself.

The AI safety angle

There’s a related dimension to this, specifically when you care about what data goes where.

At Aimable we work with organisations that have sensitive data on the line. Our default is to use as much local AI capacity as possible. Smaller, open AI models like Qwen run inside your own environment and do the bounded tasks well: classification, routing (”who is this message for?”, “what is this conversation about?”). They struggle with the planning-shaped work, so we route those steps to a frontier model. The trick is making sure no sensitive data ever travels to that frontier step.

That split is good for safety. It’s also one more thing to maintain. Local AI models need to be kept current. New versions come out, older ones get worse relative to what’s available. So now you’re not just monitoring agents and credentials, you’re also keeping a local model fleet up to date. Another piece of agent operations no one puts on the cover slide.

Where the value actually lives

What I keep coming back to is that the setup is becoming the easy part. Anyone who can prompt an agent into a useful shape can stand one up in an afternoon. The work that actually generates value, and protects the trust your team builds in the agent, lives in the weeks afterward:

• Keys expiring on services the agent talks to.

• Frontier AI models being upgraded under you, with subtle behaviour changes.

• Local AI models that need to stay current.

• Dependencies you forgot the agent had.

• Log files filling disks because something somewhere is retrying.

• Drift you only notice because the people using the agent stop trusting it.

None of these are glamorous problems. None of them have a “build an agent in five minutes” demo attached. They are also the difference between an agent that creates leverage for a team and an agent that quietly poisons their willingness to try the next one.

Where I’m landing

Where I’m landing, for now: the value of an agent is not in standing it up. It’s in keeping it standing, in a way the people using it never have to think about.

That has implications I’m still working through. For Aimable, the platform our customers run their safe AI on, it sharpens a hypothesis I already had: the platform is the place where this maintenance work lives. Keys, policies, observability, drift detection, AI model updates, the local-versus-frontier split, dependency awareness across agents and people on the same gateway. Not features bolted on, more like the reason the platform exists.

For our household: I’m building cleaner failure modes into Rosie, so the kids see “Rosie is sleeping” rather than a model error.

For Pim’s missing meeting note: we now alert ourselves when the agent stops writing, instead of waiting for a person to notice (sorry for the confusion, Pim!).

I don’t have a clean conclusion. The gap between how easy the first day of an agent feels and how hard the second month is, is something I expect a lot of people are about to learn the same way I did. If you’re running agents at home or at work and seeing the same drift, I’d like to hear how you’re handling it.

It’s where we show what we’re building before it lands in the core product. Build in the open. Every card has its own page with an animated, conceptual demo, so you can see how the thing works instead of reading about it.

What’s in the Lab today. Some of these are already running in real-world scenarios with our Design Partners, others are still in build:

· Aimee. A hosted agent that runs shifts inside your Space. Same Collections, same guardrails, same audit trail as your team. Audit prep, regulatory scans, overnight briefings.

· Meetings. Notes grounded in every line. Each decision and action links back to the exact transcript line it came from. If a claim has no citation, it doesn’t ship.

· Skills. A packaged recipe: prompt, tools, policies, output schema. People and agents call it the same way. One trail, one Space.

· Office Add-ins. Aimable inside Word, Excel, and PowerPoint. Your Collections, your policies, PII pseudonymised on the round-trip to the model.

· Canvas. A document pinned inside the Workbench chat. Highlight a section, ask for a change, only that passage rewrites in place. Same Space, same audit trail.

Running thread across all five: yours, not theirs. These surfaces plug into the Space and policies your team already has, instead of spinning up a parallel vendor world.

Lab features graduate into the main line-up once they’ve proven themselves with our Design Partners. Have a look: aimable.ai/en/lab

This is the pattern now. Specialised modes for specialised work. A model that speaks your industry’s language.

Good. Specialisation beats generic.

Here is the catch

The work you do is probably confidential. Patient data. Molecule pipelines. Client files under NDA. Contracts that make you personally liable if something leaks.

A specialised cloud model does not solve that. It is still a vendor, still a third party, still a black box when the auditor asks what went where.

The model is never the real problem

What happens before and after the model is.

Before: is sensitive data filtered out before it ever reaches OpenAI, or Anthropic, or whoever ships the next specialised mode next quarter?

After: can you prove what was asked, what was answered, which sources grounded it, and who had access?

That layer does not live inside GPT-Rosalind. It lives in the platform everything goes through.

That is what we build at Aimable

Any model, including the specialised ones. On your terms. With your rules. In a logbook your board can sign off on.

Specialised AI is great news. Ungoverned specialised AI is the same trust problem in a nicer suit.

Most companies I talk to have a list of things they cannot do with AI. The support tickets with customer names in them. The contracts. The mailbox full of complaints with IBANs and phone numbers. Exactly the work where AI would actually help.

And then the question comes up: what do we actually have to arrange to use AI on this kind of material without the legal team losing sleep?

Pavle Bojkovski and Abacus Legal just made that question much easier to answer. They built an annotated reading of the EU AI Act. Full text, every article cross-linked to the recital that explains it, drafting history, amendment tracking. Free.

https://bojkovski-cpu.github.io/ai-act-annotated/

Reading it, the shape of the answer becomes obvious. A few examples:

a) Article 4, AI literacy. In force since February. Your people have to know what they are doing with AI, and you have to be able to show that they do.

b) Article 50, transparency. When a generative system interacts with customers or staff, you keep a record of what goes in and what comes out.

c) Article 10, data governance. For high-risk systems, the data has to be traceable and clean. For everyone else, GDPR is still in the room the moment an IBAN lands in a prompt.

None of this is a reason not to use AI. It is a list of things to have in place so you can finally use AI on the work that matters most.

That is what we build Aimable for. A working environment that filters sensitive data before it reaches any model, keeps a full logbook of every interaction, and lets your team actually use AI on the tickets, the contracts, the mailboxes. Without the phone-under-the-desk workaround.

Thanks Pavle for making the regulation readable.

What the investigation found

Before firing Altman in 2023, chief scientist Ilya Sutskever compiled 70 pages of Slack messages and HR documents alleging a “consistent pattern of lying.” He told the board: “I don’t think Sam is the guy who should have his finger on the button.”

OpenAI promised its superalignment team 20% of compute for safety research. The actual number? Between 1 and 2%. On the oldest hardware. The team was dissolved without completing its mission.

The investigation after Altman’s reinstatement? No written report was ever produced. Just oral briefings to two board members Altman helped select.

And now OpenAI is building data centres in the UAE seven times larger than Central Park, funded by autocracies, while lobbying against every meaningful regulation.

This is not just about one CEO

This is about what happens when safety depends on promises instead of structure.

Every charter got rewritten. Every safety team got dissolved. Every commitment got renegotiated when the money got big enough. Anthropic weakened its responsible scaling policy. Google dropped restrictions to win military contracts. The pattern is industry-wide.

Why this matters for your organisation

If you’re using AI in your organisation today, you’re trusting someone’s promise that your data is handled responsibly. That safety research is properly funded. That the rules won’t change when the next funding round closes.

The New Yorker investigation shows exactly how much those promises are worth. Not because these are bad people. Because the incentive structure makes it almost impossible to keep them.

The question was never “which AI company can we trust?”

The question is: how do you build a system where trust doesn’t depend on one company keeping its word?

This is exactly why we built Aimable around Trusted Intelligence. Not trust in a vendor’s promises. Not trust in a CEO’s good intentions. Structural trust.

Your data is protected before it ever reaches any model. Your answers are grounded in your own verified sources. Your rules are enforced automatically, not by policy documents that can be quietly rewritten.

The model provider can change their charter, fire their safety team, or sell out to the highest bidder. Your organisation stays protected. Because the trust lives in the architecture, not in someone’s promise.

Read the full New Yorker investigation

If you were using OpenClaw through your $20/month Claude Pro plan, that’s no longer covered. You can still use it via the API, but depending on usage, your bill could jump from $20 to $500 a month.

This matters beyond OpenClaw. The way AI is priced determines who controls your AI strategy, what it costs at scale, and how vulnerable you are to changes you didn’t see coming.

The gym membership model

AI subscriptions work like gym memberships. Most people pay monthly and barely use it. A few power users push the limits every day. The light users subsidise the heavy ones. That’s the business model.

Anthropic charges $20/month for Claude Pro. Microsoft charges $30/user/month for Copilot (reportedly increasing to $60). OpenAI charges $20 for ChatGPT Plus and $200 for Pro. These are flat rates regardless of how much you actually use.

On top of that, Anthropic gives you better rates when you stay inside their ecosystem: Claude Desktop, Claude Web, Claude Code, Claude Cowork. So you’re subsidised twice: once by low-usage subscribers, and once by Anthropic itself, who wants you using their apps instead of someone else’s.

OpenClaw broke that model. It’s an agent framework that runs hundreds of API calls per task. This kind of usage was already against Anthropic’s terms of service since February 2026, but enforcement was loose until now. Boris Cherny, Head of Claude Code, announced the change on X, describing capacity as “a resource we manage thoughtfully.” Anthropic gave about two weeks’ notice and offered a one-time credit equal to each user’s monthly subscription price (redeemable by April 17), up to 30% off pre-purchased Extra Usage bundles, and a full refund option. They pointed people toward Claude Cowork as an alternative. But the underlying message was clear: if your usage doesn’t fit the subscription economics, the terms will change.

The per-seat problem

For individuals, subscriptions are simple. For organisations, it gets more complicated.

Larger organisations typically negotiate enterprise agreements: Claude for Enterprise, ChatGPT Enterprise, Microsoft 365 Copilot. These come with volume discounts, SSO, admin controls, and negotiated rates. But they’re still per-seat. You’re still paying for everyone, whether they use AI ten hours a day or ten minutes a week. And you’re committing to one provider’s ecosystem for the duration of the contract.

In most organisations today, maybe 10 percent use AI intensively, another 20 percent use it occasionally, and the rest are just getting started. But that's changing fast. The whole point of rolling out AI is to get everyone using it. And the moment adoption picks up, flat-rate per-seat pricing punishes you for succeeding.

And you’re locked in. If Anthropic has the best model today but Google or OpenAI leapfrogs them next quarter, you’re still committed. Enterprise agreements typically run 12 months or longer.

What pay-per-token actually means

The alternative is API pricing: you pay per token. A token is roughly a word, though not exactly. It’s the smallest unit an AI model processes. Short common words like “the” or “is” are one token. Longer or less common words get split into pieces: “organisation” might be two tokens, “pseudonymisation” might be four. A typical page of English text is around 500 tokens. Not a perfect measure, but close enough for cost estimates.

You pay separately for what goes in (your prompt) and what comes out (the AI’s response). Output tokens always cost more because generating new text requires more compute than reading existing text.

Here’s what the major providers charge for a selection of their models, per million tokens (pricing verified April 4, 2026). There are many more variants available, but these cover the flagship and budget options from each provider:

A few things jump out. First, the price range is enormous. The cheapest models cost literally 100x less than the most expensive ones. This matters because most questions don’t need the most powerful model. Asking “summarise this email” doesn’t require the same firepower as “analyse this contract for legal risk.” Second, older models can be more expensive than newer ones. Anthropic’s Opus 4.1 costs $15/$75 per million tokens. The newer Opus 4.6 costs $5/$25. Three times cheaper for a better model. Third, there are discounts layered on top. Prompt caching gives you a 90% discount on cached tokens. Batch processing halves your bill. These matter at scale. Verify these rates yourself at platform.claude.com/docs/en/about-claude/pricing, openai.com/api/pricing, and ai.google.dev/pricing.

The hidden complexity

Beyond basic token pricing, there are additional costs that catch people off guard. Extended thinking (where the model reasons step-by-step before responding) generates tokens billed at output rates. For agentic workloads, this is where costs really explode: the model “thinks” extensively before each action, and you pay full output pricing for all of it. OpenAI charges 2x input rates beyond 272K tokens; Anthropic’s current models include the full 1M context window at standard pricing. If you require data to stay within a specific geographic region, most providers add a 10% surcharge. Some providers charge extra for specific features (Anthropic charges $0.01 per web search). Tool use adds extra tokens to every request. For an agent like OpenClaw that chains dozens of steps, reads documents, calls tools, and triggers extended thinking on each step, these costs compound quickly. That’s why Anthropic’s $20 subscription couldn’t sustain it. Beyond cost, third-party agent frameworks also raise security questions: OpenClaw had several critical vulnerabilities disclosed in early 2026, including a remote code execution flaw that exposed over 40,000 instances.

Why this is actually an opportunity

Here’s the part most people miss: per-token pricing, done right, can save organisations serious money compared to per-seat subscriptions.

Here’s a rough calculation. 50 people, averaging 30 AI interactions per day, 22 working days per month. Assume each interaction uses about 1,000 input tokens and 500 output tokens (a short question and a paragraph-length answer). That’s 33 million input tokens and 16.5 million output tokens per month. On Claude Opus 4.6 ($5/$25), that comes to about $580/month for all 50 people. For comparison: 50 seats of Microsoft Copilot at $30/user is $1,500/month today, or $3,000/month at the reported $60 rate. But most interactions don’t need the flagship model. If you route 70% to Haiku ($1/$5), 25% to Sonnet ($3/$15), and only 5% to Opus ($5/$25), the total drops to under $200/month. The exact number depends on your usage patterns, but the contrast is clear: under $200 with smart routing versus $1,500+ in per-seat licensing. And you’re not locked into one provider.

The bigger picture

This week’s OpenClaw decision is a small example of a larger pattern. AI providers are figuring out their business models in real time. While Anthropic was restricting third-party subscription access, OpenAI was doing the opposite, offering free ChatGPT Pro to open-source maintainers and explicitly naming OpenClaw as eligible. Different providers, different strategies, shifting in real time. What’s included today might not be tomorrow. The organisations that navigate this well are the ones that don’t tie their AI strategy to one provider’s pricing page. They separate the intelligence (the models) from the infrastructure (the platform that manages access, routing, cost, and rules).

This is exactly why we built Aimable. We use Anthropic’s models ourselves and think Claude is excellent. This isn’t about picking sides. It’s about architecture. Any organisation that routes all AI through a single provider’s subscription is exposed to exactly this kind of shift. A platform layer that sits between your teams and the models, handling routing, access, and cost management, gives you the flexibility to adapt when pricing changes. That’s the approach we’ve taken, and we think it’s worth considering regardless of which platform you choose.

The panic in the market is real. Software stocks down 30% since January. But the conclusion that AI kills all software is lazy thinking. What AI actually does is expose which software was worth paying for and which was just expensive enough to tolerate.

I see three categories emerging.

Infrastructure stays. And grows.

Nobody is going to vibe-code a database. Or a vector store. Or an authentication layer. Companies like Weaviate and Supabase are in the best position they’ve ever been in. The more people build, the more infrastructure they need. Every new AI project, every agent, every internal tool someone spins up in an afternoon needs somewhere to store data, somewhere to run, somewhere to authenticate. Infrastructure doesn’t get disrupted by more building. It benefits from it.

Simple tools get repriced.

There’s a whole category of SaaS that charges 50 euros per month for something that isn’t particularly complex. A form builder. A scheduling tool. A basic dashboard. If the price is low enough, nobody bothers replacing it. But if you’re charging serious money for something relatively simple, your customers now have an alternative. They can build it themselves in a weekend. The price has to match the complexity. A lot of SaaS is about to discover their pricing assumed a world where building was hard.

Complex, critical software gets stronger.

This is the category where trust matters. Where uptime matters. Where certifications matter. Where you need to prove to an auditor that everything works as promised. Nobody is going to vibe-code their compliance platform. Nobody is going to let an intern build the system that handles their client data. The more noise there is in the market, the more people gravitate toward software they can trust. Brand, process depth, and real certifications become the moat.

The software industry isn’t shrinking. It’s splitting. Infrastructure grows because everyone is building more. Simple tools get cheaper because building got easier. And complex, trusted software becomes more valuable because in a world where anyone can ship an app, the question shifts from “can you build it” to “should I trust it.”

If you’re building software right now, ask yourself: which category are you in?

What is it?

Google just shipped WebMCP as a browser API in Chrome 146. Microsoft co-authored the W3C spec. It’s worth paying attention to.

Read the Chrome developer blog post →

How does it work technically?

Today, AI agents interact with websites the hard way. They take screenshots, run them through vision models, and guess where to click. It’s slow, expensive, and breaks the moment you change your UI.

Why does it matter?

WebMCP replaces that. A website registers tools in its frontend JavaScript using navigator.modelContext.registerTool(). The browser exposes those tools to AI agents running on the user’s desktop. The agent makes structured calls instead of blind clicks.

What should you think about before implementing?

A travel site lets agents search and book flights. An e-commerce site lets agents find products and complete checkout. A support portal lets agents file detailed tickets. All within the user’s existing authenticated browser session.

The bigger question: what about agents without a browser?

The website owner decides what to expose. They write the tool definitions, the parameter schemas, the descriptions. Nothing happens automatically. It’s an active choice, tool by tool.

Where Aimable fits

WebMCP lives entirely client-side. The user visits your website in Chrome. Your JavaScript registers tools with the browser. An AI agent (like Claude Desktop) connects to that Chrome instance and sees the available tools. When the agent calls a tool, it executes in the browser tab where the user is already logged in.

Your webserver doesn’t know the difference. It receives normal authenticated requests from the browser session, whether those were triggered by a human clicking or an agent calling a tool.

This is different from backend MCP servers or REST APIs. Those handle service-to-service communication. WebMCP makes the frontend agent-callable, using the session and state that already exist in the browser.

Three reasons.

First, efficiency. Early benchmarks show 89% fewer tokens used compared to screenshot-based approaches. Tasks that took 30-60 seconds of screen-scraping complete in under 5 seconds.

Second, reliability. Screen-scraping breaks when a UI changes. Structured tool calls don’t. You define the contract, the agent calls it.

Third, distribution. If your site is agent-ready and your competitor’s isn’t, every user working through an AI agent will gravitate to you. That’s a real advantage, and it’s going to matter fast.

WebMCP is well-designed. But a few things are worth considering.

You’re defining tools that third-party agents will call. Scope them tightly. Start minimal. Think through what happens when an agent sends unexpected parameter combinations or calls tools in sequences you didn’t anticipate.

The agent runs in the user’s session with their full privileges. In regulated industries, that means understanding what a third-party agent can do on your site before your compliance team asks the question.

And support: when an agent uses your site incorrectly, the user will contact you. Having an agent-interaction section in your docs and training your support team for this new category of issues is worth doing early.

This is where it gets interesting for us.

WebMCP covers one scenario well: a human is present, browser is open, agent assists in real-time. That’s valuable.

But the direction everything is moving is autonomous agents. Background workflows. Overnight batch processing. Agents chaining actions across services without anyone watching. Those agents don’t run inside Chrome. They’re headless. They call backend APIs and MCP servers directly.

For that world, WebMCP isn’t the answer. And that’s where the governance question becomes most relevant.

The Aimable team spent a day in the forest at my cofounder Arjé’s place, splitting wood and enjoying the quiet. Being out there gave me a bit more perspective on the scale of what we are building in the AI industry and the energy it consumes. It is easy to forget that every query, every workflow, every model call has a real footprint somewhere in the world.

That is why this new Stanford study on local model efficiency caught my attention so strongly. The data shows how fast things are changing. Local models can now handle close to 89 percent of single-turn tasks, and intelligence per watt has improved more than fivefold in just two years. With smart routing, most queries can be answered locally while cutting energy use by 60 to 80 percent.

Read the Stanford study on local model efficiency →

I find this encouraging. It is a reminder that responsible AI adoption is not only about safety and control but also about making real progress on efficiency. When we started Aimable, the focus was on helping organizations steer and govern AI inside their walls. Seeing energy savings emerge as a natural consequence of better orchestration is a welcome bonus.

The photo I am adding has nothing to do with AI on the surface, but the contrast makes the point for me. If we want powerful systems, we also need to build them in a way that respects the world that powers them.