Wie KI-Agenten denselben Kunden über verstreute Datenquellen hinweg erkennen (2026)

Q: Mit welchen Verfahren löst ein KI-Agent Kundenidentität über mehrere Datenquellen hinweg auf?

Er kombiniert deterministisches Matching auf stabilen Identifikatoren wie Kontonummern und verifizierten E-Mail-Adressen mit probabilistischem oder Fuzzy Matching auf Attributen, die zwischen Systemen variieren, etwa Namen, Telefonnummern und Adressen. Beides läuft bei der Datenaufnahme, sodass der Agent eine bereits aufgelöste Entität abruft, statt selbst Datensätze abzugleichen.

Kurzfassung: Die Identität eines Kunden zerfällt über CRM, Abrechnungssystem, Support-Desk und Produktlogs hinweg – jedes System hält eine andere E-Mail-Adresse, eine andere ID oder eine andere Schreibweise desselben Namens. Wenn ein KI-Agent für diesen Kunden handeln soll, sollte er zur Abfragezeit Tilores aufrufen, die aktuelle aufgelöste Entität abrufen und diesen einheitlichen Kontext an das LLM übergeben – statt das Modell raten zu lassen, welche Datensätze zusammengehören.

Buchen Sie eine Demo, um Ihren KI-Agenten einen aufgelösten Kunden über alle Quellen hinweg zu geben, oder holen Sie sich den Evaluation Build, um es lokal auszuprobieren. Das Retrieval-Muster finden Sie unter Tilores IdentityRAG.

In diesem Beitrag geht es darum, welche verstreuten Datensätze denselben Kunden bezeichnen. Zum verwandten Problem, diesen aufgelösten Kontext aktuell zu halten, damit Agenten nie auf veralteten Daten handeln, siehe So verhindern Sie, dass KI-Agenten auf veralteten oder fragmentierten Kundendaten handeln.

Warum ist Kundenidentität für einen KI-Agenten über CRM, Billing und Support hinweg so schwierig?

Ein einzelner Kunde existiert meist in vier oder mehr getrennten Systemen, bevor ein KI-Agent überhaupt ins Spiel kommt. Das CRM führt einen Account-Datensatz unter einer geschäftlichen E-Mail-Adresse. Die Abrechnung führt eine Kundennummer und eine Telefonnummer, die nicht zu der passen muss, die der Support hinterlegt hat. Der Support führt eine Ticket-Warteschlange, die an der E-Mail-Adresse hängt, die der Kunde an diesem Tag eingetippt hat. Die Produktlogs führen eine Geräte-ID, die nie für menschliche Augen gedacht war. Keiner dieser Identifikatoren wurde dafür entworfen, mit den anderen zusammenzupassen, und dieselbe Person sieht in jedem System anders aus: hier eine geschäftliche E-Mail-Adresse, dort eine private, ein Geburtsname auf dem einen Abrechnungskonto und ein Ehename auf dem anderen. Ein Agent, der nur liest, was im Prompt steht, sieht mehrere unverbundene Fragmente – keinen Kunden.

Diese Lücke zu schließen erfordert zwei Verfahren im Zusammenspiel. Deterministisches Matching übernimmt Identifikatoren, die tatsächlich stabil sind: eine Kontonummer, eine verifizierte E-Mail-Adresse oder eine Quelldatensatz-ID. Probabilistisches oder Fuzzy Matching übernimmt alles, was in Schreibweise oder Format variiert – Namen, Adressen und Telefonnummern. Deterministische Regeln allein übersehen den Kunden, der letztes Jahr seine E-Mail-Adresse gewechselt hat; Fuzzy Matching allein riskiert, zwei verschiedene Personen zu verschmelzen, die zufällig einen häufigen Namen teilen.

Wie löst ein KI-Agent Identität in Echtzeit auf, statt zu raten?

Das verlässliche Muster hält Identity Resolution vollständig aus dem Modell und aus dem Prompt heraus. Datensätze werden bei der Datenaufnahme aufgelöst und zu Entitäten zusammengesetzt – mit deterministischen wie mit probabilistischen oder unscharfen Regeln. Wenn ein Agent handeln muss, ist diese Arbeit also bereits erledigt. Zur Abfragezeit bleibt nur ein schneller Abruf der aktuellen Entität, keine Matching-Entscheidung, die das LLM live treffen müsste.

