Choose the Platform. Keep Your Options.

I am not particularly worried about picking the wrong AI model this week. I am more worried about building a way of working that cannot cope when the model, the product or the company behind it changes.

That is becoming a bigger question as I work through what an enterprise AI operating model should look like. It is easy to get excited about what a platform can do now. The harder question is what happens after people start relying on it.

What if the price changes enough to make the work uneconomic? What if a capability disappears, access is restricted or the provider is no longer there? How much of the business can carry on, and how much have we quietly handed over with the subscription?

I do not want to sit out useful technology while waiting for the market to settle. I also do not want to build years of working knowledge into something I cannot sensibly leave.

We have seen technology ecosystems come and go before. I am less interested in predicting the winning format than making sure the work is not stranded when the market moves.

Same projectDifferent platformReview before resuming

AI-generated conceptual illustration · fictional work records

This is not a bet on who goes broke

I expect the supplier landscape to change. That is my planning assumption, not a prediction that a particular provider will fail. Competition could narrow, ownership could change and products could take a different direction. An outage or a contract decision could cause a problem long before a company disappears.

The practical question is the same: what have we made dependent on something we do not control?

This matters more when AI moves beyond answering questions. If it helps prepare proposals, coordinate work, investigate incidents or maintain software, losing access is no longer just an inconvenience at the chat window. It can interrupt an activity the team has started to organise itself around.

That is why I see adaptability as part of the operating model, not a procurement preference we mention once and forget.

Choose a starting point, not a permanent dependency

There are good reasons to use an integrated platform. Familiar tools, existing identity, support and a coherent user experience can make adoption easier. Building every component ourselves would introduce its own costs and risks.

The current announcements show different approaches. Microsoft describes Autopilot as a persistent agent with its own identity, memory and workspace inside the tenant; its September announcement sets out a private-preview rollout. OpenClaw Enterprise describes a self-hosted approach with replaceable models, harnesses and sandboxes, while explicitly positioning the pre-1.0 release for internal pilots. Neither announcement is evidence that a particular business can migrate its work without disruption. Microsoft announcement · OpenClaw announcement

I would rather choose a sensible starting point and learn from real work than spend a year designing a perfect platform-neutral abstraction.

For me, platform independence means separating what the work requires from the technology we happen to use to do it. The purpose, evidence, output expectations and human decision points should remain understandable when we change the model or the harness—the software that connects the model to its tools and work. Some integrations will still need adapting.

I do not need every model to think or write identically. I need the work to remain understandable, the important controls to remain effective, and the result to meet the same standard. That should give us room to use better capabilities, not force everything down to the lowest common denominator.

But I would ask a few awkward questions before the convenient starting point becomes the only way the organisation knows how to operate. Where is the enduring knowledge? Can we export it in a useful form? Which parts of the workflow are ours, and which only exist inside the product? What would we lose if we had to move?

Using a supplier is not the problem. Discovering too late that the supplier holds the only usable version of how your business works is.

Keep the work, not just the conversation

The important asset is not a collection of clever prompts. It is the working knowledge around the task: what we are trying to achieve, the information we trust, the steps that matter, the decisions already made and what a useful result looks like.

For a digital worker, that also includes its role, the person responsible for it, what it may access, what it may change and when it must hand back to a human.

I want those things in records the business controls, with versions and a usable history. A folder and a readable framework can be a good starting point for some work. Other work belongs in a business application, a controlled repository or a service-management system. The point is not that everything should become a Markdown file. It is that the conversation should not be the only place the work makes sense.

Imagine moving a proposal-drafting task to another platform. The next system should receive the current brief, approved source material, open questions, output structure and review requirements. It should not need to reconstruct the engagement from six months of chat.

Brief and evidenceDecisions madeCurrent draftNext action

Solid lines: execution route. Dashed lines: access to shared work records. AI-generated conceptual illustration · fictional work records.

The same thinking applies to handing work from one session to another. What is complete? What is still unresolved? Which decisions have been made, and what needs my approval? I want the next session to start from a useful record of the work, not from whatever I can remember to paste into a new chat window.

That does not make the new system equally capable. It gives us something coherent to test it against.

Changing the model is only one part of the move

A model is the engine. The product around it may also hold memory, permissions, schedules, tool connections and work in progress. Being able to select a different engine does not tell us whether the rest can move.

I would want to know whether a replacement can pick up a task, explain its state, request the right approval, return usable files and stop when told. Those are working requirements, not just API compatibility questions.

There is another awkward detail: what has already happened? If the first agent sent a message or updated a business record before losing access, starting the task again could repeat the action. A useful handover needs a record of completed actions and unresolved work, not just the original instruction.

The permissions need checking too. A replacement should not inherit authority simply because the old worker had it. We need to test the new combination of model, tools and controls, and decide what it is allowed to do.

