Agentic Travel Recommendations Service

Dieses Projekt ist ein TypeScript- und Node.js-Proof-of-Concept für einen Multi-Tenant-Reiseempfehlungsdienst. Es stellt gemeinsame Empfehlungsfunktionen über eine REST-API, einen Streamable-HTTP-MCP-Endpunkt und eine Kommandozeilenschnittstelle bereit.

Wichtigste Funktionen

• REST-API für Health, Mitgliederprofile und Empfehlungen

• Streamable-HTTP-MCP-Endpunkt

• MCP-Tool: get_member_profile

• MCP-Tool: get_recommendations

• Maßgebliche, vom Mitglied abgeleitete Mandantenauflösung

• Partnerspezifische Empfehlungsobergrenzen

• Partnerspezifische Kategorieausschlüsse

• Deterministische Empfehlungserzeugung

• Fail-closed-Verhalten bei Partnerkonfiguration

• Anforderungs-IDs und strukturierte JSON-Logs

• Minimale CLI-Demonstration

• Mehrstufiger Docker-Build

• Automatisierte Tests

Architektur auf einen Blick

REST / MCP / CLI
       |
       v
RecommendationService
       |
       v
MemberDataService
       |
       | member.partnerId
       v
PartnerConfigurationService
       |
       v
CandidateGenerator
       |
       v
RecommendationPolicy
       |
       | exclusions then cap
       v
Final Recommendations

Aufrufer übermitteln nur memberId; sie wählen nicht die maßgebliche partnerId. Das Mitgliederprofil bestimmt die Partnerkonfiguration, und REST, MCP und CLI nutzen alle dieselbe Geschäftslogikschicht.

Schnellstart

npm ci
npm run dev

Der Dienst ist standardmäßig unter http://localhost:3000 verfügbar.

Typprüfung

npm run typecheck
npm run typecheck:test
npm run typecheck:all

Tests

npm test

Die aktuell verifizierte Basis umfasst 46 erfolgreiche Tests in 6 Dateien.

Produktions-Build

npm run build
npm start

REST-API

GET /health
GET /api/members/:memberId
GET /api/recommendations/:memberId

Beispielanfragen:

curl http://localhost:3000/api/members/MEMBER-001
curl http://localhost:3000/api/recommendations/MEMBER-001

MCP

Der MCP-Server wird bereitgestellt über:

POST /mcp

Er stellt diese Tools bereit:

• get_member_profile

• get_recommendations

Beide Tools akzeptieren nur die Mitgliederkennung:

{
  "memberId": "MEMBER-001"
}

Die Implementierung verwendet den offiziellen @modelcontextprotocol/sdk-Streamable-HTTP-Transport. Der Aufrufer liefert keine partnerId; sie wird aus dem maßgeblichen Mitgliederprofil aufgelöst.

CLI

npm run cli -- MEMBER-001

Demo-Mitglieder:

• MEMBER-001 → BANK_A

• MEMBER-002 → BANK_B

• MEMBER-003 → CREDIT_UNION_C

Docker

docker build -t agentic-travel-recommendations .
docker run --rm -p 3000:3000 agentic-travel-recommendations

Das Image verwendet einen mehrstufigen Build, eine Node-24-Laufzeit und einen Nicht-Root-Laufzeitbenutzer. Der HTTP-Server behandelt Signale für ein sauberes Herunterfahren.

Abschnitt A — Architektur und Abwägungen

Architekturübersicht

Der Dienst ist eine zustandslose TypeScript- und Node.js-Anwendung, die denselben Empfehlungsworkflow über REST, Streamable HTTP MCP und eine CLI bereitstellt. Jeder Transport validiert seine Eingaben und delegiert an den gemeinsamen RecommendationService; Transporthandler implementieren selbst keine Partnerrichtlinie.

Der maßgebliche Mandantenablauf ist:

memberId
→ MemberDataService
→ MemberProfile.partnerId
→ PartnerConfigurationService
→ CandidateGenerator
→ RecommendationPolicy
→ final recommendations

Aufrufer übermitteln memberId und wählen nie die maßgebliche partnerId. Das von MemberDataService zurückgegebene Mitgliederprofil bestimmt, welche Partnerkonfiguration abgerufen wird. Beide vorgelagerten Dienste gleichen außerdem die in einer Antwort enthaltene Identität mit der angeforderten Identität ab, und RecommendationService führt vor der Erzeugung eine zusätzliche Partner-Identitätsprüfung durch.