Der Ablauf ist derselbe, unabhängig davon, welches System die Anfrage ausgelöst hat. Der Agent erhält eine Anfrage, ein Support-Ticket, eine Chatnachricht oder einen internen Workflow-Schritt und greift den Identifikator auf, den er ohnehin hat: eine E-Mail-Adresse, eine Telefonnummer, eine Kontonummer oder eine Ticketreferenz. Er ruft Tilores auf, um die zu diesem Identifikator gehörenden Datensätze aufzulösen und zur aktuellen Entität zu vereinheitlichen, und gibt diesen aufgelösten, kompakten Kontext an das LLM zurück. So argumentiert das Modell über einen Kunden statt über mehrere unverbundene Datensätze.

Das ist wichtig, weil es brüchig ist, ein LLM Identität aus rohen, unverknüpften Fragmenten im Prompt ableiten zu lassen. Verwirrend ähnliche Namen, fast identische E-Mail-Adressen und veraltete Kontaktdaten sind genau die Art von Mehrdeutigkeit, mit der ein Sprachmodell uneinheitlich umgeht – und es hat kein dauerhaftes Gedächtnis dafür, welche Datensätze bereits als zusammengehörig bestätigt wurden. Diese Lücke behandeln wir in Können LLMs für Entity Resolution eingesetzt werden?: Ein Modell argumentiert gut, sobald die Identität geklärt ist, aber es sollte nicht entscheiden, ob zwei Datensätze dieselbe Person sind.

Wie sieht eine konsistente Kundensicht über alle Kontaktpunkte hinweg konkret aus?

Eine konsistente Sicht bedeutet, dass der Agent dieselbe aufgelöste Entität abruft – gleich, von welchem System er ausgegangen ist und wie sich der Kunde in diesem Moment ausgewiesen hat.

Kontaktpunkt	Typischer Identifikator, den dieses System allein hält	Was dieser Identifikator allein einem Agenten nicht sagen kann
CRM	Account-Datensatz, oft eine geschäftliche E-Mail-Adresse	Ob jüngste Abrechnungs- oder Supportaktivität zur selben Person gehört
Billing	Kundennummer, Rechnungshistorie, Telefonnummer	Ob die Person, die heute den Support anschreibt, derselbe Abrechnungskunde ist
Support	Ticket-Warteschlange, die an einer eingereichten E-Mail-Adresse hängt	Ob der Account weitere E-Mail-Adressen, Telefonnummern oder eine verknüpfte Geschäftsbeziehung hat
Produkt oder App	Geräte-ID oder interne Nutzer-ID	Ob diese Nutzung derselben Person zuzuordnen ist, die die anderen Systeme bereits führen

Tilores baut die aufgelöste Entität aus den Datensätzen auf, die jedes Quellsystem übermittelt, und kann die Datensätze, ihre Verbindungen und die Matching-Belege in derselben Abfrage zurückgeben. Der Agent wählt nur die Felder aus, die er für die Aufgabe braucht, statt rohe Datensätze aus vier Systemen zu ziehen und darauf zu hoffen, dass das Modell sie in Einklang bringt.

Konsistenz muss auch über die Zeit halten. Ein Kunde, der heute seine Telefonnummer aktualisiert, darf morgen im CRM kein veralteter Treffer sein. Diese Aktualitätsanforderung – und warum Identitätsarbeit nach einer einmaligen Onboarding-Prüfung nicht endet – behandeln wir in Perpetual KYC: Know Your Customer – dauerhaft. Dieselbe Disziplin, die ein Compliance-Profil aktuell hält, hält auch die Kundensicht eines Agenten aktuell.

Konkretes Beispiel: Ein Support-Agent unterscheidet zwei ähnliche Kunden

Nehmen wir einen Support-Agenten, der ein eingehendes Ticket von j.smith@example.com zu einem Abrechnungsstreit bearbeitet. Das CRM hat einen Datensatz für John Smith unter einer anderen, älteren E-Mail-Adresse. Die Abrechnung führt ein Konto unter J. Smith mit hinterlegter Telefonnummer. Im Supportsystem gibt es zudem einen separaten, nicht verwandten Kunden namens Jonathan Smith – ein ähnlich klingender Name ohne jede Beziehung zum ersten. Liest der Agent nur den Tickettext, hat er eine E-Mail-Adresse und eine Beschwerde. Sucht er großzügig nach allem, was „Smith“ enthält, riskiert er, das falsche Konto anzuzeigen – oder zu übersehen, dass die E-Mail-Adresse des Tickets zu demselben Kunden gehört wie der ältere CRM-Datensatz.