Local is an option to prepare, not a magic escape hatch

This is where local models become strategically interesting to me. Not because they will always be cheaper, or because they can replace every frontier capability, but because they may let us keep selected work moving without the same external dependency.

Local inference is a real option: Ollama, for example, documents a local-only mode that disables its cloud features. That tells us something about where the model can run. It does not prove that a whole business workflow will operate offline. Ollama documentation

A locally running model may still need documents in a cloud service, an external identity provider or a tool that requires an internet connection. Two alternative models can also depend on the same infrastructure. Different names on a selection list do not necessarily mean independent ways to keep working.

I would start by deciding what must continue, what can slow down and what should stop safely. Perhaps a local setup can search an approved document set, prepare a first draft and organise a review pack, while more demanding analysis waits. Perhaps the right fallback is a person following a documented process without AI.

The fallback does not have to be as impressive as the normal service. It has to be useful, controlled and understood by the people who will rely on it.

That means preparing the model files and checking their licence, the hardware, the necessary data, the access controls and the people who will operate it. It also means measuring quality, capacity and human review effort. A model that works for one person in a lab has not yet demonstrated that it can support a team under pressure.

Give the fallback a real job

This is also becoming a business continuity and disaster recovery question. We know how to discuss backup systems and recovery plans. But if an agent helps run part of the business, what are we actually recovering? The infrastructure, or the ability to carry on with the work? Another server is not much help if the instructions, decisions and unfinished tasks are trapped somewhere we can no longer access.

I also see a supply-chain risk here. We are not only relying on the provider we buy from, but on the models, infrastructure and services it relies on. If the primary platform and the fallback share a critical dependency, both could be affected by the same disruption. I would want to understand that chain before treating a different provider as a recovery plan.

Primary platformFallback platformShared dependency

AI-generated conceptual illustration · fictional work records

Continuity means deciding what can carry on during disruption, perhaps more slowly or with more human involvement. Recovery also means restoring the service and reconciling what happened while it was unavailable. Both need to be about the business activity, not simply whether the agent starts again.

One practical example is a framework I use to review and respond to requests for information (RFIs) and requests for proposals (RFPs). I have been using it across Claude Code, OpenAI's Codex and OpenClaw, with a mix of models depending on the task an agent is completing.

What I want to carry between those environments is the method: the questions we need to work through, the information required, the shape of a useful response and the points where I need to make a decision. The conversation can vary. The engagement should not have to start again because I have opened a different tool.

The next question is how that holds up when something goes wrong. Using several tools in normal conditions is not the same as losing access to one halfway through an engagement. I still need to know whether another setup can continue the work to the required standard.

I would choose one bounded response task, use synthetic or explicitly cleared source material, and practise completing it without the primary provider in a controlled environment. Can another supported setup pick up the brief, current draft, decisions and open questions? Can it produce a response that passes the same review? If the required records are unavailable or too old, it should say so rather than inventing a reassuring answer.

I would want the exercise to answer four things:

• Can we resume the work? The brief, records and completed actions are available and make sense outside the original product.
• Is the result good enough for this purpose? We check accuracy, missing information and review effort, not just whether a file appeared.
• Do the boundaries still hold? The fallback uses permitted information and actions, records what happened and escalates when it should.
• Can we sustain and recover it? We know the capacity, cost, owner, how long recovery can take, how much recent work we can afford to lose and how to reconcile the work when normal service returns.

That exercise will probably expose compromises. Good. I would rather find them during a planned test than while people are waiting for something important.

For less critical work, a documented manual route may be enough. For work the business cannot afford to lose, keeping an alternative ready may justify more investment. We should spend in proportion to the consequence, not build two of everything because resilience sounds good in a strategy document.

Keep moving without starting again

For an enterprise, this is an architecture decision, not just a model-selection decision. Highly available infrastructure still matters. But availability alone does not give us the freedom to change providers.

The process, knowledge, decisions and unfinished work need to remain usable when we change the model, the agent software or where it runs. The hosting choice might be AWS, Azure, Google Cloud or our own infrastructure. That is a different choice from which model or harness does the work, and moving one layer does not automatically make the others portable.

Not everything will move unchanged. Some connections will need rebuilding, some capabilities may not be available, and the replacement will need testing. The point is to make that a manageable change, not a reconstruction of how the business works.

This connects directly to the Beyond Agents work. Clear roles, bounded authority, evidence and human ownership need to survive a technology change too. Confidence in an alternative model's answer is not permission for it to act. We still need evidence that the replacement can do the required work within the required boundaries.

I want to use the best tools available for the work in front of me. I also want the freedom to change them without losing everything we have learned about doing that work well. That matters when a provider disappears, but also when something more useful comes along.

So yes, choose a platform. Get something useful working. Learn where it helps and where it does not.

Just make sure changing the technology tomorrow does not mean starting the business process again.