Die Kandidatenerzeugung ist bewusst unabhängig von der Partnerrichtlinie. Der deterministische Generator erzeugt zunächst rohe Kandidaten aus dem Mitgliederprofil; die generische Richtlinienebene entfernt dann Kandidaten in excludedCategories und wendet recommendationCap in dieser Reihenfolge an. Nur die resultierenden Empfehlungen werden zurückgegeben. Der Member Data Service und der Partner Configuration Service sind für dieses Proof-of-Concept gemockt, und der Zugriff auf die Partnerkonfiguration ist schreibgeschützt.

Design-Abwägungen

Korrektheit vor Verfügbarkeit. Wenn die maßgebliche Partnerkonfiguration fehlt, nicht verfügbar ist, ein ungültiges Schema aufweist oder die Identität nicht übereinstimmt, schlägt die Anfrage fail-closed fehl. Der Dienst ersetzt keine permissiven Standardwerte und gibt keine uneingeschränkten Empfehlungen zurück. Dies kann die Verfügbarkeit während eines Ausfalls vorgelagerter Systeme verringern, verhindert jedoch, dass Empfehlungen die korrekte Mandantenrichtlinie umgehen.

Frische Konfiguration statt Caching. Die erste Version ruft für jede Empfehlungsanfrage die Partnerkonfiguration ab, anstatt eine Cache-Infrastruktur hinzuzufügen. Das hält das Verhalten einfach und stellt sicher, dass jede erfolgreiche Anfrage die aktuelle Richtlinie verwendet. Sie akzeptiert zusätzliche Latenz und Last vorgelagerter Systeme; ein kurzlebiger Cache ist später nur sinnvoll, wenn gemessene Leistung den Konsistenz-Kompromiss rechtfertigt.

Deterministische Erzeugung statt externem LLM. Die Kandidatenerzeugung ist reproduzierbar, testbar, kostenlos und betrieblich vorhersehbar. Das begrenzt die Raffinesse der Personalisierung, macht aber das Richtlinienverhalten und Bewertungsergebnisse leicht überprüfbar. Eine zukünftige LLM- oder Ranking-Komponente könnte die Kandidatenerzeugung ersetzen, ohne die deterministische Richtliniendurchsetzung zu ändern.

Umgang mit Partnerkonfigurationsänderungen

Der Partner Configuration Service ist eine schreibgeschützte Abhängigkeit. Wenn ein Partner seine Empfehlungsobergrenze von unbegrenzt auf 3 ändert oder cruise zu excludedCategories hinzufügt, benötigt der Empfehlungsdienst keine Codeänderung und keinen mandantenspezifischen Zweig. Die nächste erfolgreiche Anfrage liest die aktuelle Konfiguration, und die generische Richtlinienlogik wendet die neuen Ausschluss- und Obergrenzenwerte an.

Solange die Konfiguration mit dem vorhandenen Schema kompatibel bleibt, ist keine erneute Bereitstellung der Anwendung erforderlich. Falls später ein Konfigurations-Cache eingeführt wird, muss dieser eine bewusst kurze TTL oder eine zuverlässige Invalidierungsstrategie haben, da veraltete Konfiguration die aktuelle Richtlinie des Partners vorübergehend verletzen könnte.

Abschnitt B — Produktionsreife und Vorfallreaktion

Vorfall-Runbook-Eintrag

Szenario: Ein Mitglied meldet, dass die AI Concierge eine Kreuzfahrtempfehlung angezeigt hat, obwohl sein Partner Kreuzfahrten ausschließt.

1. Identifizieren und korrelieren. Holen Sie die Anfrage- oder Korrelations-ID aus dem Bericht, sofern verfügbar, und lokalisieren Sie die entsprechenden strukturierten Logs. Erfassen Sie operation, memberId, die maßgebliche partnerId sobald aufgelöst, resultCode und gegebenenfalls den HTTP-Status. Reiseverlauf und Empfehlungsdaten werden absichtlich nicht protokolliert; verwenden Sie daher Kennungen und Ergebnis-Metadaten zur Korrelation.

2. Den maßgeblichen Mandanten verifizieren. Rufen Sie das betroffene Mitglied über MemberDataService ab und bestätigen Sie, dass die angeforderte memberId der zurückgegebenen member.memberId entspricht. Leiten Sie den Mandanten nur aus member.partnerId ab. Vertrauen Sie keiner Partner-ID, die von einem Frontend, einem MCP-Aufrufer, einem Abfrageparameter oder einem Supportbericht stammt.

