The promise of AI agents is compelling: ask a question in plain language and get the answer; tell the agent what to change and it changes it. The demos look effortless because the demo data is clean.
Real company data is not. The CRM is half set up. The billing system and the CRM disagree about what a customer pays. The same account exists three times under slightly different names. Renewal dates live in a spreadsheet that one person maintains. Product usage sits in a database nobody has linked to the account it belongs to.
Put an agent on top of that and it will still answer, confidently. It will just be wrong in ways that are hard to spot.
Why does the data foundation have to come before AI agents?
Because an agent can only report and act on what your systems record. If the CRM, billing and product data disagree, the agent’s answers are guesses and its actions spread the errors. Structuring the data first gives every agent one agreed version of the facts, so its reports can be trusted and its actions are safe.
The short version is the one on our homepage: no data, no AI. In our experience it is also where many AI projects quietly stall. MIT NANDA’s 2025 report “The GenAI Divide” found that only about 5% of generative-AI pilots reach production with a measurable return. A pilot on a tidy sample can look excellent; the same idea on the real, messy data often does not survive the move.
What goes wrong when agents sit on messy data
The failures are predictable, and they get worse once the agent can act as well as answer:
- Reports that do not match. Ask for ARR and the agent adds up the CRM. Finance adds up the invoices. The board gets two numbers and trusts neither.
- Duplicates that multiply. Three records for one customer means three health scores, three renewal reminders and an account manager who looks careless.
- Actions on the wrong facts. An agent told to send renewal reminders sends them from whatever dates the CRM holds. If those dates are stale, so are the reminders, and now they have reached customers.
- Answers nobody can check. When data is scattered, nobody can trace where a figure came from, so nobody can tell whether it is right.
Pulling data from bad sources produces bad reports. Pushing data into bad sources makes them worse. Both halves of what an agent does depend on the foundation underneath.
What a data foundation actually is
A data foundation is not a data-warehouse program or a year-long migration. For a growing company, and especially a SaaS company, it comes down to a few things done properly:
- A CRM set up for how you sell, renew and bill. Pipelines, stages, objects and fields designed around how the company actually works, rather than around a default template.
- Each fact recorded once. Accounts, contacts and contracts without duplicates; products, prices and renewal terms kept in one place.
- The systems connected. Invoices and payments matched to the right customer, product usage linked to the account it belongs to, and a customer, a contract and an invoice meaning the same thing in every system.
- Something keeping them in agreement. Data drifts unless something maintains it. In our builds that is the Processor, which runs the workflows between systems, retries what fails and keeps a complete audit trail of every step.
The detail is on our data foundation page.
How to tell whether your data is ready
A few questions give a fast, honest answer. If any of them takes more than a few minutes, or gets two different answers from two different people, the foundation needs work before agents go on top:
- Does ARR from the CRM match ARR from finance?
- Does every customer exist exactly once, in every system?
- Are renewal dates and terms in the CRM, and are they correct?
- Can you see product usage per account, next to what that account pays?
- When a deal closes, does the rest of the company find out without someone sending a message?
Checking this is part of our AI Readiness Assessment: whether the CRM and finance systems agree well enough for AI to rely on them, before anything is built.
The order that works: data, then the AI layer, then agents
Every engagement we run builds the same three layers, in the same order:
- 1. The data foundation. The CRM and the systems around it set up, structured and kept in agreement.
- 2. The AI layer. That data connected to the AI assistant the team already uses, over MCP (Model Context Protocol), the open standard for connecting AI to real systems. Anyone with permission can pull data, push data and trigger actions in plain language.
- 3. Department agents. Purpose-built agents for finance, sales and customer success, each with the reports and the actions that team needs, within its permissions and with an audit trail.
Skipping the first layer feels faster. It rarely is. The time saved at the start is spent later explaining why the agent’s numbers do not match finance’s, and repairing records it changed. Built in order, each layer makes the next one cheaper, and the agents on top can be trusted from the first day.
Built this way, the foundation also stays yours, and in Europe. The data stays on EU infrastructure during the build, the AI model is your choice, and if you change the model later, the foundation and everything built on it stay the same.