How to Feed Resolved Customer Data Into an AI Agent or RAG Pipeline (2026)

TL;DR: The fastest path is to resolve customer records when they are ingested, then retrieve the current resolved entity at query time and pass a compact entity summary into the agent or RAG prompt. Vector retrieval can still fetch relevant documents, but it should not decide which customer the model is talking about.

What is the fastest way to feed resolved data into an agent or RAG pipeline?

The fastest operational pattern is simple: do entity resolution before the model is called, then make the agent retrieve the current resolved entity when it needs customer context. The model should reason over the answer to "who is this customer?" rather than over a pile of unjoined records.

In a Tilores build, that means source records are submitted into the entity layer, records are assembled into entities during ingestion, and the application later retrieves the entity by entity ID, source record ID, or search. Tilores documents the relevant GraphQL paths in its API reference, including submit, entity, entityByRecord, and search.

This is different from asking the LLM to infer identity from raw fragments in the prompt. That approach is brittle because prompts are short-lived, retrieval can return semantically similar but wrong records, and the model has no durable memory of how two records were linked. The resolution decision belongs in the data layer.

What should happen at ingestion before the model is called?

At ingestion, each source system should send records into the entity resolution layer with the fields needed for matching, search, and later audit. Tilores rules define how records connect into entities, how search compares input parameters with existing records, and how rule sets, edges, hits, and indexing work in practice.

The matching layer should use deterministic logic where stable identifiers exist, such as source record IDs, account numbers, or verified emails. It should also support probabilistic or fuzzy matching where customer data varies across systems. Tilores publishes material on fuzzy matching algorithms, and that distinction matters because names, addresses, and contact details rarely stay perfectly identical across operational systems.

For an agent or RAG build, ingestion is the point where you assemble identity. Query time is the point where you fetch the current resolved context. Keeping those jobs separate gives the model a cleaner input and gives engineers a better place to inspect, correct, or explain entity links.

How do you retrieve the resolved entity at query time?

At query time, the application should use the most specific identifier it already has. If the user session, ticket, case, or application state includes a Tilores entity ID, retrieve that entity directly. If it only includes a source record ID, retrieve the entity for that record. If it only includes partial attributes, search the resolved entity layer.

Tilores entity responses can include records, edges, duplicates, hits, and scores. Search responses can include entities, hit details, and hit scores. That does not mean every response should be dumped into the prompt. The application should select the fields the agent needs for the current task.

A good default is to pass the entity ID, the relevant source records, the small set of attributes needed for the action, and any match evidence the agent should expose or log. If the use case is customer support, the context may be contact details and recent accounts. If it is fraud review, it may be linked identifiers and source record lineage. If it is a sales assistant, it may be account rollup and recent interactions.

Where does this sit next to vector retrieval, MDM, CDP, KYC AML, and the warehouse?

Tilores should sit next to the systems that already govern, store, activate, or report on customer data. It is not a replacement for MDM, CDP, KYC AML tooling, or the warehouse. Its role in this stack is to give live applications and AI systems a resolved entity access layer.

Layer	Best job	How the agent should use it
Resolved entity API	Answer which records belong to the same customer, account, household, or business.	Fetch current, compact identity context before the model responds or acts.
Vector retrieval	Find semantically relevant documents, policies, notes, transcripts, or long text.	Fetch supporting passages after the customer entity is known.
MDM, CDP, KYC AML, and warehouse systems	Govern master data, activation, compliance processes, analytics, and reporting.	Remain systems of record or operating systems while the agent uses resolved context for live tasks.
Agent or RAG orchestrator	Choose tools, call retrieval paths, assemble context, and ask the model to reason.	Keep identity lookup and document retrieval as separate steps with logged inputs and outputs.

This is also why vector retrieval alone is not enough for customer identity. The original RAG pattern combines generation with retrieved knowledge, and vector retrieval is useful for finding similar text. It is not designed to assemble a durable customer entity from operational records. For a deeper version of that boundary, see Tilores on why identity resolution belongs beside vector retrieval.

What should the pipeline look like in practice?

The pipeline should make identity resolution an upstream service and make the agent a consumer of resolved context. A practical first version can be built in eight steps.

1. Submit or update source records in the resolved entity layer as systems change.
2. Apply deterministic and probabilistic or fuzzy rules during ingestion.
3. Persist stable entity IDs or source record IDs in the application state.
4. At query time, retrieve the current entity by entity ID, source record ID, or search.
5. Build a field allowlist for the agent task so unnecessary raw records stay out of the prompt.
6. Run document retrieval separately for policies, notes, transcripts, or long text.
7. Pass the compact entity context and selected retrieved passages into the model.
8. Log the entity lookup, retrieval inputs, prompt context, and action result for later review.