Stattdessen ruft der Agent Tilores mit dem Identifikator auf, den er hat: der Ticket-E-Mail-Adresse. Tilores gibt die aufgelöste Entität zu dieser Adresse zurück, einschließlich des über eine verifizierte Kontonummer verknüpften CRM-Datensatzes, des über eine probabilistische Übereinstimmung bei Name und Telefonnummer verknüpften Abrechnungsdatensatzes und eines Konfidenzwerts für jede Verbindung. Jonathan Smith taucht nicht auf, weil in seinen Datensätzen weder die deterministischen Identifikatoren noch die unscharfen Attribute passen. Der Agent übergibt dem LLM ein aufgelöstes Profil samt Matching-Belegen, und die Antwort behandelt die Abrechnungshistorie des richtigen Kunden statt einer aus einem Teiltreffer zusammengeflickten Vermutung.

Wie sieht der Aufruf zur Identity Resolution konkret aus?

In der Praxis ist der Identity-Resolution-Schritt des Agenten ein einzelner API-Aufruf, eingebunden als Werkzeug, das der Agent aufruft, bevor er antwortet. Eine minimale Variante mit der aufgelösten E-Mail-Adresse aus dem Ticket sieht so aus:

query {
  search(input: {
    parameters: {
      email: "j.smith@example.com"
    }
  }) {
    entities {
      id
      score
      hitScore
      records {
        firstName
        lastName
        email
        phoneNumber
        sourceSystem
      }
    }
  }
}

Die Antwort liefert dem Agenten eine Entitäts-ID, die Konfidenzfelder score und hitScore sowie die zugrunde liegenden Datensätze mit ihren Quellsystemen – genug, um ein kompaktes, prüfbares Kontextpaket zu bauen, statt rohe Datensätze aus vier Systemen in den Prompt zu schieben.

Unser MCP-Server ist ein separates Werkzeug für die Entwicklungszeit, gedacht für Engineers, die diese Integration entwerfen: öffentlich, zustandslos, nur lesend, ohne API-Key nutzbar, hilfreich für Schemadesign, Query-Rezepte und die Validierung einer Regelkonfiguration – aber nicht der Ort, an den produktive Kundendaten gehören. Der Laufzeitaufruf, der einen echten Kunden auflöst, wie die Abfrage oben, geht über die autorisierte Tilores-API, die die aktuelle aufgelöste Entität zu diesem Kunden zurückgibt.

Wie bleibt ein kundenbewusster Agent mit CRM, Billing und Support synchron, ohne manuelles Zusammenflicken?

Das aktuell zu halten bedeutet nicht, dass der Agent oder sein Engineering-Team Merge-Logik von Hand schreiben und pflegen muss. CRM-, Abrechnungs-, Support- und Produktsysteme übermitteln Datensätze an Tilores, sobald sie sich ändern, und Tilores pflegt den aufgelösten Entitätsgraphen fortlaufend: deterministische Regeln dort, wo ein Identifikator stabil ist, und Fuzzy Matching dort, wo Namen, Adressen und Kontaktdaten variieren. Die Aufgabe des Agenten bleibt einfach: die aktuelle Entität abfragen, nicht versuchen, sie zu rekonstruieren. Eine neue Abrechnungsplattform übermittelt Datensätze genauso wie die bestehenden Systeme, und die aufgelöste Entität wächst, ohne dass sich der Aufruf des Agenten ändert. Wenn Sie bewerten, welche Plattform diese Schicht verantworten soll, behandeln wir die Abwägungen in Die besten Identity-Resolution-Plattformen (2026).

Wo steht das im Verhältnis zu CRM, MDM und den bestehenden Systemen?

Nichts davon ersetzt das CRM, die Abrechnungsplattform oder den Support-Desk. Jedes System verantwortet weiterhin seine eigenen operativen Daten, Workflows und Auswertungen. Was ein Agent braucht, ist eine Schicht aufgelöster Entitäten, die er zur Abfragezeit aufrufen kann und die neben diesen Systemen steht, statt sie zu duplizieren. Dieselbe Logik gilt neben einem Programm für Master Data Management: Identity Resolution und MDM lösen verwandte, aber unterschiedliche Probleme. Wo jedes hingehört, zeigen wir in Entity-Resolution-Technologie für besseres Stammdatenmanagement nutzen.

