We used external AI and platform capabilities for several operational functions. In one workflow, ChatGPT Memory was part of our persistent storage architecture. At some point, new information could no longer be stored persistently from that workflow.
The cause remained unclear. OpenAI Support was also unable to resolve the issue in a timely manner. That changed the decision we were making.
From: How do we get this working again?
to: Which parts of our operation do we actually want to depend on an external capability whose state we cannot sufficiently control?
What began as a planned technical workaround became a broader architectural change.
Persistent state was moved into a more controllable external persistence layer.
The model we used was treated more explicitly as a replaceable execution layer.
Platforms were treated as distribution surfaces, not as the foundation of the underlying operating and publishing architecture.
This did not make us independent of external infrastructure. But it did make us less dependent on one specific capability, model, or platform.
That changes the classic buy-vs.-build question. For small organizations in particular, the real choice is often not:
Buy it or build everything yourself?
Time, capital, or technical resources are usually too limited for that.
The more important question may be:
What does the organization need to control itself, and what can remain external if it is replaceable?
The organization does not need to own the model. It does not need to own the platform. Nor does it need to operate the entire infrastructure itself. But replacing one of them should, where possible, not require rebuilding the operation around it.
Buy vs. build therefore answers only part of the architectural decision:
Where does the capability come from?
A second question follows:
How deeply should dependence on that capability be embedded in the organization’s architecture?
Replaceability is not a third sourcing category alongside buy and build. It changes the conditions under which buy remains operationally viable.
The relevant addition is therefore:
Buy, but design for replaceability.
Or, more concretely:
If you buy it, ask what happens when you have to replace it.
