In Today’s Issue:

🔌 What determines whether a company can keep operating if its AI provider becomes unavailable

🧭 Three dimensions of AI sovereignty and the limits of infrastructure independence

🔄 How to design for model switching and where a backup can still fail

🕸️ Where knowledge graphs fit and how to avoid database lock-in

🧪 How to test a provider switch with real workflow data

📅 What a team can realistically do in its first 30 days

🔍 Follow-ups: what really happened at Anthropic in June and the evidence behind GraphRAG

Dear Readers,

In June, a lot of companies learned how quickly access to a frontier model can disappear. After a US export control directive on June 12, Anthropic switched off Fable 5 and Mythos 5 for all of its customers, and for almost three weeks teams that had built on those models had to work without them. The question is no longer whether a provider can go away, but whether your workflows keep running when it does.

Philip Rathle, CTO of graph database company Neo4j, has spent this year discussing exactly that with executives and government officials around the world. His answer is refreshingly practical: treat a model switch like a disaster recovery test. Pick one production workflow, run it on real inputs and measure what changes. And keep your company's knowledge in a layer you control, so the model becomes the easiest part of the stack to replace. Neo4j sells technology for that context layer, which is worth keeping in mind, but the drill he describes works whatever database you use.

We sent Rathle seven questions on AI sovereignty, model routing, database lock-in and what a team can get done in its first 30 days, followed by a round of follow-ups on the evidence behind his claims.

All the best,

Kim Isenberg

Neo4j builds graph database technology, including the knowledge graphs Rathle recommends as a context layer. In these answers he explains how companies can prepare for losing access to an AI model, from routing workloads across several models to testing a switch with real data.

The interview was conducted in writing. Questions 8 to 11 are follow-ups we sent after the first round of answers; the editor's notes are ours.

Q1. If a company lost access to its main AI provider tomorrow, what would determine whether it could keep operating?

This is a question I’m hearing a lot from executives outside of the U.S. In June, the U.S. government ordered Anthropic to suspend access to Fable 5 and Mythos 5. That it happened matters much more to them than the “why.” For leaders, it begs the question: how can I build resilience into my systems so that my operations aren’t forced to take a pause the next time something like this happens, regardless of the reason.

Building for resilience is not new: every company is accustomed to building various forms of resilience into their systems. Model vendor independence is simply a new form of this. Many companies (including ours) are already building model routers for economic reasons. These route different types of work to different models and model tiers depending on the workload. Assuming one is already doing this, then accounting for the possibility that one of these models or providers might suddenly become unavailable starts with:

The other facet of this isn’t just model horsepower. It’s how much of a company’s knowledge has been trained into a provider’s model and memory. The more of one’s business knowledge and logic becomes entwined with the model provider, the more difficult it becomes to swap. An important part of the resilience answer therefore becomes: how can I own my own enterprise knowledge and context. If I do that, then model reasoning remains commoditized, leaving open the possibility of swapping. And one keeps one’s crown jewels in house.

Editor’s note: The June 12 directive barred foreign nationals from accessing Fable 5 and Mythos 5. Because Anthropic could not verify nationality in real time, it disabled both models for all customers until the controls were lifted on June 30. Rathle explains what happened in the follow-ups below.

Q2. What should a company actually be able to do with its data and AI systems before you would describe it as sovereign?

Before I'd call a company sovereign, I'd want it to say yes to three things:

In reality, each of these ends up being somewhat of a sliding scale, as the world is still deeply interconnected and interdependent. One important thing to distinguish is sovereign buildout vs. sovereignty of one’s ongoing operation. Buildouts can’t ever be completely sovereign. Each country is going to depend on hardware and software components originating from a mixture of countries. Consider the Nvidia (U.S.) dependency on TSMC (Taiwan) for chip production, TSMC’s dependencies on ASML (Dutch) for lithography, ASML’s dependency on Carl Zeiss (Germany) for mirrors and optics – to name a few. To say nothing of operating systems, database management systems, model providers, and so on.

Once components are in place however, ensuring that one can continue using that infrastructure unimpeded and with minimal degradation becomes somewhat tractable. The two concrete things to which I would give the highest priority are the ones we talked about in the answer to the first question: model routers (with some open source models in the mix) and a context layer with rich context (i.e. inclusive of a knowledge graph, not just the map of systems) to insulate myself from dependency on the model provider for knowledge about my enterprise. I would also look to use standards-based technology wherever possible. This remains a reliable way to enable swapping of technologies and tech stacks.

Q3. Can you share a real example of an AI system built so that the model can be swapped?

I'll give you a non-obvious example of a company that built an AI system where models could easily be swapped. Uber operates in around 15,000 cities. They have an agent that drivers can use to determine what services they are eligible for. A driver gives their inputs: background check, car model, location, hours, experience. The rules graph works out which Uber offerings they're eligible for. This reasoning operation has regulatory and safety implications, and is therefore high stakes enough that there is zero room for hallucination. Being able to clearly and completely explain the reasoning is also a foundational requirement.

