Eines unserer aktuellen Projekte ist eine Studentenplattform für Auslandsstudienprogramme. Der Kunde hatte bereits solide Vorarbeit geleistet: ein trainiertes ML-Modell, einen sauberen Datensatz, einen Chatbot, der Nutzerfragen korrekt beantwortete. Nach den meisten Maßstäben war das technische Fundament tragfähig.
Doch das Produkt verhielt sich nicht wie ein Gespräch. Ein Nutzer schrieb etwas – „Ich möchte im Ausland studieren, mein Budget liegt bei etwa 5.000 bis 10.000 €“ – und der Bot antwortete korrekt und wartete dann. Keine Rückfrage. Keine Klärung. Kein Angebot, beim nächsten Schritt zu helfen. Jeder Austausch fing von vorn an. Das Modell antwortete, aber es hörte nicht zu.
Genau dieses Problem sollten wir lösen. Und im Zentrum stand die Architekturentscheidung, ob MCP eingesetzt werden sollte.
Was MCP ist und warum es hier wichtig ist
MCP – das Model Context Protocol – ist ein Kommunikationsstandard, der es einem KI-Modell erlaubt, direkt mit Backend-Systemen zu sprechen: Datenbanken, APIs, Anwendungslogik. Anthropic hat ihn Ende 2024 eingeführt, und er ist seither zu einer der wichtigeren Infrastrukturentscheidungen für Teams geworden, die KI-gestützte Produkte entwickeln.
Die Alternative – die bei den meisten frühen KI-Integrationen zum Einsatz kommt – läuft über Zwischenschichten: Das Modell schickt eine Anfrage, eine API-Schicht fragt die Datenbank ab, das Ergebnis wandert durch dieselben Schichten zurück, und erst dann erhält das Modell es. Jede Schicht erhöht die Latenz. Jede Schicht ist eine mögliche Fehlerquelle. Jede Schicht schränkt ein, auf welchen Kontext das Modell in Echtzeit zugreifen kann.
MCP beseitigt diese Zwischenschichten. Das Modell verbindet sich direkt. Das Ergebnis sind schnellere Antworten – wichtiger aber: Es verändert, was das Gespräch leisten kann, denn das Modell hat nun Live-Zugriff auf die Daten, die es braucht, um wirklich nützlich zu sein und nicht nur technisch korrekt.
Der Unterschied zählt am meisten bei Produkten, bei denen die Qualität der Konversation das Produkt ist. Ein Chatbot, der korrekt antwortet, aber keinen Kontext halten, keine Rückfragen stellen und nicht auf sein Wissen hin handeln kann, ist kein Konversationsprodukt. Er ist eine Suchoberfläche mit freundlicherer Verpackung.
Was der Kunde brauchte – und was das technisch bedeutete
Das Ziel des Kunden war konkret: ein Bot, der sich verhält wie ein kompetenter menschlicher Berater. Erwähnt ein Nutzer sein Budget, merkt sich der Bot es. Fragt der Nutzer mitten in einem Gespräch über Kursoptionen nach Visabestimmungen, behandelt der Bot das, ohne den roten Faden zu verlieren. Kann der Bot beim nächsten Schritt helfen – Kurse vormerken, einen Rückruf buchen, einen Vergleich senden –, bietet er es an.
Ein solches Verhalten erfordert das Zusammenspiel von drei Dingen: Das Modell muss den Kontext über eine Sitzung hinweg behalten, es braucht Zugriff auf Live-Produktdaten, und es muss Aktionen im Backend auslösen können.
Darüber haben wir mit Anastasiya, unserer PM im Projekt, gesprochen, um zu verstehen, woher die Architekturentscheidung tatsächlich kam – und warum sich das Problem nicht auf Modellebene lösen ließ.
Anastasiya — PM
Das Modell selbst war nicht das Problem. Das Problem war, wie es mit allem anderen verbunden war. Alle Daten – Kursangebot, Preise, Verfügbarkeit – lagen in der Datenbank, aber das Modell konnte nicht in Echtzeit darauf zugreifen. Es antwortete auf Basis dessen, womit es trainiert worden war, nicht auf Basis dessen, was gerade tatsächlich galt. Und es konnte keine Aktionen ausführen. Es konnte Ihnen sagen, dass es einen Kurs gibt, aber Ihnen nicht helfen, etwas damit zu tun. Der von uns gebaute POC zeigte, dass ein MCP-Server diese Lücke sofort schließen konnte: Das direkt mit dem Backend verbundene Modell konnte mitten im Gespräch Live-Daten abrufen, den Sitzungskontext halten und Backend-Aktionen auslösen – ohne die Latenz zwischengeschalteter Schichten.
Wer eine solche Integration leiten sollte – und warum
Diese Frage hören wir in unterschiedlicher Form bei fast jedem KI-Integrationsprojekt: Braucht man dafür einen KI/ML-Spezialisten?
Bei einer MCP-Integration lautet die Antwort Nein – und warum das so ist, ist wichtig für die Planung und das Budget dieser Arbeit.
MCP ist keine Modellentwicklung. Sie trainieren, feintunen oder verändern das Modell selbst nicht. Sie bauen die Verbindungsschicht zwischen einem bestehenden Modell und Ihren bestehenden Systemen. Das Schwierigste ist nicht, das Modell anzubinden – sondern präzise festzulegen, worauf das Modell in einer echten Produktionsumgebung sicher und stabil zugreifen darf. Dafür braucht es jemanden, der Ihr Backend gründlich kennt, nicht jemanden, der Modelle gründlich kennt.
Anastasiya — PM
Vlad ist unser Backend-Entwickler in diesem Projekt. Vlad arbeitet von Anfang an in dieser Codebasis. Er kennt das Backend, er kennt die Produktlogik, er versteht, wie die Daten strukturiert sind und wo die Grenzfälle liegen. Dieser Kontext ist hier mehr wert als KI-spezifische Qualifikationen. Jemand von außen bräuchte selbst mit starker ML-Erfahrung Monate, um dorthin zu kommen, wo er bereits ist. Die Integration muss exakt zum bestehenden System passen – und diese Präzision kommt aus dem Produktwissen, nicht aus dem Modellwissen.
Für Teams, die ähnliche Vorhaben planen, hat das eine praktische Konsequenz: Die richtige Person für eine MCP-Integration ist wahrscheinlich schon in Ihrem Team.
Die technischen Details, auf die es wirklich ankommt
Die MCP-Integration zum Laufen zu bringen, ist der Anfang, nicht das Ende. Ob sie in der Produktion trägt, hängt von vier Dingen ab, die in den meisten Beiträgen zu diesem Thema zu selten besprochen werden.
Tool-Grenzen. Das Modell braucht klar definierte Grenzen dafür, was es abfragen darf und was es nicht anfassen darf. Nicht jede Tabelle der Datenbank ist für ein Nutzergespräch relevant – und manche Daten sollten auf Modellebene unter keinen Umständen zugänglich sein. Diese Grenzen vorab zu definieren, ist eine Sicherheits- und Produktentscheidung, nicht nur eine technische.
Berechtigungslogik. Manche Aktionen kann das Modell eigenständig ausführen – Kursdaten abrufen, den Sitzungskontext merken, eine Vorauswahl erstellen. Andere erfordern vor der Ausführung eine ausdrückliche Bestätigung des Nutzers: einen Rückruf buchen, eine Vergleichs-E-Mail versenden, jeden transaktionsnahen Schritt auslösen. Die Unterscheidung zwischen automatischen und bestätigten Aktionen muss bewusst entworfen werden und darf sich nicht erst aus dem Verhalten der Integration ergeben.
Fallback-Verhalten. Live-Datenverbindungen fallen aus. Die Kursverfügbarkeit ändert sich zwischen Beginn und Ende einer Sitzung. Preisdaten können unvollständig sein. Das Modell muss damit souverän umgehen – eingestehen, was es nicht weiß, anbieten, was es weiß, und veraltete Daten niemals als aktuell darstellen. Fallback-Logik lässt sich leicht auslassen und ist in der Produktion teuer nachzurüsten.
Observability. In einem klassischen Produkt protokolliert man Fehler. In einem MCP-integrierten Produkt muss man deutlich mehr protokollieren: die vom Modell ausgeführten Tool-Aufrufe, die Latenz pro Aufruf, fehlgeschlagene Aktionen, die aus Backend-Abfragen zurückgegebenen Daten, wie das Modell die Nutzerabsicht interpretiert hat und wann Fallback-Verhalten ausgelöst wurde. Ohne das wird die Fehlersuche in der Produktion zum Ratespiel.
Testing. Eine MCP-Integration zu testen bedeutet mehr, als die Qualität der Konversation zu prüfen. Es bedeutet, das Verhalten der Backend-Integration, die Berechtigungsabläufe, die Bestätigungslogik für Aktionen und die Grenzfälle in den Daten zu testen – unabhängig davon, ob sich der Dialog gut liest. Eine Konversation kann sich natürlich anfühlen und darunter trotzdem eine defekte Berechtigungsgrenze haben.
Wie wir die Zusammenarbeitsoptionen aufgebaut haben
Ein Teil unserer Arbeit bei solchen Projekten besteht darin, Kunden ein realistisches Bild ihrer Optionen zu geben – nicht nur der technischen, sondern auch der Umsetzungs- und Budgetoptionen. Bei diesem Projekt haben wir drei Wege vorgestellt.
Die erste: Unser Team übernimmt die gesamte MCP-Integration. Saubere Lieferung, volle Verantwortung, höchste Kosten.
Die zweite: Unser Backend-Entwickler arbeitet Seite an Seite mit dem internen Entwickler des Kunden – gemeinsame Umsetzung, integrierter Wissenstransfer, geringere Kosten. Der Entwickler des Kunden geht mit praktischer MCP-Erfahrung am eigenen System aus dem Projekt. Zu dieser Option tendiert der Kunde, und wir halten sie für die richtige Wahl in seiner Situation.
Die dritte: Wir beraten, während das Team des Kunden die Umsetzung übernimmt. Niedrigste Kosten, höchstes Risiko, falls der Entwickler des Kunden noch nicht mit MCP gearbeitet hat.
Die zweite Option eignet sich besonders für Integrationen wie diese, bei denen der Kunde ein fähiges technisches Team und eine langfristige Produkt-Roadmap hat. Die Integration ist keine einmalige Aufgabe – sie muss sich mit dem Produkt weiterentwickeln. Von Anfang an interne Kompetenz aufzubauen, ist die etwas längere Laufzeit wert.
Was sich ändert, wenn es gut gemacht ist
Die Version dieses Produkts, die am Ende einer gut umgesetzten MCP-Integration steht, unterscheidet sich grundlegend von der, mit der der Kunde gestartet ist – nicht, weil sich das Modell verändert hat, sondern weil das Modell nun seine Aufgabe erfüllen kann.
Ein Nutzer, der mit einem Budget, einem Zeitrahmen und einer vagen Vorstellung davon kommt, was er möchte, kann ein echtes Gespräch führen. Der Bot kann die richtigen Rückfragen stellen, aktuelle Kursdaten in Echtzeit abrufen, sich merken, was zuvor in der Sitzung geklärt wurde, und helfen, zu einer Entscheidung zu kommen.
Die Lücke zwischen „Ich habe eine Frage“ und „Ich habe einen nächsten Schritt“ schließt sich deutlich – und in dieser Lücke entscheidet sich die Conversion, wird Nutzervertrauen aufgebaut oder verspielt und rechtfertigt sich das Produkt oder eben nicht.
Für Teams, die prüfen, ob ihr KI-Produkt eine solche Architekturänderung braucht, ist die Frage einfach: Ist die Konversation das Produkt? Lautet die Antwort Ja, ist die Anbindungsschicht kein technisches Detail. Sie ist die Produktarchitektur.
