Grounding Agents in your world

The Semantic and Memory modules give AI agents an anchor in your enterprise, and a way to make that foundation better over time.

This article is part of Designing AI-Native Data Products, a Teradata Labs series on the architecture and standards for data products built to work with agents as well as humans. The full design standards are open-source at: github.com/Teradata/ai-native-data-products.

This article was co-authored with Daniel Tehan.

Semantic and Memory modules are critical for grounding Agents.

AI models are general. Your organisation is specific. A model that doesn’t understand your products, your customers, your terminology, your business rules, or your history isn’t really working for you. It’s working for the average of everything it was trained on.

This context and knowledge gap shows up in a few ways: answers that are technically correct but commercially useless, hallucinations that stem not from model failure but from absence of grounding, and AI that can answer generic questions but can’t reason about your situation.

Context and knowledge are about making your enterprise’s understanding of itself available to AI in a form it can actually use. Business concepts need to be defined, not just named. “Customer” means something specific in your organisation. It’s not a table, it’s a concept with rules, history, and relationships attached. Data needs to be curated and connected to reflect how the business actually works, and knowledge needs to be packaged so it travels with that data. So that when AI encounters a metric, it understands what it means, where it came from, and what it should and shouldn’t be used for.

A cafe loyalty agent is a good place to start. The same agent that helps a barista recognise a returning customer and suggest their usual order needs to understand your customers, your menu, your transaction history, and your business rules. Two modules from the AI Native Data Product Design Standards do that grounding work: Semantic and Memory.

Semantic module

The Semantic module provides a machine-readable map of the data product. Agents query it with SQL, and it’s the only discovery surface the framework requires. The product describes itself, in itself. An enterprise catalog can register it for organisation wide discovery, but the product doesn’t depend on one to function.

This comes together through four tables:

• data_product_map: describes the modules that make up our loyalty data product. A loyalty product returns up to six rows (Domain, Semantic, Prediction, Search, Observability, Memory), each pointing at the actual location (Loyalty_Domain, Loyalty_Prediction, etc.). This is the agent's first query, every session.
• entity_metadata: describes what tables are in each module, and how to query them. In our example it registers the customers table so the agent knows where to get customer information.
• column_metadata: describes what each column means and how to use it. Similarly registering the customer_id column in the customers table, along with a description of what it is and how to use it.
• table_relationship: describes how tables interact with one another. In the loyalty product, customers purchase items from a menu, with transactions linking them together. This captures intra-module foreign keys, reference tables, cross-module joins, multi-hop chains, reverse directions, and more.

Four queries. The agent now knows what modules exist, what tables are in each, what columns are in each table, and how to join them. That’s the foundation for everything the agent does next, and the anchor that keeps it working in your world rather than guessing at it.

But a map only gets you so far. Without memory, an agent rediscovers the same context every session. It can’t learn from experience, build on what worked, or share what it figured out with other agents working on the same data product. Memory is how agents move from repeating themselves to accumulating knowledge. That is how that knowledge becomes a shared, collaborative resource anchored to the data, not locked inside a single session or a single agent.

Memory module

The Memory module captures two things: what agents did during operation (sessions, interactions, learned strategies, user preferences and discovered patterns) and the design decisions made during deployment (module registry, design decisions, business glossary, query cookbook and change log).

It organises these into two categories:

1) Run time memory:

• Agent sessions: tracks active and historical sessions for continuity across interactions with the Loyalty data product.
• Agent interactions: records what the agent did, which tables were involved, and outcomes. Stores SQL and metadata, NOT query result data.
• Learned strategies: successful patterns discovered through experience with the Loyalty data product.
• User preferences: enables personalised agent behaviours for Loyalty product users.
• Discovered patterns: stores pattern metadata and statistical support, NOT individual record details.

2) Design time memory:

• Module registry: tracks available modules and their versions for the Loyalty data product.
• Design decisions: captures rationale behind architectural and design choices for the Loyalty data product.
• Business glossary: defines key terms and concepts relevant to the Loyalty data product.
• Query cookbook: documents effective query patterns and strategies for the Loyalty data product.
• Implementation notes: captures operational knowledge like workarounds, known issues, and deployment tips discovered during implementation.
• Change log: records changes made to the Loyalty data product over time.

The distinction between these two categories matters more than it might appear to at first glance. Design time memory captures what was known and decided before the agent went to work, but it doesn’t stop there. The data product will change over time, data sources will be added, modified or removed and run time learning feeds back into new design decisions. Design time memory captures those changes too. It becomes living documentation, part of a feedback and learning loop where agent experience shapes how the data product evolves. Run time memory captures what the agent learned by doing. Together they give the agent a starting point and a foundation that improves from it.

The Semantic and Memory modules do something neither achieves alone. The Semantic module tells an agent where it is and what it is working with. The Memory module tells it what has been learned, decided, and discovered along the way. One grounds the agent in your world. The other makes sure that grounding gets better with every interaction, every session, every agent that works with the same data product.

The remaining four modules build on this foundation and will be covered in other blogs in this series. Semantic and Memory are where the potential of an AI Native Data Product begins.

Watch Daniel build the loyalty data product from scratch on youtube here: AI Native Data Products — Loyalty product build — YouTube