I trained another member of the team to work with Claude today.

We connected it to company information, CRM data and the other systems needed to do a useful piece of work.

And I had one of those moments where something that has been sitting in the background suddenly becomes obvious.

The future is either ERP or AI.

That is deliberately too neat, of course. I do not think every business will choose one enormous ERP system, or hand the entire company to Claude or Codex.

But I do think every company now needs to solve the same problem:

How do we create one coherent view of the work when the truth is scattered across many different systems?

There are two serious answers. Consolidate the company into an integrated suite. Or keep the specialist systems and use an authorised agentic layer to orchestrate them.

The thing that loses is disconnected software.

A CRM can only know what reaches the CRM

Take a customer question that sounds simple: what is really happening with this account?

The contact and deal may be in HubSpot. The invoice may be in Xero. The latest concern may be buried in email. Delivery evidence may sit in a project system. A decision may be in meeting notes. The contract may be in a document store.

No single application has the answer.

The CRM can produce a very good answer about the CRM. The finance system can produce a very good answer about finance. Their built-in AI can only reason over the context it can see and the actions it is allowed to take.

This does not mean HubSpot or Xero are sealed boxes. HubSpot has a substantial app marketplace and an official remote MCP server with authorised access to many CRM objects. Xero provides OAuth-based APIs for accounting integrations.

That matters. It means the systems can participate in a larger operating model.

But a connector is a route. It is not, by itself, shared memory, a permission model, a source of truth or a coherent understanding of the company.

The old answer is ERP

ERP exists because businesses discovered this fragmentation problem a long time ago.

Instead of running finance, sales, stock, people, purchasing and operations as unrelated islands, an ERP suite brings them into a common data model and process environment.

Odoo is a very clear example. Its suite spans CRM, accounting, inventory, ecommerce, point of sale, projects and other business functions. The attraction is not that every individual module must be the best product in the world. It is that the modules know they belong to the same company.

Chinese enterprise platforms are making the same argument. I may have been trying to remember Yonyou or Kingdee. Yonyou's YonBIP describes an integrated environment across finance, people, supply chain, marketing, procurement, manufacturing and projects. Kingdee similarly combines finance, procurement, manufacturing, supply chain, sales and people functions.

That gives them a fighting chance in the AI era.

If the system already has common identities, objects, processes and permissions, its AI has a much richer business context to work with.

The new answer is orchestration

The alternative is not to move everything into one suite.

It is to leave each system authoritative for the thing it does well, then give an agentic work layer permission to assemble the relevant context when a task requires it.

Claude calls these integrations connectors. OpenAI calls connected services apps. MCP provides a common protocol through which agents can discover tools and data.

The names will change. The architectural move is the important part.

I do not need to copy every email into the CRM. I need the authorised agent to inspect the relevant email when the task requires it, identify where it came from, combine it with the CRM record and finance position, and show me the evidence behind its answer.

The company does not need one application.

It needs one coherent view of the work.

Two routes to a coherent company: consolidate CRM, finance, operations and people into an ERP suite, or keep source systems authoritative and connect them through an agentic layer using APIs, MCP and events. Both routes require identity, permissions, evidence, approvals and recovery.
The future is coherence by consolidation, or coherence by orchestration. Both routes still need disciplined authority and evidence.

Integration is not the same as context

This is where companies can fool themselves.

They buy several connectors, push selected fields from one product into another, and declare the problem solved.

Then the copied data becomes stale. The customer has three different identifiers. A field means something slightly different in each system. Permissions do not travel cleanly. Nobody knows which version is authoritative. An automated action succeeds in one application and fails in the next.

An agentic layer can also create a mess if it is allowed to invent a new shadow database containing a little bit of everything.

The safer model is explicit:

Layer Job Rule
Systems of record Hold authoritative customer, finance, people and operational data. Do not duplicate data without a defined reason and owner.
Agentic work layer Retrieve context, reason across systems and coordinate bounded actions. Carry provenance and uncertainty with every answer.
Control plane Manage identity, permissions, approvals, evidence, limits and recovery. No consequential action without the required authority and receipt.

This is why authorisation is not a technical footnote. The current MCP specification explicitly supports least-privilege scopes and step-up authorisation. An agent should not receive every permission it might ever need just because one workflow needs to read a deal and another needs to create an invoice draft.

What happens to SaaS?

I think specialist software companies now have three choices.

  1. Become a broader suite. Add enough adjacent functions and a common data model to compete as an ERP-style environment.
  2. Become brilliantly agent-accessible. Remain the best system for one job, but make it extraordinarily easy and safe for Claude, Codex and other authorised agents to use.
  3. Stay closed. Keep the data and actions difficult to reach, and risk becoming a background utility that customers visit only when an agent cannot complete the task for them.

I would be very careful about building a little AI assistant inside a SaaS product and assuming that is the strategy.

Why would I begin with the assistant that can see only one application when I can begin with the agent that can see the authorised parts of the company?

The embedded assistant can still be excellent at product-specific work. But it must participate in the wider company context rather than trying to trap the user inside its screen.

Make your MCP boringly excellent

If I ran a best-of-breed SaaS company, I would make its API and MCP surface one of the best parts of the product.

Not flashy. Boringly excellent.

  • A clear object model with stable identifiers.
  • Granular permissions and separate read and write authority.
  • Useful error messages and idempotent actions that can be retried safely.
  • Events and webhooks so agents do not have to keep asking what changed.
  • Sandboxes and test identities that behave like the real system.
  • Audit records showing who or what acted, under whose authority and with which inputs.
  • Versioned documentation, predictable deprecation and exportable data.
  • Approval points for money, publication, deletion and other consequential actions.

The vendor that does this becomes the best component in an agentic company.

The vendor that does not may discover that a pleasant screen and a proprietary chatbot are no longer enough.

What I would do inside a company

I would not begin by migrating everything into one enormous new database. I would begin by mapping the work.

  1. Name the systems of record. Decide where customer, contract, finance, people and delivery truth lives.
  2. Map the cross-system questions. Find the work that currently requires people to open three or four applications.
  3. Connect read access first. Let the agent assemble context before allowing it to change anything.
  4. Preserve provenance. Every important answer should show where the evidence came from and when it was retrieved.
  5. Add actions in stages. Draft, review, approve, execute and verify should be separate authorities where the consequence warrants it.
  6. Keep an escape route. Business rules, skills and evidence should not exist only inside one model provider or one application.

This is close to what I am building with Orchistra: the existing finance, CRM, email and operational systems remain authoritative, while an operating layer coordinates goals, permissions, work and evidence across them.

So is the future really ERP or AI?

Not quite.

ERP platforms will add agentic interfaces. Agentic platforms will make collections of specialist products behave more like a coherent suite. Many companies will use both.

The real choice is:

Coherence by consolidation, or coherence by orchestration.

Both can work. Both can fail. One giant suite can become rigid and expensive. One clever agent can become dangerous if identity, authority and evidence are vague.

But fragmented software that cannot expose its data and actions safely has a much harder future.

So if you are building SaaS, either help the company become whole or become exceptionally good at working with the layer that does.

Because the user is not trying to operate your application.

They are trying to operate their company.