If you already have agent framework infrastructure, Tilores has public Python integration documentation and a related integration repository. The important design choice is still the same: the agent calls the identity layer as a tool, then uses retrieved context as evidence for the task.

How do you keep latency under control honestly?

Latency should be budgeted explicitly, not guessed. Treat the entity lookup, document retrieval, model call, and any downstream action as separate steps. Then measure them in your own environment with your own schema, match rules, fields, and agent framework.

The practical controls are straightforward. Retrieve by entity ID when possible. Use source record ID lookup when that is what the application has. Use search only when you start from partial attributes. Limit fields. Keep prompt context compact. Use paging and sorting where a search can return many entities, which the Tilores API reference documents for search responses.

Do not cache a resolved entity summary as if it were permanent. Cache stable identifiers if that helps the application, then retrieve the current entity at query time. That keeps the agent from acting on stale customer context while still avoiding unnecessary identity work inside the model prompt.

What context should go into the model prompt?

The prompt should receive a small, auditable entity packet, not a data dump. A useful packet usually contains the entity ID, selected attributes, the relevant source record IDs, the source system labels the application is allowed to expose, and any match score or edge information the task needs to explain or log.

For RAG, keep two context streams distinct. The resolved entity stream answers who the task is about. The document stream answers what relevant policy, note, contract, or history should be considered. Tilores covers the identity side in its identity resolution for LLMs guide, while this article focuses on the wiring pattern.

This separation makes failures easier to diagnose. If the wrong customer appears, inspect the entity lookup and match evidence. If the right customer appears but the model cites the wrong document, inspect document retrieval. If both are right but the response is wrong, inspect the prompt and action policy.

What can go wrong if identity is left to the model?

If identity is left to the model, the system can produce confident answers from mismatched records. A prompt may include two similar names, two addresses for the same person, one shared phone number, or a business and a consumer account that need to stay separate. The model can reason over those fragments, but it does not give you a durable, inspectable entity graph.

Vector retrieval can add a second failure mode. It may retrieve text that is semantically close to the question but belongs to a different customer or account. That is normal for similarity search. It is not a defect in vector retrieval. It is a sign that identity assembly and text retrieval need separate jobs.

The safer design is to resolve identity before generation, retrieve the current entity at query time, and then let the model work with bounded context. That gives engineers a concrete place to test merges, splits, field selection, and audit logs before the agent is allowed to take higher risk actions.

How should a builder start safely?

Start with one read-only use case where the agent needs customer context but does not write back to a source system. Use representative records, define the fields the agent may see, and log every entity lookup. Review a sample of successful matches, ambiguous matches, and no-match cases before expanding scope.

Then add document retrieval. Keep the entity lookup first, because it narrows the task to the right customer. Run vector retrieval second, because it finds relevant long-form material for that customer or task. The IdentityRAG implementation guide covers the wider retrieval pattern, and the entity resolution API comparison guide helps place the layer beside existing enterprise systems.

When the read-only version behaves well, add guardrails for write actions: allowlisted tools, human review for sensitive decisions, action logs, and clear rollback paths. The goal is not to make the model responsible for identity. The goal is to make the model a careful consumer of resolved identity.

FAQ

Should the AI agent resolve customer identity itself?

No. The agent should receive resolved context from the data layer, not decide whether two customer records are the same person or account from raw fragments.

What is the first lookup an agent should make?

If the application already has an entity ID, use that. If it only has a source record ID, retrieve the entity for that record. If it only has partial customer attributes, search the resolved entity layer.

Where does vector retrieval still help?

Vector retrieval is still useful for semantically relevant documents, notes, policies, and support material. It should sit beside the resolved entity lookup, not replace it.

Does this replace an MDM, CDP, KYC AML system, or warehouse?

No. Tilores should sit next to those systems as a resolved entity access layer for live applications, agents, and RAG systems.

What context should be passed to the model?

Pass a compact summary with the entity ID, selected fields, relevant source records, match evidence when useful, and links back to source systems. Do not pass every raw record by default.

How do deterministic and fuzzy matching fit together?

Use deterministic rules where stable identifiers are available, and use probabilistic or fuzzy matching where names, addresses, emails, and other attributes vary across systems.

How should teams avoid stale entity context?

Cache stable identifiers where useful, but retrieve the current resolved entity at query time before the model responds or takes action.

What is the safest first build?

Start with a read-only agent use case, a narrow field allowlist, logged entity lookups, and a human review sample before allowing write actions.

What is the implementation takeaway?

The cleanest agent and RAG architecture is not a larger prompt. It is a better handoff from the data layer. Resolve customer entities when records arrive, retrieve the current entity when the agent needs context, and keep vector retrieval focused on relevant text. That gives the model less ambiguity and gives the engineering team more control.

For a product-level view of this layer, see the Tilores product overview.