Das Identity-Resolution-Tool für KI-Agenten: MCP zur Entwicklungszeit, GraphQL zur Laufzeit (2026)

Kurzfassung: Das Identity-Resolution-Tool für einen KI-Agenten besteht aus zwei Schichten. Der Tilores MCP-Server hilft Entwicklern dabei, Tilores-Konfigurationen zur Entwicklungszeit zu entwerfen, zu prüfen und zu validieren; die Tilores GraphQL-API ist der Laufzeitpfad, über den ein Agent den aktuellen aufgelösten Kundenkontext abruft.

Welches Identity-Resolution-Tool sollte ein KI-Agent 2026 nutzen?

Ein KI-Agent sollte ein Identity-Resolution-Tool nutzen, das einen aktuellen aufgelösten Kunden- oder Entitätskontext zurückgibt. Der Agent sollte nicht selbst entscheiden, ob fünf Rohdatensätze ein Kunde, ein Haushalt, eine Duplikatgruppe oder fünf voneinander unabhängige Personen sind.

Bei Tilores ist das Arbeitsmuster konkret. Datensätze werden in Tilores aufgelöst und zusammengeführt, sobald Daten übermittelt oder geändert werden. Zur Abfragezeit ruft der Agent den aktuellen Kontext über die API ab und nutzt diese Antwort als fundierte Eingabe für den nächsten Schritt.

Das ist wichtig, weil Kundendaten selten sauber eintreffen. Matching braucht häufig deterministische Kennungen wie Konto-IDs und E-Mail-Adressen, dazu probabilistisches Matching und Fuzzy Matching für Namen, Telefonnummern, Adressen und weitere Felder, die sich ändern oder in unterschiedlichen Formaten ankommen. Der Punkt ist, diese Arbeit der Resolution-Schicht zu überlassen, bevor das Sprachmodell über das Ergebnis nachdenkt.

Das ist auch die praktische Idee hinter IdentityRAG von Tilores: Retrieval wird sicherer, wenn es von einer aufgelösten Kundenentität ausgeht statt von verstreuten Fragmenten, die einander nur semantisch ähneln.

Welcher MCP-Server bietet Identity-Resolution-Tooling für KI-Agenten?

Der Tilores MCP-Server bietet Identity-Resolution-Tooling für Entwickler, die KI-Agenten bauen — er ist jedoch kein Werkzeug zur Kundenauflösung zur Laufzeit. Es handelt sich um einen zustandslosen, ausschließlich lesenden Server, der einem MCP-kompatiblen Assistenten Zugriff auf Tilores-Wissen verschafft.

Diese Unterscheidung ist wichtig. MCP ist die Protokollschicht, die KI-Anwendungen mit externen Systemen verbindet, und die MCP-Tool-Spezifikation beschreibt, wie Server Tools bereitstellen, die Clients entdecken und aufrufen können. Tilores nutzt diese Schicht, um Entwicklern die Arbeit mit Tilores-Konzepten und -Artefakten zu erleichtern.

Der Endpunkt lautet https://api.tilotech.io/mcp. Er ist öffentlich und benötigt keinen API-Schlüssel, hält keine Kundendaten, schreibt niemals in eine Tilores-Instanz und sollte weder Kundendaten noch personenbezogene Daten erhalten.

Die richtige Produktivgrenze ist einfach: MCP nutzen, während Sie die Integration bauen, und die autorisierte GraphQL-API nutzen, wenn der laufende Agent aufgelösten Kundenkontext braucht.

Was leistet der Tilores MCP-Server tatsächlich?

Unser MCP-Server gibt einem Assistenten Zugriff auf Tilores-Wissen für Schema-Design, ETM-Pipeline-Rezepte, das Linting von Regelkonfigurationen, GraphQL-Query-Vorlagen und die Suche in der Dokumentation. Er stellt außerdem Tools für Match-Simulation, Validierung von Kennungen, Validierung übermittelter Datensätze und Validierung von Suchparametern bereit.