What they did was: instead of training the rules into a model, or writing them in code (which can get messy when rules are frequently changing), they capture the rules in a graph in Neo4j, and use the model to translate from the human language question into a query and then back to language. The takeaway isn’t that all reasoning should live outside one’s model. It’s that when your core IP lives outside the model (such as Uber does here in the graph), the model largely becomes a commodity you can replace. The companies that will have the easiest time switching are the ones that don’t overly rely on models to understand the complex nuances of one’s business.

Q4. Where can knowledge graphs make an AI system easier to move between providers, and how would you address the concern about database vendor dependence?

In a knowledge graph, context sits outside the model. That makes it accessible to any model you choose. More specifically, the knowledge graph contains your customers, products, suppliers, procedures and policies, how they all connect, where the data comes from (provenance), and who can see what.

Of course data sovereignty is not the only thing one gains from building up a knowledge graph. Other advantages include improvements in AI accuracy (GraphRAG significantly outperforms RAG in many cases) and token reduction (by being more surgical about what gets fed into the context window).

The next question is ensuring the knowledge graph itself isn’t a lock-in. Top questions to look for in a graph database provider are: do they offer form factors enabling their tech to run on premises, in any cloud or as a managed service, so that you can choose what you want now and change your mind later. The second is: is the technology standards based. In the graph space this primarily means supporting GQL, which is the first new ISO database language standard in the 40 years since ISO SQL became a standard. And are the APIs open.

Q5. When does using several models make operational and economic sense?

Normally when prototyping, you want to keep it simple and use one model, erring on the side of a more powerful one. This will help you assess whether the thing you’re trying to do is actually doable. Often it’s good practice to use a different model for evals.

Once you're past the pilot stage, then assuming you aren’t building something simple and low-stakes (where one model might be enough), you need to make refinements to meet your functional and nonfunctional requirements. The more high-stakes and complex the operation is, the more work needs to go into ensuring accuracy, explainability, independence/sovereignty, fact checking, as well as minimizing token costs. This is where multiple models often come in.

It’s also where multiple systems besides the model come in. The AI systems I see going into production are highly composite: each operation involves multiple model calls, often with more than one model / model provider, as well as clever use of other technologies and tools besides LLMs. A surprising example I’ve repeatedly seen is: once you have a knowledge graph built, not only can you feed rich context into a model to get better reasoning, you can also run reasoning operations in the graph. Finding the right supplier for an automobile component in a deeply-nested bill of materials (BOM), or an ultimate beneficial owner for an asset, or the right drug candidate to solve for a disease, can be computed in milliseconds as a CPU-based graph query in something like Neo4j, yielding an exact and fully-explainable result. Likewise, the strongest churn indicator for a telco might be how close you are to another customer who has churned. This is right in the sweet spot of graph algorithm operation (centrality), for which there are specialized technologies. Not every problem is best solved with an LLM.

Bottom line: you should always look to leverage multiple technologies and look to AI as a technology composition problem, not a model choice problem. The best AI engineers are the ones who approach problems with a toolbox, not just a hammer.

Q6. How would you test whether a company can genuinely switch providers?

Treat it like a disaster recovery test. Most companies test their backups. Almost none test whether they can swap their model. Pick one production workflow that matters and build a test set from real inputs/outputs/decision traces. That's where good evals and observability hygiene pay off.

I'd measure it the way you'd measure any system, against functional and non-functional requirements. I mentioned this above. Functional means: does it get the right answer? That covers accuracy against known/good answers, how many answers trace back to a source and whether the same question gets the same answer. Non-functional means all the "-ilities" around it: permission violations, latency, cost per task, how often a human has to step in, and how long the switch took.

“Good enough” means accuracy within a tolerance you agreed on in advance, zero regressions on security or permissions, and cost and speed within budget. Given the pace of change, I'd run the drill at least once every quarter for good measure (or when some external trigger warrants it), and of course automate it.

Q7. What are the steps required to switch model providers, in order, and what could a team realistically get done in the first 30 days?

If your goal is to be able to switch on the fly to enable continuous business operation in the event you or an external force decides to swap out a model, then you’ll want to carry out the following steps:

In 30 days, a team can rank its concerns and take stock of where its AI context lives, including which pieces depend on one provider. Then it can turn on decision tracing for one important workflow and move that workflow's retrieval into a layer it controls. Acting on it will take longer, but in 30 days you should be able to get a good baseline of where you're exposed and what it will take to close the gaps.

After the first round of answers, we asked Rathle for sources and clarifications. Here is what he sent back.

Q8. What exactly happened with Anthropic's models in June?

The Commerce Department’s June 12 directive barred foreign nationals from accessing Fable 5 and Mythos 5. Anthropic said the order took effect immediately and that it had no reliable way to verify users’ nationality in real time, so it disabled both models for everyone. The department lifted the controls on June 30, and Anthropic began restoring access on July 1. Anthropic’s statement is here.

My point about the reaction from the business community and the steps they are now taking still stands. The fact that the restrictions were lifted doesn’t change the lesson. For almost three weeks, companies that depended on those models had no access, including U.S. companies that were never the target of the order. What leaders took from it is that access to a frontier model can be cut off overnight for reasons outside their control.