3. Die Partnerkonfiguration verifizieren. Rufen Sie die Konfiguration mit member.partnerId ab und bestätigen Sie dann configuration.partnerId === member.partnerId. Prüfen Sie excludedCategories und recommendationCap und stellen Sie fest, ob cruise in der aktuellen maßgeblichen Konfiguration ausgeschlossen ist. Fehlende, nicht verfügbare, fehlerhafte oder identitätsabweichende Konfiguration muss dazu führen, dass der Dienst fail-closed reagiert, anstatt permissive Standardwerte zu verwenden.

4. Die Pipeline reproduzieren. Führen Sie das Mitglied durch denselben Empfehlungsworkflow. Eine Kreuzfahrt in der rohen Ausgabe von CandidateGenerator ist an sich kein Fehler, da die Erzeugung die Partnerrichtlinie bewusst ignoriert. Verifizieren Sie, dass RecommendationPolicy die Verarbeitung raw candidates → remove excluded categories → apply recommendation cap → final recommendations durchführt, und bestätigen Sie, dass Kreuzfahrten im Endergebnis nicht enthalten sind.

5. Den Fehlerort eingrenzen. Wenn Kreuzfahrten in den rohen Kandidaten, aber nicht in den endgültigen Empfehlungen erscheinen, arbeitet die Richtlinie korrekt. Untersuchen Sie eine veraltete Client-Antwort, eine Antwort, die dem falschen Mitglied zugeordnet ist, einen anderen Consumer oder Endpunkt, der den erwarteten Workflow umgeht, oder eine Abweichung zwischen dem gemeldeten Zeitpunkt und der aktuellen Konfiguration. Wenn eine Kreuzfahrt RecommendationPolicy übersteht, prüfen Sie den Kategorienvergleich oder die Normalisierung, den Inhalt und die Identität der maßgeblichen Konfiguration sowie aktuelle Richtlinienänderungen oder Regressionen.

6. Eindämmen. Wenn die korrekte Partnerrichtlinie nicht festgestellt oder sicher reproduziert werden kann, reagieren Sie fail-closed, anstatt potenziell nicht konforme Empfehlungen zurückzugeben. Versuchen Sie nicht, den schreibgeschützten Partner Configuration Service aus dieser Anwendung heraus zu ändern.

7. Beheben und verifizieren. Korrigieren Sie den Fehler in der verantwortlichen Schicht und fügen Sie einen Regressionstest hinzu, der den genauen Fehler reproduziert. Führen Sie aus:

   npm run typecheck:all
   npm test
   npm run build

   Verifizieren Sie den betroffenen Partner, mindestens einen nicht betroffenen Mandanten, das REST-Verhalten und gegebenenfalls das MCP-Verhalten.

8. Nachbereitung. Dokumentieren Sie die Grundursache, den betroffenen Partner- und Mitgliederumfang, das Auswirkungsfenster, die Abhilfe, die Regressionstestabdeckung und die vorbeugenden Maßnahmen.

Teil B2 — Erforderliche Denkfrage

Ein KI-Codierungsassistent könnte plausibel eine Implementierung erzeugen, die vorgelagerte Mitglieds- und Partnerdatensätze per Zod validiert, aber die zurückgegebenen Identitäten nie mit den angeforderten Identitäten abgleicht. Der Code wäre typsicher, Schema-Validierung und Happy-Path-Tests würden bestehen, und eine oberflächliche Überprüfung würde eine angemessene defensive Validierung sehen. Die fehlende mandantenübergreifende Invariante würde dennoch ein ernsthaftes Richtlinienrisiko darstellen.

Zum Beispiel gehört MEMBER-001 zu BANK_A. RecommendationService fordert die Konfiguration von BANK_A an, aber ein fehlerhafter oder falsch weitergeleiteter vorgelagerter Dienst gibt eine vollständig schema-validierte BANK_B-Konfiguration mit einer unbegrenzten Obergrenze und ohne Kategorieausschlüsse zurück. Zod akzeptiert deren Form korrekt, aber die Anwendung dieser Richtlinie auf MEMBER-001 könnte die Einschränkungen von BANK_A umgehen.

Ich würde dies mit einem adversarischen Regressionstest aufdecken: BANK_A anfordern, während ein absichtlich fehlerhafter Konfigurationsdienst-Test-Double die gültige BANK_B-Konfiguration zurückgibt. Ich würde InvalidUpstreamDataError erwarten, bestätigen, dass kein Empfehlungsergebnis erzeugt wird, und explizit verifizieren, dass CandidateGenerator.generate nicht aufgerufen wurde. Ich würde den entsprechenden Mitgliederdaten-Test hinzufügen, der beweist, dass die angeforderte memberId der zurückgegebenen member.memberId entsprechen muss.

