AI models and tools will keep changing. The harder question is whether the knowledge your company builds with them can survive the switch.
Your company should expect to replace the AI it uses today.
That is not a failure. It is what a healthy technology market looks like. Models improve. Prices fall. Better tools appear. A system that is right for you this year may not be the one you want three years from now.
The part you should not expect to replace is everything those systems learn about how your company works.
That distinction is easy to miss because most of the AI conversation is still about the model: which one is smartest, fastest or cheapest. But models are improving quickly. Company knowledge moves in the opposite direction. It becomes more valuable because it accumulates.
If we get the architecture wrong, companies may spend the next few years teaching a collection of AI tools how their business works, only to discover that the knowledge belongs more to the tools than to the company.
The thing that compounds
Most companies already have a data fragmentation problem.
Sales has the CRM. Finance has spreadsheets. Support has a ticketing system. Operations has the tools that made sense when each one was introduced. Somewhere, an important partner still sends a spreadsheet by email every month.
For a long time, people were what held those pieces together.
The account manager knew a customer was unhappy before the churn report showed it. Someone in operations remembered why an exception had been made for a supplier two years earlier. Finance knew which number in the spreadsheet could be trusted and which one always needed checking.
Some of that knowledge was written down. Much of it was not.
This is an old idea. Ikujiro Nonaka’s work on organisational knowledge distinguished between explicit knowledge that can be recorded and transferred, and tacit knowledge that is much harder to separate from the experience of the people who hold it.1
Companies have always lost some of that second kind when experienced people leave.
They have also spent a lot of human effort compensating for fragmented systems.
Someone copies numbers from four places into a spreadsheet every Monday. Larger companies hire data engineers to build pipelines between systems that were never designed to work together.
Different methods, same job: connect enough of the pieces to understand what is actually happening.
AI changes the shape of this problem.
Fragmentation gets smarter
Teams are now adopting software that does more than store their work. It also accumulates context from it.
Engineering uses an AI coding tool. Support uses an assistant across customer conversations and documentation. Marketing uses another system across campaigns, briefs and previous work.
Each decision can be perfectly sensible.
Engineering gets faster. Support answers questions sooner. Marketing gets more done.
The problem appears one level above the team.
Each system starts building its own picture of the company.
The support assistant knows why customers are complaining. The sales system knows which accounts have gone quiet. Another system knows what changed in the product.
Each picture can become useful on its own.
But the pictures do not necessarily connect.
We may be replacing fragmented data with fragmented intelligence.
And fragmented intelligence is harder to see.
Correct can still be wrong
Suppose you ask why an important customer is at risk.
Sales knows the relationship has gone quiet. Support knows the customer opened several serious tickets. Product knows a feature they depend on has been delayed. Finance knows their usage is falling.
An AI assistant with access to only one of those histories can still give you a convincing answer.
It may even be correct.
Just incomplete.
That is the more interesting failure mode.
A missing number in a dashboard is visible. A confident explanation based on part of the company’s knowledge is not.
As companies give AI access to more systems, the question is no longer only whether the model can reason correctly from the information in front of it.
It is whether it has the right information in front of it in the first place.
Once you see the problem this way, memory stops looking like a feature in a chat window.
It starts looking like infrastructure.
Who owns the memory?
The more useful an AI system becomes, the more context it accumulates about how a company works.
Customer names are the easy part.
The valuable context often lives in the relationships between things: which sources people trust, why a metric is calculated a certain way, which exception was made for a customer, what an internal term means, or which information is no longer current.
What happens to that context when you change tools?
Traditional software lock-in is mostly a migration problem. You export data, rebuild integrations and retrain people.
AI introduces another question: can you take the accumulated understanding with you?
That probably does not feel urgent six months after adopting a tool.
It could feel very different after five years.
There are already early signs that the industry is treating this as a real infrastructure problem. In June 2026, Google introduced the Open Knowledge Format, a vendor-neutral specification for representing metadata, context and curated knowledge in a portable form for humans and agents.2
A month later, version 0.2 added explicit signals for provenance, trust, freshness, lifecycle and attestation.3
Those details matter because portability alone is not enough.
Moving an old fact from one system to another does not make it true.
Models should be replaceable
This matters more because models will not stand still.
The best model for one task may not be the best model for another. The best model this year may not be the one you want next year. Agent frameworks are already being designed around that assumption rather than treating one model as permanent infrastructure. Google’s Agent Development Kit, for example, supports multi-agent systems, structured workflows and integration with different model implementations.4
That seems healthy.
The model should be replaceable.
Your company’s accumulated knowledge should be much harder to lose.
Models improve. Interfaces change. Agent frameworks change. Company context becomes more useful precisely because it has been built over time.
So perhaps the more durable question is not:
Which AI should we use?
It is:
Where should what our AI learns live?
If the answer is inside each individual application, companies may recreate the same fragmentation they spent years trying to fix in their data.
Only this time the fragmented thing is not rows in a database.
It is understanding.
Memory gets messy
There is a temptation to make memory sound like a database you bolt onto an agent.
It is not that simple.
Even at the framework level, short-lived conversational state and longer-term memory are different problems. ADK, for example, separates a session and its working state from longer-term memory that can be retrieved across sessions.5
That is the easy distinction.
The harder questions are about meaning.
Is “Acme” in one conversation the same company as “Acme Ltd” in the CRM?
If someone said a customer was planning to expand six months ago, when does that memory stop being useful?
If two systems disagree, which one wins?
Should an AI remember every correction a user makes?
Who is allowed to see a memory created from a private conversation?
When should something be forgotten?
These are not edge cases.
They are the actual problem.
What we’re betting on
This thinking has influenced how we have been building Dataseka.
We started with the less glamorous part: helping companies work across information that already lives in spreadsheets, databases and business systems without requiring all of the underlying data to be copied into a new application first.
Only then did we start building Seeka and the specialist agents behind it.
The reason was simple.
We did not want the useful context a company builds up to belong permanently to one agent or one model.
The agent will change.
The model will change.
The interface will change.
The company’s knowledge should survive all three.
We have not solved every part of this. Nobody has.
There are difficult engineering questions around permissions, identity, retrieval, provenance, stale information and what an AI system should remember in the first place.
But those questions become more important as the models improve, not less.
Most of the attention in AI still goes to what a model can do today.
The more durable question is what happens to everything your company teaches it tomorrow.
If you want the engineering side of that argument, I wrote a companion piece on the decisions behind Seeka’s multi-agent system: Nine Lessons from Running Seeka’s Multi-Agent System in Production.
References
- Ikujiro Nonaka, “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science, Vol. 5, No. 1, 1994. INFORMS
- Sam McVeety and Amir Hormati, “Introducing the Open Knowledge Format,” Google Cloud, 12 June 2026. Google Cloud
- Sam McVeety and Amir Hormati, “Open Knowledge Format v0.2 tackles agentic trust,” Google Cloud, 24 July 2026. Google Cloud
- Google, “Agent Development Kit: Technical Overview.” Google ADK
- Google, “Memory: Long-term knowledge with MemoryService,” Agent Development Kit documentation. Google ADK