How Do I Get My Company's Data Ready for AI Agents?

Ready means reachable, permissioned, and defined. It does not mean clean. Four things get an agent working: read-only access to the live system instead of an exported file, an agent identity that inherits the permissions of a real employee role, a written definition of the ten to twenty fields the chosen workflow actually reads, and one deduplicated master list for the entity that workflow turns on. Three to six weeks per workflow, not the eighteen month data programme you were quoted.

Why companies get this wrong

The wrong question is asked first. Someone senior asks whether the company data is good enough for AI, a consultancy answers no, and a readiness programme starts: a lake, a catalogue, a governance committee, a quality score. Eighteen months and a seven figure invoice later the data is measurably better and not one agent is doing a job. The programme became the deliverable. Meanwhile the finance team is still coding invoices by hand, which was the thing anybody actually wanted fixed.

The reason this keeps happening is a bad mental model. Companies picture an agent as a reporting tool that needs one warehouse fed by everything. An agent works more like a new joiner. It reads the same three screens the person it is replacing reads, asks about the fields it does not understand, and looks things up in the shared drive when a case is odd. A new joiner does not need your data warehouse finished before their first day. They need a login, the right permissions, and someone to explain what the status codes mean. Agents need exactly that, and the access piece is where six of every ten stalls actually happen, because granting it is a security decision rather than a technical one.

The framework I use with clients

Five steps, run alongside the build rather than in front of it. Step one is the one that saves the year.

Step one: scope the data to one workflow, then count the fields. Pick the workflow first, then list every field the agent will read to do it. Invoice coding needs supplier name, invoice number, date, net, tax, currency, purchase order reference, cost centre, and the last twelve months of how that supplier was coded before. That is nine fields and one history table. It is not your finance system. If the list runs past twenty five fields, the workflow is too broad and you are back to boiling the ocean. Everything outside that list stays exactly as messy as it is today.

Step two: give the agent an identity, not a master key. Create a service account that mirrors one real job role, read-only for the first four weeks, and log every call it makes. This is a security conversation, so start it in week one and expect it to take two to three weeks in a regulated company. Two rules make the yes easier: the agent can never see data the role it mirrors could not see, and every read is attributable to a run and a case. Agents handed a broad admin credential get switched off by the first person who notices, and they are right to switch them off.

Step three: deduplicate one entity, not the database. Every workflow turns on a single entity. Invoice coding turns on supplier. Pipeline routing turns on account. Support triage turns on customer. Fix duplicates on that one entity and ignore the rest. My working threshold: if more than 5 percent of the entity records are duplicates, or if any single real world entity appears under three or more spellings, dedupe before you ship, because the agent will confidently split one supplier into three and the numbers will not tie. Below that, ship and clean as you go.

Step four: write down what the fields mean. Two pages, plain English, owned by the function and not by IT. What counts as an active customer. What status 4 means and who sets it. Which of the three revenue columns is the one finance reports. Which fields are known to be unreliable and should never be used alone. This document is the single highest return artefact in the whole exercise, because the failure mode of an agent is not that it cannot read the field, it is that it reads the field correctly and interprets it the way a stranger would. A new finance analyst learns this in six weeks of corridor conversation. An agent never gets the corridor.

Step five: index the documents where they sit. The contracts, policies, PDFs, and email threads do not get migrated. They get indexed in place, retrieved at the moment of the question, and cited with a source and page on every answer. The one job that matters here is version hygiene: quarantine superseded documents before you index, because an agent quoting the 2023 expense policy with a confident citation does more damage than an agent with no documents at all.

What that means in practice, by workflow:

From my operating seat

Inside one client I run, the finance agent was blocked for five weeks and not one day of it was about data quality. It was about who signs off a service account that can read the ledger. We unblocked it by cutting the ask down to a single read-only role scoped to one company code, with every call logged and a weekly report of what the agent had read going to the controller. That got signed in four days. The lesson I keep relearning is that data readiness is mostly an approvals problem wearing a technical costume, and the fix is to shrink the ask until somebody can say yes to it.

Twenty years in the C-suite and three exits taught me the same thing about diligence rooms. Buyers never asked whether the data was clean. They asked whether we could produce the same number twice, and say where it came from. That is the actual bar for an agent too. An agent working off average data with defined fields and cited sources beats an agent working off beautiful data nobody has written a definition for, every time, and it ships eleven months sooner.

Do I need a data warehouse before I use AI agents?

No, for the first three or four workflows. Those almost always sit inside one system, and an agent that codes invoices needs read access to the accounting platform, not a copy of it in a lake. The warehouse earns its place when a workflow spans three or more systems and needs one version of a number, which in practice means board and cash reporting. Start there and you spend nine to eighteen months and ship nothing, because the warehouse project ends up holding the budget the agents needed.

How long does it take to get company data ready for AI agents?

Three to six weeks per workflow, running alongside the build. Week one is access and identity, and that is where the delay lives because it is a security decision. Weeks two and three are field definitions and deduplicating the one entity the workflow depends on. Weeks four to six are the document set. Budget 30 to 40 percent of build effort for data work on the first workflow and roughly half that on the second, since the access pattern and the definitions carry across.

Can AI agents work with PDFs, contracts, and messy shared drives?

Yes, and this needs the least preparation of anything. Documents get indexed where they sit and retrieved at the moment of the question, so scanned contracts and policy PDFs become usable with no migration. Two rules keep it safe: every claim cites its source document and page, and the index inherits the same folder permissions the humans have. The real work is quarantining out of date versions, because a confident citation of a superseded policy is worse than no answer.

Where I come in

This is what I build and run inside companies: the scoped field list, the agent identity a CFO or a general counsel will actually sign, the definitions document the function owns, and then the agents themselves working in finance, pipeline, onboarding, and compliance off that data. If you have been told you need two years of data work before AI is possible here, get a second opinion before you sign it. See how I work on data and IP strategy, or start at meethayat.com.