How AI agents actually read client marketing data.

An AI agent asked about a client's marketing does not know anything about that client's marketing. It is given a way to run queries against your tables, it writes a query, it reads the result, and it turns that result into a sentence.

That is the whole mechanism, and it explains both what agents are good at and how they fail. Given consistent tables an agent is genuinely useful, because writing the query is the part most people cannot do. Given inconsistent tables it writes a query that runs, gets a number back, and reports it in exactly the same confident tone.

Four things, and none of them is a better model.

• Tables it can query directly

  An agent reading a dashboard screenshot is guessing. An agent running SQL against the tables underneath is reading. If your data only exists inside a reporting tool, there is nothing for an agent to query.

• One name per metric

  Asked for total spend across platforms, an agent has to choose which columns to add. If three platforms name spend three ways it either picks one or sums figures that are not comparable, and both look like an answer.

• Column names that mean something

  An agent infers meaning from the name. A column called value_2 forces a guess. A column called spend_usd does not. Naming is documentation an agent can actually read.

• A stated grain per table

  One row per day is a different table from one row per campaign per day, and joining them without accounting for that multiplies every figure. An agent cannot detect this, because both queries succeed.

Read-only access is the first one, and it is not optional. An agent that can write to your tables can also change them while trying to be helpful.

Then scope. An agent pointed at every table in the warehouse will find the raw layer and answer from it, which is the layer with the platform inconsistencies still in it. Point it at the modelled tables only, so the numbers it reads are the numbers your reports read. For an agency, scope also means clients: an agent that can read every client's rows will answer a question about one client from all of them unless something in the data stops it.

Then logging. Keep the queries it ran, not just the answers it gave. When somebody disputes a figure the query is the evidence, and without it you are comparing two opinions.

Agents are strong on questions that are a query you could write if you had the time. Which campaigns spent more than last month, which accounts have not delivered in three days, what the cost per result was by country. These are lookups, and a lookup is checkable.

They are weak on questions that need a judgement nobody has written down. Which channel is working, whether a campaign is worth continuing, why performance dropped. The data does not contain the answer, so the model supplies one, and it will sound the same as the checkable kind.

The practical rule: if you could verify the answer with a query, ask. If verifying would take a conversation with three people, the agent is guessing on their behalf.

The modelling is what makes an agent answerable: one name per metric, one type, one grain and one currency, across every source, inside a warehouse you own.

The chatbot reads those same modelled tables, and so do your client dashboards. You bring your own model key, so the choice of model is yours and the data stays in your account rather than being sent somewhere to be reasoned about.