Bevor ich auf KI-generierten Code vertraue, würde ich die Autoritäts- und Ausführungsreihenfolge nachvollziehen, anstatt mich nur auf Typen zu verlassen. Ich würde verifizieren, dass member.partnerId – niemals eine Aufrufereingabe – den Mandanten auswählt; dass beide zurückgegebenen Identitäten ihren maßgeblichen Anfragen entsprechen; und dass fehlende, nicht verfügbare oder abweichende Konfiguration ohne permissiven Fallback fail-closed endet. Ich würde außerdem bestätigen, dass die Erzeugung nicht beginnen kann, bevor die Richtlinienidentität sicher festgestellt ist, und dass negative, adversarische Tests diese Fälle neben normalen Happy Paths abdecken.

Abschnitt C — KI-Nutzungsprotokoll

Interaktion 1 — Architekturprüfung

Was ich gefragt habe

Ich bat den KI-Codierungsassistenten, die Aufgabe zu prüfen und bei der Entwicklung einer minimalen Architektur zu helfen, die ein Ingenieur realistisch umsetzen kann. Der angeforderte Umfang umfasste Domänenmodelle, gemockte vorgelagerte Dienste, Empfehlungslogik, REST, MCP, CLI, automatisierte Tests und Containerisierung, während Infrastruktur vermieden wurde, die das Proof-of-Concept nicht benötigte.

Was die KI bereitgestellt hat

Sie schlug vor, Domänenmodelle, Dienstverträge, gemockte vorgelagerte Dienste, Kandidatenerzeugung, Partnerrichtlinie, Orchestrierung und Transportadapter zu trennen. Zunächst schlug sie stdio als einfachsten MCP-Transport vor.

Was ich übernommen, geändert oder abgelehnt habe

Ich habe die Schichtentrennung übernommen, weil sie es REST, MCP und CLI ermöglicht, eine Geschäftslogikschicht aufzurufen, anstatt Regeln unabhängig zu implementieren. Ich habe stdio als primären MCP-Transport abgelehnt und das Design auf den Streamable-HTTP-Transport des offiziellen MCP SDK unter POST /mcp ausgerichtet. Die Aufgabenstellung beschreibt eine interne API, die Agenten entdecken und aufrufen sollen, und HTTP passt zur containerisierten Dienstarchitektur. Ich habe diese Entscheidung getroffen, nachdem ich den Vorschlag mit den Integrationsanforderungen der Aufgabenstellung verglichen habe, anstatt automatisch die einfachste Option zu akzeptieren.

Interaktion 2 — Inkrementelle Implementierung

Was ich gefragt habe

Ich habe nicht die gesamte Anwendung in einer einzigen Aufforderung angefragt. Ich habe die Implementierung in begrenzte Schritte unterteilt: Domänenmodelle, Schemas und Fehler, vorgelagerte Verträge und Mocks, Kandidatenerzeugung, Empfehlungsrichtlinie, Orchestrierung, REST, MCP, CLI, Beobachtbarkeit und Docker. Nach jedem Schritt habe ich das berichtete Verhalten überprüft und Typprüfung sowie Tests verlangt, bevor ich fortfuhr.

Was die KI bereitgestellt hat

Der Assistent implementierte jede begrenzte Komponente mit fokussierten Tests und berichtete die geänderten Dateien und Verifikationsergebnisse. Dadurch wurden einzelne Designentscheidungen sichtbar und überprüfbar, anstatt sie in einem großen generierten Patch zu verstecken.

Was ich übernommen, geändert oder abgelehnt habe

Ich habe den gemeinsamen RecommendationService, den deterministischen CandidateGenerator, die separate RecommendationPolicy, die aus Mitgliedsdaten abgeleitete Mandantenauflösung, den schreibgeschützten Konfigurationsvertrag und die gemeinsame REST-/MCP-/CLI-Geschäftslogik beibehalten. Diese Struktur macht die Mandantenrichtlinie unabhängig testbar und verhindert transportspezifische Regelimplementierungen. Ich habe außerdem bewusst an der deterministischen Generierung festgehalten, anstatt eine externe LLM-Abhängigkeit hinzuzufügen. Die Bewertung konzentriert sich auf das Servicedesign und die Durchsetzung von Richtlinien, und reproduzierbare Ergebnisse sind einfacher zu testen, zu debuggen und zu demonstrieren. Jedes Inkrement wurde erst akzeptiert, nachdem sein Verhalten den architektonischen Invarianten entsprach und die Prüfungen bestanden waren.

