How to Prepare Your Business Data for AI Agents: The Checklist, the Order, and the Mistakes
An owner-level checklist for preparing business data before handing it to an AI agent: reference lists, normalization, process documentation, roles — and the mistakes that quietly kill the project.
TL;DR
| Question | Short answer |
|---|---|
| Can I just connect my files to an AI agent and let it figure things out? | You can — and it will produce confident answers built on contradictory data. Don’t |
| What comes first? | Pick one process and measure its current cost (hours, errors, money). Everything else serves that |
| What is “reference data”? | The lists your business runs on: customers, products, prices, statuses, units. One canonical copy of each, with a named owner |
| How much history should I hand over? | The active 3–6 months. Older years are a migration project, not an agent’s job |
| What proves the agent works? | A test set: 20–50 real cases with known correct answers, checked after every change |
| Biggest single mistake? | Free-text where a controlled list should be — statuses like “sorta paid”, colors as data, one sheet per month |
The pitch sounds irresistible: connect Google Drive or SharePoint, and an AI agent reads your spreadsheets, answers questions, and runs your operations. OpenAI’s own AgentKit page promises agents you “visually build and iterate on” (announcement). The demo always works. Then Tuesday happens: the agent quotes a price from an outdated list, “Romashka LLC” and “Romashka” become two different customers, and nobody can say which number is true.
The gap is almost never the model. It’s the data and the process behind it. This is the preparation checklist I run with clients before any agent touches anything — in the order that actually works, with the mistakes that quietly kill such projects.
Why raw files sabotage an agent
Three mechanisms, each independently fatal:
- Contradictions become confident answers. An agent doesn’t know that Price-List-2025-FINAL-v3.xlsx supersedes prices-old.xlsx. It averages, guesses, or picks one — and states the result with full confidence. Spreadsheet audits going back two decades (Ray Panko, University of Hawaii) consistently find ~88% of business spreadsheets contain errors (research summary); an agent inherits every one of them, plus the conflicts between files.
- No keys, no joins. Your order table says client “AK-114”, the payments sheet says “Kamensky A.”, and the CRM tab says “Andrey — wholesale”. A human resolves this from memory; an agent can’t. Without shared identifiers, every cross-check the agent makes is a coin flip.
- Volume burns money before it burns anything else. A 40-tab workbook re-read on every request means your costs scale with conversation length, not with value delivered. (The metered-cost math behind AI builders is laid out in Your Replit or Lovable App Isn’t Production-Ready.)
Preparation fixes all three — and it’s mostly work you’d eventually have to do anyway to grow past spreadsheets.
The checklist, in order
1. Pick one process and baseline it
One process: order intake, or invoice approval, or stock updates. Not “operations”. Write down what it costs today: hours per week, error rate, the last mistake’s price. Without this baseline you cannot prove the agent saved anything — the project dies at the first budget question.
2. Inventory every source
List every file, tab, tool, and person the process touches. Include the shadow ones: the manager’s private tracker, the WhatsApp group where exceptions actually get decided, the whiteboard. Anything you skip here will resurface as the agent’s blind spot.
3. Extract the reference data
This is the heart of preparation. For each list your business runs on — customers, products, prices, units, statuses, warehouses, cost centers — produce exactly one canonical version:
- One record per real thing. “OOO Romashka”, “Romashka LLC”, “romashka (wholesale)” collapse into one customer with one ID.
- A named owner and an update rule. Who changes the price list, and what triggers a change? Reference data without an owner rots within a quarter.
- Effective dates where reality changes. Prices, exchange rates, tariffs: keep history, but the agent must always know which value is current.
4. Normalize the formats
Boring, decisive rules:
| Rule | Broken | Fixed |
|---|---|---|
| Statuses are a controlled list | ”paid?”, “kinda paid”, “PAID!!” | paid / pending / overdue |
| One row = one event | Three orders merged in one row | One row per order |
| Dates in one format | 03.04.26, Apr-3, 2026/4/3 | 2026-04-03 |
| Units explicit | ”5” (boxes? pieces? liters?) | 5 box |
| No layout-as-data | Merged cells, red = overdue, one sheet per month | Plain rows, status column, date column |
Colors and merged cells are invisible to an agent — everything they encode must become a column.
5. Separate facts from references
Orders, payments, shipments, tickets are events: they accumulate, they’re never edited retroactively. Customers, products, prices are references: they change. Keeping them in separate tables (instead of one mega-sheet) is what makes an agent’s answers consistent and checkable — and it’s the same separation a real database enforces (why Sheets stops scaling).
6. Write the process down as it actually runs
Not the org-chart version — the real one. For each step: who does it, what triggers it, what they decide, what the exceptions are, what SLA applies. Two half-day sessions with the people who touch the process is usually enough for the first honest version. Every unwritten exception you skip becomes a future Friday-evening incident.
7. Assign roles and permissions
Decide now who may see costs, who may edit prices, who may approve refunds. In chat tools everyone sees everything; in a real system this becomes role-based access and an audit trail. Handing the agent a permission model (even a simple table) prevents both leaks and “helpful” overreach.
8. Define guardrails and the escalation rule
What may the agent do alone (answer, draft, tag, route) versus what always requires a human (send money, contact a customer, change reference data, anything with confidence below the bar). Also define the error path: when data is missing or contradictory, the agent must stop and ask — not improvise.
9. Build the test set
Take 20–50 real historical cases where you know the correct outcome, including the nasty ones. This set is your definition of “works”. After any prompt or data change, the agent must pass it. Without a test set, “better” is indistinguishable from “different” — the failure mode behind most token bonfires.
10. Package the handover
What the agent (or the engineer building around it) receives: canonical reference files, the process document, the permission table, the guardrail rules, the test set, and the KPI baseline. That package — not the prompt — is the actual project.
The mistakes that kill these projects
| Mistake | What happens | The fix |
|---|---|---|
| Handing over the raw folder | Agent answers from the wrong file version | Steps 3–5 first, one process at a time |
| Reference data without an owner | Lists quietly diverge again | Named owner + update rule, in writing |
| Free-text statuses | Agent can’t count, filter, or escalate reliably | Controlled vocabulary |
| Colors/merged cells as data | Agent is blind to half the meaning | Columns, plain rows |
| Migrating all history on day one | Months of work before any result | Active 3–6 months, archive the rest |
| Unwritten exceptions live in one head | Agent “fails randomly” | Process doc + shadow-source inventory |
| No test set | Endless prompting, no proof of progress | 20–50 cases with known answers |
| No KPI baseline | ROI unprovable; budget cut mid-project | Measure before you build |
What changes once data is prepared
The same agent, on the same model, starts behaving like a different system: it joins customers to payments without coin flips, its costs stop scaling with file size, its answers become checkable against the test set — and the remaining errors are fixable in one place instead of hunted across forty tabs. This is also exactly the preparation that makes a later migration to a real platform cheap: the Sheets-to-SQL demo shows what that looks like with live numbers.
Preparation is most of the battle — but not all of it. The follow-up article covers the part data preparation cannot fix: why teams burn hundreds of prompts after doing everything right, and why the missing piece is a person.
Sources & further reading
- Introducing AgentKit — OpenAI — what the vendors actually ship (and who their “builders” are)
- Raymond Panko, What We Know About Spreadsheet Errors — the ~88% error-rate audits
- When Google Sheets Stops Scaling — the volume ceiling behind mechanism 3
- Google Sheets to SQL in One Transaction — where this checklist leads: 1,686 records, 12 defects found, live demo