Q9. Has Uber actually switched models or providers in that driver workflow?

I can’t point to a documented model or provider switch in this workflow. What I can say is why it would be a low-cost switch if Uber chose to make one. The reasoning happens in the graph, not in the model. Because the business logic sits outside the model, the model’s job is mostly translation, and translation is the easiest part of the stack to swap.

More broadly, here’s what we see across our customer base. Most teams start with one large model while prototyping. By the time they reach production, their pipeline uses several smaller models. Most also find their overall token spend goes down once GraphRAG is supplying more targeted context, mainly because agents need fewer steps to reach a good answer.

Q10. What evidence is there that GraphRAG outperforms conventional RAG and reduces token use?

We have both research studies and customer stories to substantiate this. We see a common pattern across our customers where graph technology is initially brought in to improve dependability. By the time the work is done, it turns out to have significantly reduced the need for tokens and hardware as a “side benefit.” One such example is Uber.

In a recent post, “Running a Software Factory Efficiently at Uber Scale,” Uber Distinguished Engineer Uday Kiran Medisetty outlines some of the key levers and methods they’ve developed. One of the key agentic optimization levers is graph-grounded context:

Accuracy: NICD at Newcastle University (2026). The research was conducted independently by the UK’s National Innovation Centre for Data and funded by Neo4j. Researchers ran 510 complex questions from MoNaCo, a peer-reviewed, Wikipedia-based benchmark designed to test reasoning across multiple documents and sources. They compared an agentic vector-only RAG system, an agentic system with both vector and graph tools, and a model with no retrieval at all. Compared with vector RAG, the knowledge graph approach improved truthfulness scores by about 80% and raised the share of questions answered from 29% to nearly 66%. Precision and recall both roughly doubled. Paper.

Structured enterprise data: data.world benchmark (2023). This study tested natural-language questions against an enterprise insurance database built on the OMG Property and Casualty Data Model, an industry-standard schema. It compared querying the SQL database directly with querying a knowledge graph representation of the same data. With GPT-4, accuracy rose from 16.7% on the SQL database to 54.2% with the knowledge graph. Paper.

A production deployment: LinkedIn customer service (2024). LinkedIn built a knowledge graph from historical support tickets and compared it with conventional text-chunk RAG. In offline tests, it improved retrieval accuracy by 77.6%. After about six months in production with LinkedIn’s customer service team, it had cut median per-issue resolution time by 28.6%. Paper (SIGIR 2024).

The common thread across these studies is that when the questions require connecting facts across many entities or documents, giving the model a graph of how those facts relate is better than handing it more text with a larger prompt.

Editor’s note: The NICD paper reports its accuracy gains alongside a modest increase in token use, and puts the share of questions answered at 28.1% for vector RAG and 65.3% with graph tools. The LinkedIn figure of 77.6% is measured in MRR, a ranking metric. Uber’s post does not say which graph technology powers its AI Context Graph.

Q11. Can you share documented examples of the millisecond graph queries you described?

The examples in my earlier answer (bill-of-materials lookups, ultimate beneficial ownership, drug-candidate search, churn proximity) describe common graph patterns, not specific customer case studies. Multi-hop queries that return in milliseconds are what most Neo4j customers do every day. Two documented examples:

This interview was conducted in writing. The original seven answers were received on November 2, 2026; the follow-up answers (Q8 to Q11) on November 5, 2026. Answers are lightly edited for typos and length, with emphasis added; the editor’s notes are ours.

Rathle proposes separating company knowledge from model execution and identifying which workloads genuinely need frontier models. A model router can direct workloads to different models; a backup still needs to meet the requirements of the particular workflow.

His most concrete recommendation is to run a provider-switch drill using real inputs, outputs and decision traces. Measure answer quality, source traceability, permissions, latency, cost, human intervention and the time needed to switch.

A company only knows whether its AI workflows survive the loss of a provider once it has actually tried. Rathle's provider-switch drill is the most useful takeaway here: pick a workflow that matters, agree on acceptable quality and cost in advance, and check accuracy, permissions, latency and switching time against real inputs.

The second lesson is architectural. The more business knowledge sits inside one model provider, the harder that provider is to leave. Keeping context in a layer you control turns the model into the part of the stack you can swap, provided that layer can run anywhere and supports open standards such as GQL.

June showed that frontier access can vanish overnight for reasons no customer controls. Thirty days are enough to map where you are exposed. Closing the gaps takes longer, which is the best argument for starting now.

Our thanks to Philip Rathle and the Neo4j team for the interview.

Philip Rathle is Chief Technology Officer of Neo4j, focused on vision, evangelism and executive relationships across the tech ecosystem. He was the company’s first product leader for more than a decade, growing Neo4j from a single database product into a portfolio that spans the graph database, data science and analytics, visualization, and tools and connectors.

Before that, he led product management at Embarcadero Technologies, overseeing ten database and developer products. Earlier in his career, he spent nearly a decade solving large-scale information processing problems for Fortune 500 companies at Tanning Technology and Accenture. He is based in Silicon Valley. Philip Rathle on LinkedIn.

Sources: