# What Data Does an AI Agent Actually Need?

> The data requirements for AI agents aren't a two-year project: what an agent really needs and what you can safely leave for later.

- Canonical: https://arkatai.com/en/data-requirements-ai-agents/
- Site: Arkatai (https://arkatai.com) — agentic operations as a service
- Language: en
- Published: 2026-07-19

---


An AI agent doesn't need a two-year data project before it can start working. It needs three things: access to the systems where the case it will handle actually lives, your operating rules written down, and a handful of already-solved cases so you can measure whether it does the job well. None of that requires clean, unified, governed data across the whole company. It requires having the data where the agent will use it, for the specific task you hand it.

I say this up front because the "data first" myth is the most expensive excuse I see in boardrooms. It blocks the start for quarters, burns budget on infrastructure nobody will use yet, and in the end it never answers the question that mattered: can an agent run this process reliably with the data I already have?

## The "I need to fix the data first" myth

The idea is inherited from earlier projects. Training your own predictive model or building a corporate dashboard genuinely did require consolidating years of history, normalising schemas and cleaning records. That work is real and sometimes necessary, but it's a different job.

An agent that runs an operational process doesn't learn from your history. It uses an already-trained model and applies *your* rules to *the case in front of it*. To reconcile an invoice it doesn't need the hundred thousand invoices of the last decade in a data lake. It needs to read this invoice, the matching purchase order and delivery note, and to know what tolerance your company accepts. That data already exists, in your ERP and in the head of whoever reconciles today. The work isn't building a new warehouse but giving access to what's there and making the rule explicit.

## What an agent does need

When I assess whether an operation has enough data for an agent, I look at three pieces.

**Access to the systems where the case lives.** The agent works inside your ERP, your email, your document store, your CRM, wherever the information a person would consult already sits. There's no need to move it anywhere. The agent needs to read it, and to write the result where it belongs, with specific permissions. How that connection is made, and what to do when the system is old, is in [integrating AI agents with the ERP](/en/integrating-ai-agents-erp/).

**Explicit rules.** The criteria by which each case is decided today: what tolerance is accepted, which combinations approve themselves, what triggers a review. If that criteria only lives in the experience of two people, the first job isn't technical, it's a business one: writing it down. That step —encoding the operating model— underpins everything else, and I develop it in [operating model as code](/en/operating-model-as-code/).

**Solved cases to evaluate against.** A set of examples with the answer considered correct: real inputs and the result a good operator would give. You don't need millions, just enough to cover the frequent cases and the edges that matter. They let you measure the agent's quality before it does real work and detect when it drifts. Without this there's no serious way to claim it "works". How that measurement is built is in [AI agent evaluation](/en/ai-agent-evaluation/).

## What an agent doesn't need (yet)

Knowing what you can defer matters just as much, because that's where time and money go without return.

| Not needed to start | Why |
|---|---|
| A corporate data lake | The agent reads the case where it already sits, not a consolidated history |
| Perfect quality across the whole base | The quality of the data that touches the specific task is enough |
| Migrating legacy systems | It integrates with what exists; migration is a separate project |
| A complete data catalogue | You document what the process uses, not the whole map |
| Hand-labelling thousands of records | The agent applies rules; it doesn't learn from your labels |

Nothing on this list is wrong in itself. Much of it makes sense over the medium term. But turning it into a prerequisite for the first agent is what keeps AI in the slide deck and out of the operation. I've watched that pattern up close and analyse it in [why enterprise AI pilots fail](/en/why-enterprise-ai-pilots-fail/). They almost never fail for lack of data, they fail for lack of clear boundaries.

## Working with imperfect data

Your data is imperfect. Everyone's is. The point isn't to wait until it stops being so, but to scope the agent's mandate so the imperfection can't push it into a decision it shouldn't make.

The mechanism is simple: the worse the data, the narrower the mandate. Picture an 80M€ distributor whose supplier master has duplicates and inconsistent names —an entirely ordinary case. There's no need to clean the hundred thousand records before starting. You tell the agent to act only when the match is unambiguous, and to route anything uncertain to a person with the context already prepared. The agent handles the bulk of clean cases from day one, and the dirty ones become a queue of exceptions that, as a bonus, points to exactly which data is worth fixing first. Managing that boundary is what I cover in [exception handling and human escalation](/en/exception-handling-ai-agents/).

That flips the usual order. Instead of "fix all the data, then automate", it's "automate what the data already allows, and let the operation tell me where fixing the rest pays off". The data project stops being a blind prerequisite and becomes a consequence driven by real use.

## Where to start

If I had to reduce it to a sequence for a first process: pick a task with volume and known rules, write down those rules and the exceptions you already know, gather twenty or thirty solved cases that represent the normal and the odd, and check the agent can reach the systems where the case lives. That's enough to start measuring. Whatever is missing gets discovered by measuring, not by planning in the abstract.

Before you start, a realistic look at the state of the house pays off —which processes are described, who owns each rule, what access exists. That's what I review in [prepare your company for agents](/en/prepare-your-company-for-agents/), and it fits within the broader picture of [AI agents for business](/en/ai-agents-for-business/).

## Frequently Asked Questions

### Do I need a data lake to deploy AI agents?

Not to start. An agent that runs a process reads the case where it already lives —in the ERP, email, document store— and applies your rules. A consolidated warehouse can make sense over the medium term for analysis, but turning it into a prerequisite for the first agent is the most common way to never start at all.

### How much data do I need to train an agent?

An operational agent isn't trained on your history: it uses an already-trained model and applies your rules case by case. What you need isn't millions of records but a modest set of already-solved cases —dozens, not millions— to evaluate whether it gets things right and to detect when it drifts.

### Can I use agents if my data is dirty or incomplete?

Yes, by scoping the mandate. You configure the agent to act only when the data is unambiguous and to route anything uncertain to a person. It handles the clean cases from day one, and the exception queue tells you which data is worth cleaning first, instead of cleaning everything blind.

### What matters more, the data or the rules?

The rules, nearly always. The data usually exists in your systems. What's missing is the explicit criteria by which each case is decided. If that criteria only lives in a few people's experience, making it explicit is the prep work that most shapes the outcome.