Interaktion 3 — Produktions- und Sicherheitsaudit

Was ich gefragt habe

Nachdem die Anwendung funktionierte, forderte ich die KI auf, keine weiteren Funktionen hinzuzufügen und das Repository aus der Perspektive eines leitenden Ingenieurs, eines Sicherheitsprüfers für Multi-Tenant-Umgebungen, eines Bereitschaftsverantwortlichen für die Produktion und eines REST-/MCP-API-Prüfers zu auditieren.

Was die KI bereitgestellt hat

Das Audit ergab, dass schema-konforme Upstream-Antworten ursprünglich nicht mit der angeforderten Mitglieds- oder Partneridentität korreliert wurden. Es zeigte außerdem, dass fehlerhaftes JSON fehlschlagen konnte, bevor die Request-ID-Middleware den Anforderungskontext hergestellt hatte. Darüber hinaus wurden weitere Verbesserungen mit niedrigerer Priorität vorgeschlagen.

Was ich behalten, geändert oder abgelehnt habe

Ich akzeptierte beide hochwertigen Erkenntnisse, da sie die Mandantenkorrektheit und den sicheren Betrieb betrafen. Für die Identitätskorrelation prüft die Implementierung nun, dass eine zurückgegebene memberId mit dem angeforderten Mitglied übereinstimmt, dass configuration.partnerId mit der maßgeblichen member.partnerId übereinstimmt und dass RecommendationService die Identitätsprüfung der Konfiguration defensiv wiederholt. Abweichungen führen zu einem Fail-Closed-Verhalten, und adversariale Regressionstests verifizieren, dass die Kandidatengenerierung niemals startet, wenn die maßgebliche Konfiguration nicht hergestellt werden kann. Für fehlerhaftes JSON werden Anforderungskontext und Request-ID nun vor dem Parsen hergestellt. Ungültige Anforderungskörper erhalten eine sichere strukturierte 400-Antwort ohne Parserdetails, Stack-Traces, Dateisystempfade oder rohen Anforderungsinhalt. Ich habe Ideen mit niedrigerer Priorität wie persistente MCP-Sitzungen, zusätzliche verteilte Infrastruktur und erweiterte Beobachtbarkeit zurückgestellt, da sie für den vierwöchigen Proof-of-Concept unnötig waren und den betrieblichen Umfang erhöht hätten. Ich habe jede Empfehlung anhand der Anforderungen des Auftrags, der Mandantenkorrektheit, der Testbarkeit, des betrieblichen Risikos und des Lieferumfangs bewertet. Der Assistent lieferte Optionen und Implementierungshilfe, aber ich habe die Begründung geprüft, die Änderungen ausgewählt und sie durch gezielte Tests sowie End-to-End-Prüfungen verifiziert.

Erster Schritt in vier Wochen

Was zuerst ausgeliefert wird

Das Vier-Wochen-Ziel ist ein erster auslieferbarer interner Proof-of-Concept. Er demonstriert den geforderten Arbeitsablauf mit sicherer Mandantendurchsetzung und betrieblichen Grundlagen; es ist keine Behauptung, dass jede für eine breite Produktionseinführung erforderliche Fähigkeit vollständig vorhanden ist.

Woche 1 — Service-Grundlage

• Die TypeScript- und Node.js-Service-Grundlage schaffen.

• Domänenmodelle, strikte Zod-Grenzvalidierung und typisierte Fehler definieren.

• Den MemberDataService-Vertrag und eine Mock-Implementierung hinzufügen.

• Den schreibgeschützten PartnerConfigurationService-Vertrag und eine Mock-Implementierung hinzufügen.

• Eine maßgebliche, aus Mitgliedsdaten abgeleitete Mandantenauflösung und das anfängliche Unit-Test-Fundament etablieren.

Ziel: Sichere Servicegrenzen und Mandantenautorität etablieren, bevor die Empfehlungslogik implementiert wird.

Woche 2 — Empfehlungsworkflow

• Den deterministischen CandidateGenerator unabhängig von Partnerregeln implementieren.

• RecommendationPolicy implementieren, einschließlich Kategorieausschlüssen und Empfehlungsobergrenzen.