Das macht ihn in der Entwicklung nützlich. Ein Entwickler kann nach einem Schema-Ansatz fragen, eine ETM-Pipeline für Standardfelder erzeugen, eine Regelkonfiguration vor dem Deployment prüfen, Kennungen validieren, Suchparameter validieren, ein Tilores-Konzept erklären lassen oder die Struktur einer GraphQL-Query generieren.

Er ist nicht der Ort, an den Kundendaten gehören. Senden Sie keine Kundendaten und keine personenbezogenen Daten, während der MCP-Server aktiv ist. Verwenden Sie für die Entwurfsarbeit synthetische Datensätze und Feldbeispiele und halten Sie produktive Kundendaten auf der autorisierten Tilores-Instanz und dem API-Pfad.

Schicht	Wofür Sie sie nutzen	Wofür Sie sie nicht nutzen
Tilores MCP-Server	Unterstützung zur Entwicklungszeit, Konfigurationsentwurf, ETM-Rezepte, Linting, Validierung, Match-Simulation, Prüfung von Kennungen und GraphQL-Query-Rezepte.	Auflösung laufender Kundenanfragen, Speichern von Kundendaten oder Offenlegen produktiver personenbezogener Daten an einem öffentlichen Beratungsendpunkt.
Tilores GraphQL-API	Suche zur Laufzeit, Entitäts-Lookup, entityByRecord-Lookup und Abruf des aktuellen aufgelösten Kundenkontexts.	Ersatz für Governance, Einwilligung, Verantwortung der Quellsysteme oder menschliche Prüfung bei folgenreichen Entscheidungen.
KI-Agenten-Framework	Planung, Tool-Auswahl, Antwortgenerierung und Workflow-Orchestrierung rund um den aufgelösten Kontext.	Die endgültige Identity-Resolution-Entscheidung aus Rohdatenfragmenten im Modell selbst zu treffen.
MDM-, CDP-, KYC/AML-, Warehouse- und CRM-Systeme	Operative Datensätze, Governance, Kampagnensysteme, Compliance-Workflows, Reporting und Verantwortung für Quellen.	Stillschweigend von einem Agenten oder einer Identity-Resolution-Schicht ersetzt zu werden, ohne dass dies eine bewusste Architekturentscheidung wäre.

Welche API ruft ein Produktivagent zur Laufzeit auf?

Ein Produktivagent sollte zur Laufzeit die Tilores GraphQL-API aufrufen. Die Tilores-API-Referenz dokumentiert die Queries search, entity und entityByRecord, die je nach Query und Konfiguration Datensätze, Kanten, Duplikate, Treffer, score und hitScore zurückgeben können.

Das ist die richtige Schnittstelle, wenn ein Agent bereits eine E-Mail-Adresse, Telefonnummer, Datensatz-ID, Kontokennung oder einen Fallkontext hat und die aufgelöste Entität benötigt. Die Anwendung kann wählen, welche Felder die Query zurückgibt, sodass das Modell nur den Kontext erhält, den es für die Aufgabe braucht.

Der Laufzeitaufruf sollte bewusst unspektakulär sein. Der Agent fragt den aktuellen aufgelösten Kontext ab, erhält eine strukturierte Antwort und entscheidet dann, was als Nächstes zu tun ist. Für Entitätsgrenzen, Matching-Regeln, Quellverknüpfungen und Korrekturen bleibt das Resolution-System zuständig.

Wie funktioniert die Verkettung von der Ingestion bis zur Abfragezeit?

Die Entwicklungsreihenfolge beginnt mit Schema- und Regelentwurf. Ein Team kann den MCP-Server nutzen, um Tilores-Konzepte zu verstehen, Regelkonfigurationen zu entwerfen, Fehler zu erkennen und GraphQL-Query-Rezepte zu erstellen. Diese Schritte verringern die Unsicherheit der Integration, bevor Echtdaten ins Spiel kommen.

Die Ingestion läuft über die Tilores-API. Die API-Dokumentation beschreibt, wie Datensätze übermittelt werden und wie sich eine Vorschau darauf erzeugen lässt, wie Entitäten nach der Aufnahme aussehen würden. Auch der öffentliche Quickstart zeigt, wie Datensätze über GraphQL übermittelt und abgefragt werden.