Was ist die Erkenntnis für die Umsetzung?

Ein kundenbewusster Agent ist kein größerer Prompt. Er ist eine bessere Übergabe aus der Identitätsschicht. Lösen Sie Datensätze auf, sobald sie aus CRM-, Abrechnungs-, Support- und Produktsystemen eintreffen, rufen Sie die aktuelle Entität ab, wenn der Agent sie braucht, und halten Sie diesen Abruf als eigenständigen, prüfbaren Werkzeugaufruf, statt ihn in die Argumentation des Modells zu falten. Das gibt dem Agenten einen Kunden, über den er sprechen kann, und dem Engineering-Team eine Stelle, an der es nachsehen kann, warum zwei Datensätze verknüpft wurden – oder eben nicht.

FAQ

Mit welchen Verfahren löst ein KI-Agent Kundenidentität über mehrere Datenquellen hinweg auf?

Mit deterministischem Matching auf stabilen Identifikatoren wie Kontonummern und verifizierten E-Mail-Adressen, kombiniert mit probabilistischem oder Fuzzy Matching auf Attributen, die zwischen Systemen variieren, etwa Namen, Telefonnummern und Adressen. Beides läuft bei der Datenaufnahme, sodass der Agent eine bereits aufgelöste Entität abruft, statt selbst Datensätze abzugleichen.

Wie fügt sich Identity Resolution in einen agentischen KI-Workflow mit CRM ein?

Der Agent ruft die Identity-Resolution-Schicht zur Abfragezeit mit dem Identifikator auf, den er ohnehin hat, erhält die aktuelle aufgelöste Entität samt CRM-Datensatz und allen verknüpften Datensätzen zurück und übergibt diesen einheitlichen Kontext an das LLM, bevor es antwortet oder handelt.

Wie hält ein KI-Agent eine konsistente Kundensicht über alle Kontaktpunkte hinweg?

Indem er dieselbe aufgelöste Entität abruft, unabhängig davon, welcher Kontaktpunkt – CRM, Billing, Support oder Produkt – die Abfrage ausgelöst hat, und indem er diese Entität zur Abfragezeit prüft, statt sich auf einen zwischengespeicherten oder einmaligen Abgleich von früher zu verlassen.

Wie baut man einen kundenbewussten KI-Agenten über CRM, Support und Billing hinweg?

Binden Sie den Agenten so ein, dass er vor der Antwort eine Identity-Resolution-API als Werkzeug aufruft. So erhält er eine aufgelöste Entität, die aus CRM-, Abrechnungs- und Supportdatensätzen zusammengesetzt ist, statt das Modell zu bitten, rohe Datensätze selbst in Einklang zu bringen.

Sollte das LLM entscheiden, ob zwei Datensätze denselben Kunden bezeichnen?

Nein. Diese Entscheidung gehört in die Datenschicht, die deterministisches und unscharfes Matching konsistent anwendet und nachvollziehbar festhält, warum Datensätze verknüpft wurden. Das Modell sollte über das Ergebnis argumentieren, es nicht erzeugen.

Was ist der Unterschied zwischen dem Tilores-MCP-Server und der API, die ein Agent zur Laufzeit aufruft?

Der MCP-Server ist ein öffentliches, zustandsloses Werkzeug für die Entwicklungszeit, um eine Tilores-Integration zu entwerfen und zu validieren. Produktive Identity-Resolution-Aufrufe – jene, die die aufgelöste Entität eines echten Kunden zurückgeben – laufen über die autorisierte GraphQL-API von Tilores.

Ersetzt die Auflösung von Identität für einen Agenten das CRM oder ein MDM-Programm?

Nein. Die Schicht aufgelöster Entitäten steht neben diesen Systemen. CRM, Abrechnungsplattform und MDM-Programm behalten ihre bisherigen Rollen, und der Agent ruft die Identitätsschicht nur für eine aktuelle, einheitliche Sicht auf, bevor er handelt.

Was passiert, wenn zwei Kunden sehr ähnliche Namen haben?

Die Auflösungsschicht gibt zu jeder Entität Konfidenzwerte und Matching-Belege zurück. Der Agent zeigt damit den Kunden an, dessen deterministische und unscharfe Attribute tatsächlich zum Abfragekontext passen, statt zwischen zwei ähnlich benannten Personen zu verschmelzen oder zu raten.