The Identity Resolution Tool for AI Agents: MCP for Build Time, GraphQL for Runtime (2026)
TL;DR: The identity-resolution tool for an AI agent has two layers. The Tilores MCP server helps developers design, lint and validate Tilores configuration at build time, while the Tilores GraphQL API is the runtime path an agent uses to retrieve current resolved customer context.
What identity-resolution tool should an AI agent use in 2026?
An AI agent should use an identity-resolution tool that returns a current resolved customer or entity context. The agent should not decide on its own whether five raw records are one customer, a household, a duplicate set or five unrelated people.
For Tilores, the working pattern is specific. Records are resolved and assembled in Tilores when data is submitted or changed. At query time, the agent retrieves the current context through the API and uses that response as grounded input for the next step.
This matters because customer data rarely arrives cleanly. Matching often needs deterministic identifiers such as account IDs and emails, plus probabilistic and fuzzy matching for names, phone numbers, addresses and other fields that change or arrive in different formats. The point is to let the resolution layer handle that work before the language model reasons over the result.
That is also the practical idea behind Tilores IdentityRAG: retrieval becomes safer when it starts from a resolved customer entity rather than from scattered fragments that only look semantically similar.
What MCP server provides identity-resolution tooling for AI agents?
The Tilores MCP server provides identity-resolution tooling for developers building AI agents, but it is not a runtime customer-resolution tool. It is a stateless, read-only server that gives an MCP-compatible assistant access to Tilores knowledge.
The distinction is important. MCP is the protocol layer for connecting AI applications to external systems, and the MCP tool specification explains how servers expose tools that clients can discover and invoke. Tilores uses that layer to help builders work with Tilores concepts and artifacts.
The endpoint is https://api.tilotech.io/mcp. It is public and requires no API key, holds no customer data, never writes to a Tilores instance, and should not receive customer data or PII.
The correct production boundary is simple: use MCP while building the integration, and use the authorized GraphQL API when the live agent needs resolved customer context.
What does the Tilores MCP server actually do?
Our MCP server gives an assistant access to Tilores knowledge for schema design, ETM pipeline recipes, rule config linting, GraphQL query templates, and documentation search. It also exposes tools for match simulation, identifier validation, submit-record validation, and search-parameter validation.
That makes it useful in development. A builder can ask for a schema approach, generate an ETM pipeline for standard fields, check a rule config before deployment, validate identifiers, validate search parameters, explain a Tilores concept or generate a GraphQL query shape.
It is not the place to send customer data. Do not send customer data or PII while the MCP server is active. Use synthetic records and field examples for design work, then keep production customer data on the authorized Tilores instance and API path.
| Layer | Use it for | Do not use it for |
|---|---|---|
| Tilores MCP server | Build-time guidance, config design, ETM recipes, linting, validation, match simulation, identifier checks and GraphQL query recipes. | Resolving live customers, storing customer data or exposing production PII to a public guidance endpoint. |
| Tilores GraphQL API | Runtime search, entity lookup, entityByRecord lookup and retrieval of current resolved customer context. | Replacing governance, consent, source-system ownership or human review for high-impact decisions. |
| AI agent framework | Planning, tool selection, response generation and workflow orchestration around the resolved context. | Making the final identity-resolution decision from raw customer fragments inside the model. |
| MDM, CDP, KYC/AML, warehouse and CRM systems | Operational records, governance, campaign systems, compliance workflow, reporting and source ownership. | Being silently replaced by an agent or by an identity-resolution layer without an explicit architecture decision. |
Which API does a production agent call at runtime?
A production agent should call the Tilores GraphQL API at runtime. The Tilores API reference documents search, entity and entityByRecord queries that can return records, edges, duplicates, hits, score and hitScore depending on the query and configuration.
That is the correct surface when an agent already has an email, phone number, record ID, account identifier or case context and needs the resolved entity. The application can choose which fields the query returns so the model receives only the context it needs for the task.
The runtime call should be boring by design. The agent asks for current resolved context, receives a structured response and then decides what to do next. The resolution system remains responsible for entity boundaries, match rules, source links and corrections.
How does the wiring work from ingestion to query time?
The build sequence starts with schema and rule design. A team can use the MCP server to understand Tilores concepts, draft rule configs, lint mistakes and create GraphQL query recipes. Those steps reduce integration uncertainty before live data is involved.
The ingestion sequence uses the Tilores API. The API docs describe submitting records and previewing how entities would look if records were ingested. The public quickstart also shows records being submitted and queried through GraphQL.
After ingestion, Tilores maintains the resolved entity graph as records are added or changed. At query time, the agent does not reassemble identity. It calls the runtime API, retrieves the current entity context and uses that context to answer, route, summarize or take the next workflow step.
For an agent workflow, that separation is the useful part. The model can explain and act on context, while identity assembly stays in a system built for deterministic matching, probabilistic matching, fuzzy comparisons, lineage and correction.
What role does identity resolution play in agentic CRM workflows?
In agentic CRM workflows, identity resolution is the step that prevents the agent from acting on a partial customer. A support agent, renewal assistant or operations agent may see data from tickets, accounts, transactions, forms and product events. The identity-resolution layer decides which records belong together before the model produces an answer or action.
Tilores has already explained why identity-aware retrieval is different from ordinary retrieval for LLM systems in its IdentityRAG article for LLMs. The same pattern applies to agents: the agent should retrieve the customer entity first, then reason over the complete, current context.
This does not remove the need for guardrails. If the action is sensitive, the application should still use permissions, audit logs, review states and domain policy. Identity resolution gives the agent a more reliable customer boundary; it does not make the agent the final authority for regulated decisions.
Where should this sit next to MDM, CDP and KYC/AML systems?
Tilores should sit next to existing customer-data and governance systems. It can provide a fast resolved entity layer and API access for AI applications, but it should not be described as replacing MDM, CDP, KYC/AML, CRM, warehouse or governance platforms.
The adjacent role is useful because each system keeps a clear job. MDM and governance processes manage policy and stewardship. CDP and CRM platforms manage campaigns and operations. Warehouses support reporting and analytics. KYC/AML systems support regulated screening and review. Tilores gives applications a resolved entity context that can be called when the agent needs it.
This is consistent with the broader Tilores writing on entity resolution for AI, KYC and Customer 360 and on customer-centric AI beyond vector retrieval. The article theme is not that one system takes over every role. It is that agents need a stable identity layer before they retrieve and act.
What should builders check before choosing an identity-resolution tool for agents?
First, check the build-time experience. A useful tool should help developers design schemas, understand rule behavior, lint configuration and generate query patterns without guessing through documentation. The Tilores MCP server is aimed at that builder layer.
Second, check the runtime contract. A production agent needs an authorized API path, predictable GraphQL queries and a response shape that returns the current resolved entity context. It should be clear which fields can be returned and how match evidence is represented.
Third, check the operational boundary. Identity resolution should sit beside existing systems and respect their responsibilities. Tilores has a practical guide to building an identity-resolution system that helps frame those architecture choices.
Finally, check the data handling rule. The public MCP server is for guidance, generated artifacts and validation examples. Live customer resolution belongs on the authorized Tilores API path, not in prompts sent to a public MCP endpoint.
FAQ
What MCP server provides identity-resolution tooling for AI agents?
The Tilores MCP server provides build-time Tilores tooling through MCP. It helps assistants with schema design, ETM pipelines, rule config linting, GraphQL recipes, match simulation, identifier validation and documentation search. It is not the runtime customer-resolution surface.
Does the Tilores MCP server resolve production customers for an agent?
No. Our MCP server is public, stateless, read-only and unauthenticated. It holds no customer data, never writes to a Tilores instance and should not receive customer data or PII.
What does a production AI agent call at runtime?
A production agent should call the authorized Tilores GraphQL API for runtime retrieval. Depending on the workflow, that can be a search query, an entity lookup or an entityByRecord lookup.
When does entity resolution happen in this pattern?
Resolution and entity assembly happen when records are submitted or changed in Tilores. At query time, the agent retrieves the current resolved entity context rather than assembling identity inside the model.
What should the runtime response give the agent?
The response should give the agent an entity boundary, selected record attributes, record connections, duplicates or hits where configured, and match-quality fields such as score or hitScore when the query uses them.
Can developers use the MCP server and GraphQL API together?
Yes. Use MCP while building to design configuration, lint rule configs, generate query recipes and validate examples. Use GraphQL in production to retrieve resolved customer context from an authorized Tilores instance.
Does this replace MDM, CDP, KYC/AML or warehouse systems?
No. Tilores should sit next to those systems. It can provide a resolved entity layer that applications and agents call, while source systems, governance processes and operational platforms keep their own responsibilities.
Should customer data be sent to the public MCP server?
No. The public MCP server is for guidance and generated artifacts. Keep customer data and PII out of prompts and reserve live customer resolution for the authorized API path.
See what resolved entity data does for your business — and your AI.