• Die geforderte Reihenfolge durchsetzen: zuerst Ausschlüsse, dann die Obergrenze.

• Die Orchestrierung durch RecommendationService und das Fail-Closed-Verhalten der Konfiguration hinzufügen.

• Richtlinie und Orchestrierung mit gezielten Unit-Tests abdecken.

Ziel: Nachweisen, dass vertragliche Partnerregeln deterministisch und unabhängig von der Kandidatengenerierung sind.

Woche 3 — Schnittstellen und End-to-End-Ablauf

• Die REST-Endpunkte und den Streamable-HTTP-MCP-Endpunkt bereitstellen.

• Die MCP-Tools get_member_profile und get_recommendations bereitstellen.

• Die CLI-Demonstration hinzufügen.

• REST, MCP und CLI über die gemeinsame Geschäftsschicht führen.

• REST-/MCP-Integrationstests und Tests für Mandantenüberschreibungen hinzufügen.

Ziel: Den vollständigen Empfehlungsworkflow über die im Auftrag geforderten Schnittstellen demonstrieren.

Woche 4 — Produktionsreife und Auslieferung

• Request-IDs, Korrelationsfelder, strukturierte JSON-Protokollierung und sichere Fehlerbehandlung hinzufügen.

• Fehlerhaftes JSON sicher behandeln und ein ordentliches Herunterfahren implementieren.

• Den mehrstufigen Docker-Build und einen Runtime ohne Root-Rechte hinzufügen.

• Produktionsquellcode und Tests getrennt typüberprüfen.

• Das Produktions- und Sicherheitsaudit durchführen und adversariale Identitätskorrelations-Tests hinzufügen.

• Die abschließende End-to-End- und Container-Verifizierung abschließen.

• README, Incident-Runbook und Demonstrationsvideo vorbereiten.

Ziel: Den Proof-of-Concept so gestalten, dass das verantwortliche Team ihn im Bereitschaftsdienst unterstützen kann.

Was später kommt

Die folgenden Arbeiten sind bewusst bis nach der ersten Vier-Wochen-Veröffentlichung zurückgestellt:

1. Echte Upstream-Integrationen. Die gemockten MemberDataService- und PartnerConfigurationService-Implementierungen durch echte arrivia-REST-Clients ersetzen, während die bestehenden Serviceverträge und Identitätskorrelations-Invarianten erhalten bleiben.

2. Bestehende Authentifizierungs- und Autorisierungsintegration. Mit den vorhandenen Identitäts- und Gateway-Mechanismen von arrivia integrieren, anstatt eine neue Identitätsplattform einzuführen. Die Autorisierung muss die aus Mitgliedsdaten abgeleitete Mandantenautorität bewahren.

3. Netzwerkresilienz. Für reale Upstream-HTTP-Abhängigkeiten Zeitüberschreitungen für Anforderungen und Verbindungen validieren und konfigurieren, begrenzte Wiederholungsversuche dort, wo Operationen sicher wiederholt werden können, und explizites Fehlerverhalten festlegen. Konfigurationsunsicherheit muss weiterhin zu Fail-Closed-Verhalten führen.

4. Leistungsvalidierung. Vor der Optimierung realistische Last- und Leistungstests durchführen. Kurzlebiges Caching der Partnerkonfiguration nur in Betracht ziehen, wenn Messungen es rechtfertigen. Veraltete Richtlinien sind ein Korrektheitsrisiko, daher erfordert jeder Cache eine klare Strategie für Aktualität und Invalidierung.

5. Empfehlungsintelligenz. Den deterministischen CandidateGenerator möglicherweise durch ein LLM, ein Ranking-Modell oder eine umfassendere Personalisierung ersetzen oder ergänzen. RecommendationPolicy muss deterministisch und außerhalb des Modells bleiben, damit generierte Ausgaben keine Partnerregeln außer Kraft setzen können.

6. Produktionsbeobachtbarkeit. Die vorhandenen strukturierten Ereignisse und Korrelations-IDs mit den von arrivia genehmigten Metriken, Tracing-, Alarmierungs- und Betriebswerkzeugen verbinden.

7. MCP-Weiterentwicklung. Zustandsbehaftetes oder fortsetzbares MCP-Verhalten nur dann in Betracht ziehen, wenn eine konkrete Produktanforderung einen Zustand über mehrere Requests hinweg erfordert. Die derzeitige zustandslose Streamable-HTTP-Implementierung ist für diesen Dienst beabsichtigt.