Skip to main content
Copertina articolo: Data modelling for AI agents: Clean and reusable context
Articles/Data Engineering

Data modelling for AI agents: Clean and reusable context

/

Ask the agent: “Which users have activated this week?” He answers. Then you find that “activated” means different things in three tables: in one it is who has completed onboarding, in another who has created a project, in another who has invited a colleague.

The problem is not the question, but the data model.

An agent needs clear entities

To analyze correctly, you need to know what exists in your domain: users, accounts, events, sessions, features, experiments, sources, tasks, outputs, decisions. Each entity must have precise relationships. An event belongs to a user? To an account? To both? Is an output linked to what task? Who approved a decision?

These apparently technical questions define what the organization will really understand.

Modeling for questions

A good data model comes from the operational questions that the team needs to ask. If you want to know if an agent improves onboarding, you need to connect exposure, interaction, setup completion and subsequent return. If you want to understand if it reduces the support work, you need to connect tickets, drafts, human modifications, reopenings and satisfaction. To evaluate insight marketing, you need to tie proposal, experiment, result and decision.

The data model must reflect decisions, not just source systems.

Avoid duplication and ambiguity

Incoherent IDs, duplicate events, discordant timestamps and non-shared definitions destroy analysis. An AI agent can mask these problems with fluid responses, but fluidity does not guarantee reliability.

You need a data glossary that includes metric name, definition, source, owner, update frequency and limits.

How to apply data modelling without complicated work

Do not start with the newest tool. Start with the point where the team is wasting time, discussing without data or making decisions with incomplete information. Here you can see whether the theme has operational value or is just a nice slide idea.

An agent is not a brilliant chat: he must have clear input, limited tools, controlled memory and an explicit rule to pass the decision on to a person when the risk grows.

A useful sequence:

  1. Define which data the agent can read and which no. 2. Write the expected result in verifiable form, not as a general intention. 3. Decide when it needs human revision before sending or saving output. 4. Measure time saved, avoided errors and cases where the agent stops.

What to measure to see if it works

The question is not “have we used AI?” or “have we added a dashboard?” The question is: what decision has become faster, clearer or safer? If a decision does not change, the project risks remaining technical decoration.

It measures at least three levels: spared operating time, quality of the result and confidence of the team in the process. Time alone can deceive: a faster but less controllable flow is not an improvement. Quality alone can deceive: a perfect system but too slow does not enter everyday work.

Connection with ginnytech path

To turn this reasoning into practical competence, link this article to the path Agentic AI Data Works. The goal is to build a way of working in which data, models and people cooperate without losing control.

Reflection

Data modelling is an act of realism. It decides how the product sees itself.

AI agents help to better question the data, but they cannot invent consistency where it does not exist.

Before asking for intelligent insights, build readable foundations.

Related articles

Product Observability: Seeing Growth As It Happens
June 14, 20261 min read
Read
Growth data pipeline: From click to decision
June 14, 20261 min read
Read
Observation for AI agents: See what happens inside the system
June 12, 20261 min read
Read