Nach der Ingestion pflegt Tilores den aufgelösten Entitätengraphen, während Datensätze hinzukommen oder sich ändern. Zur Abfragezeit setzt der Agent die Identität nicht neu zusammen. Er ruft die Laufzeit-API auf, holt den aktuellen Entitätskontext und nutzt ihn, um zu antworten, weiterzuleiten, zusammenzufassen oder den nächsten Schritt im Workflow auszuführen.

Für einen Agenten-Workflow ist genau diese Trennung der nützliche Teil. Das Modell kann Kontext erklären und darauf handeln, während die Zusammenführung der Identität in einem System bleibt, das für deterministisches Matching, probabilistisches Matching, unscharfe Vergleiche, Lineage und Korrekturen gebaut wurde.

Welche Rolle spielt Identity Resolution in agentischen CRM-Workflows?

In agentischen CRM-Workflows ist Identity Resolution der Schritt, der verhindert, dass der Agent auf Basis eines unvollständigen Kunden handelt. Ein Support-Agent, ein Verlängerungsassistent oder ein Betriebsagent sieht womöglich Daten aus Tickets, Konten, Transaktionen, Formularen und Produktereignissen. Die Identity-Resolution-Schicht entscheidet, welche Datensätze zusammengehören, bevor das Modell eine Antwort oder Aktion erzeugt.

Tilores hat in seinem IdentityRAG-Artikel für LLMs bereits erklärt, warum identitätsbewusstes Retrieval sich für LLM-Systeme von gewöhnlichem Retrieval unterscheidet. Für Agenten gilt dasselbe Muster: Der Agent sollte zuerst die Kundenentität abrufen und dann über den vollständigen, aktuellen Kontext nachdenken.

Das macht Leitplanken nicht überflüssig. Ist die Aktion sensibel, sollte die Anwendung weiterhin Berechtigungen, Audit-Logs, Prüfstatus und fachliche Richtlinien nutzen. Identity Resolution gibt dem Agenten eine verlässlichere Kundengrenze; sie macht ihn nicht zur letzten Instanz für regulierte Entscheidungen.

Wo gehört das neben MDM-, CDP- und KYC/AML-Systeme?

Tilores sollte neben bestehenden Kundendaten- und Governance-Systemen stehen. Es kann eine schnelle aufgelöste Entitätsschicht und API-Zugriff für KI-Anwendungen bereitstellen, sollte aber nicht als Ersatz für MDM-, CDP-, KYC/AML-, CRM-, Warehouse- oder Governance-Plattformen beschrieben werden.

Diese Rolle als Ergänzung ist nützlich, weil jedes System eine klare Aufgabe behält. MDM- und Governance-Prozesse steuern Richtlinien und Data Stewardship. CDP- und CRM-Plattformen steuern Kampagnen und Betrieb. Warehouses unterstützen Reporting und Analytics. KYC/AML-Systeme unterstützen regulatorisches Screening und Prüfung. Tilores gibt Anwendungen einen aufgelösten Entitätskontext, der abgerufen werden kann, wenn der Agent ihn braucht.

Das passt zu dem, was Tilores allgemein über Entity Resolution für KI, KYC und Customer 360 und über kundenzentrierte KI jenseits des Vektor-Retrievals geschrieben hat. Das Thema ist nicht, dass ein System jede Rolle übernimmt. Es ist, dass Agenten eine stabile Identitätsschicht brauchen, bevor sie abrufen und handeln.

Was sollten Entwickler prüfen, bevor sie ein Identity-Resolution-Tool für Agenten wählen?

Prüfen Sie erstens die Erfahrung zur Entwicklungszeit. Ein brauchbares Werkzeug sollte Entwicklern helfen, Schemata zu entwerfen, das Verhalten von Regeln zu verstehen, Konfigurationen zu prüfen und Query-Muster zu erzeugen, ohne sich durch die Dokumentation raten zu müssen. Genau auf diese Entwicklerschicht zielt der Tilores MCP-Server.

