As I was writing about context and lock-in, another thought landed.
There is a category of software we often talk about as if it only exists to hold data. CRM. ERP. Project systems. Finance systems. Stock systems. All the SaaS machinery that surrounds a business.
When you are on your own, or in a very small company, some of that machinery is starting to look different.
With tools like Codex, Claude Code, ChatGPT, and agentic co-workers, one or two people can now do things that used to need a proper system around them. You can keep files. You can query your own notes. You can ask an agent to pull context together. You can automate a surprising amount of the awkward middle work.
So it is tempting to ask a simple question:
Do we still need all these SaaS systems?
Sometimes the answer may be no.
But not always.
The thing many SaaS systems do well is not storage. It is shared understanding.
Collaboration changes the problem
On your own, you can work around a mess.
You know what you mean. You know where you put the file. You know that "stock" means one thing in your head today and something slightly different in the spreadsheet you made last month. You can hold the contradiction because you are the system.
Teams cannot work that way for long.
The moment several people need to work on the same data, the challenge changes. The problem is not just whether the data exists. The problem is whether everyone means the same thing when they use it.
That is where SaaS earns its place.
A CRM says: this is what we mean by a customer, a lead, an opportunity, a stage, a contact, an account, a renewal, a next action.
An ERP says: this is what we mean by an order, a purchase, a stock position, a warehouse, an invoice, a commitment, an available quantity.
A finance system says: this is what we mean by approved, posted, reconciled, paid, overdue, recognised, deferred.
The software is not only a database. It is a language with rules attached.
What does "in stock" mean?
Take a simple example.
Someone asks, "How much is in stock?"
That sounds obvious until the business depends on the answer.
Do you mean how much is physically in the warehouse?
Do you mean how much has been purchased from the supplier?
Do you mean how much is available to sell?
Do you mean how much is in the warehouse but already allocated to customer orders?
Do you mean what is arriving next week?
Do you mean what can be promised without causing a problem for someone else?
All of those answers can be true. They are just different truths.
If every person uses their own meaning, the business is not collaborating. It is accidentally arguing through data.
This is the quiet value of shared systems. They force a common language. Sometimes clumsily. Sometimes expensively. Sometimes with far too many screens. But they force a business to decide what its words mean.
The price of the common language
The cost is that the language is often designed by someone else.
The SaaS provider has to build a system that works for many businesses. That means general concepts, configuration options, permissions, custom fields, workflows, reports, and enough flexibility to make the product useful across a market.
Then the implementer arrives. They customise the system. They make decisions. They translate the business into the product's structure.
That can be useful. It can also quietly reshape how the business thinks.
After a while, people stop asking, "What is the right way for us to understand this?" and start asking, "What does the system let us call it?"
You can change the colours. You can change a label. You can add a field.
But often you are still thinking in the shape of the software.
That is the bargain.
You get consistency, access control, process, reporting, audit, and a shared vocabulary.
You also inherit someone else's mental model of the work.
What if the shared language was separate?
This is where agentic systems make the question interesting.
What if a business had a small, explicit layer that defined its common understanding?
Not a giant replacement ERP on day one. Not a heroic platform project. Something smaller and more practical.
A shared store that says:
- This is what we mean by customer.
- This is what we mean by stock.
- This is what counts as available.
- This is who is allowed to change the source data.
- This is where the current truth lives.
- This is what an agent may infer.
- This is what an agent must ask a human to confirm.
The control question is where the value gets practical.
What do we store? Where does it live? Which system is allowed to change it? What can an agent read, what can it write, and when must it ask a human?
You could imagine that as an MCP server called something very boring and very useful, like common understanding.
Every agent in the company can ask it the same questions.
What does this term mean here? Which source is authoritative? What is the rule for this calculation? Which data can I use? Which action needs approval? Which language should I use when I explain this to a customer, a director, or an operations person?
That starts to replicate some of the logic we put into ERP and CRM systems.
But it does it in a way that can be much closer to the business.
The spine, not the cage
The interesting part is not that agents replace every system.
That is too blunt.
Finance still needs controls. Warehouses still need operational truth. CRMs still help teams coordinate customer work. There are regulatory, audit, security, and process reasons why serious systems exist.
But maybe some of the value moves.
Maybe the shared language does not have to live entirely inside one vendor's product.
Maybe the business can give its agents a spine: the rules, definitions, guardrails, source-of-truth map, and permission model that make work understandable.
Then people can work in more natural ways around that spine.
One person might talk to their agent. Another might use a spreadsheet. Another might use a project board. Another might prefer a structured form. The important thing is that the shared concepts underneath do not drift.
Everyone can work in their own way without everyone inventing their own meaning.
A small experiment
So here is the task, should you decide to accept it.
Pick one part of your company where the words matter.
It might be stock. It might be customer status. It might be project health. It might be onboarding. It might be finance approvals. It might be the rules around how you quote, fulfil, refund, renew, or escalate.
Create a small shared folder, repo, database, or MCP service for that area.
Keep it simple. Start with:
- The key terms and what they mean.
- The source of truth for each term.
- The rules that must not be broken.
- The decisions an agent can make alone.
- The decisions that need a human.
- The wording your team should use when explaining the concept.
Then let a few people use their agents against it.
Do they get better answers?
Do they ask better questions?
Do they spend less time translating between systems?
Do they feel more in control, or less?
That last question matters.
The human bit is still the point
The goal is not to make the company think like an ERP.
The goal is to stop needing humans to contort themselves around software that was designed for someone else's version of the work.
If the rules and guardrails are clear enough for agents to follow, then people may be able to work in a more human way again.
They can speak, sketch, ask, compare, challenge, and decide.
The agent can translate that intent into the shared language of the business.
That is powerful.
It is also a little uncomfortable, because it asks a very direct question of our systems:
Are they giving us shared understanding, or are they just forcing us to think in their shape?
Some SaaS companies will adapt to this. I hope they do. The best ones will become language layers, guardrail layers, and collaboration layers for agentic work.
Until then, we can start experimenting ourselves.
Start small. Define one shared language. Give it to the agents. See what breaks. See what improves.
Then tell me what you find.