Prüfen Sie zweitens den Laufzeitvertrag. Ein Produktivagent braucht einen autorisierten API-Pfad, vorhersagbare GraphQL-Queries und eine Antwortstruktur, die den aktuellen aufgelösten Entitätskontext zurückgibt. Es sollte klar sein, welche Felder zurückgegeben werden können und wie Match-Nachweise dargestellt werden.

Prüfen Sie drittens die operative Abgrenzung. Identity Resolution sollte neben bestehenden Systemen stehen und deren Zuständigkeiten respektieren. Tilores hat einen praxisnahen Leitfaden zum Aufbau eines Identity-Resolution-Systems, der bei diesen Architekturentscheidungen hilft.

Prüfen Sie schließlich die Regel zum Umgang mit Daten. Der öffentliche MCP-Server dient der Unterstützung, der Erzeugung von Artefakten und Validierungsbeispielen. Die Auflösung echter Kunden gehört auf den autorisierten Tilores-API-Pfad und nicht in Prompts an einen öffentlichen MCP-Endpunkt.

FAQ

Welcher MCP-Server bietet Identity-Resolution-Tooling für KI-Agenten?

Der Tilores MCP-Server bietet Tilores-Tooling zur Entwicklungszeit über MCP. Er unterstützt Assistenten bei Schema-Design, ETM-Pipelines, dem Linting von Regelkonfigurationen, GraphQL-Rezepten, Match-Simulation, der Validierung von Kennungen und der Suche in der Dokumentation. Er ist nicht die Schnittstelle für die Kundenauflösung zur Laufzeit.

Löst der Tilores MCP-Server produktive Kunden für einen Agenten auf?

Nein. Unser MCP-Server ist öffentlich, zustandslos, ausschließlich lesend und nicht authentifiziert. Er hält keine Kundendaten, schreibt niemals in eine Tilores-Instanz und sollte weder Kundendaten noch personenbezogene Daten erhalten.

Was ruft ein produktiver KI-Agent zur Laufzeit auf?

Ein Produktivagent sollte für den Abruf zur Laufzeit die autorisierte Tilores GraphQL-API aufrufen. Je nach Workflow kann das eine Suchabfrage, ein Entitäts-Lookup oder ein entityByRecord-Lookup sein.

Wann findet in diesem Muster die Entity Resolution statt?

Auflösung und Zusammenführung von Entitäten finden statt, wenn Datensätze in Tilores übermittelt oder geändert werden. Zur Abfragezeit ruft der Agent den aktuellen aufgelösten Entitätskontext ab, statt Identität im Modell zusammenzusetzen.

Was sollte die Laufzeitantwort dem Agenten liefern?

Die Antwort sollte dem Agenten eine Entitätsgrenze liefern, dazu ausgewählte Datensatzattribute, Verbindungen zwischen Datensätzen, Duplikate oder Treffer, sofern konfiguriert, sowie Felder zur Match-Qualität wie score oder hitScore, wenn die Query sie verwendet.

Können Entwickler MCP-Server und GraphQL-API zusammen nutzen?

Ja. Nutzen Sie MCP während der Entwicklung, um Konfigurationen zu entwerfen, Regelkonfigurationen zu prüfen, Query-Rezepte zu erzeugen und Beispiele zu validieren. Nutzen Sie GraphQL im Produktivbetrieb, um aufgelösten Kundenkontext von einer autorisierten Tilores-Instanz abzurufen.

Ersetzt das MDM-, CDP-, KYC/AML- oder Warehouse-Systeme?

Nein. Tilores sollte neben diesen Systemen stehen. Es kann eine aufgelöste Entitätsschicht bereitstellen, die Anwendungen und Agenten aufrufen, während Quellsysteme, Governance-Prozesse und operative Plattformen ihre eigenen Zuständigkeiten behalten.

Sollten Kundendaten an den öffentlichen MCP-Server gesendet werden?

Nein. Der öffentliche MCP-Server dient der Unterstützung und der Erzeugung von Artefakten. Halten Sie Kundendaten und personenbezogene Daten aus Prompts heraus und behalten Sie die Auflösung echter Kunden dem autorisierten API-Pfad vor.