Agentic Customer Support Assistant (FastAPI + RAG + MCP)

Ein E-Commerce-Support-Agent, der echte Bestelldaten nachschlägt, Richtlinienfragen basierend auf einer FAQ per RAG beantwortet und Support-Tickets autonom erstellt, wenn er ein Problem nicht lösen kann – alles entschieden vom LLM in einer Tool-Use-Schleife, nicht durch hartcodierte If/Else-Logik.

Dies ist bewusst eine andere Domäne als ein einfaches „Dokument-Q&A“-RAG-Projekt (Bestellabfragen + Ticket-Erstellung sind Aktionen, nicht nur Abruf), was nützlich ist, wenn man zwei unterschiedliche Projekte im Lebenslauf haben möchte, statt dieselbe Idee zweimal.

Was es demonstriert

• Agentic AI: mehrstufige Tool-Nutzung – das Modell verknüpft check_order_status → faq_search → create_support_ticket in einer einzigen Konversation, wenn nötig.

• FastAPI: REST-Endpunkte mit Anfragevalidierung über Pydantic und automatisch generierte Dokumentation.

• RAG: FAQ-Dokumente werden in Chunks aufgeteilt und nach Relevanz abgerufen, bevor Richtlinienfragen beantwortet werden.

• MCP: dieselben Bestell-/Ticket-/FAQ-Tools werden als MCP-Server (app/mcp_server.py) für die Nutzung außerhalb dieser API bereitgestellt, z. B. von Claude Desktop.

Related MCP server: CommerceHub MCP

Setup

python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
cp .env.example .env   # add your GROQ_API_KEY

Run

uvicorn app.main:app --reload --port 8001

Dokumentation unter http://localhost:8001/docs.

Beispiel: vollständiger agentischer Ablauf

curl -X POST http://localhost:8001/agent/chat \
  -H "Content-Type: application/json" \
  -d '{"message": "My order ORD1002 seems delayed and I need it urgently, my email is a@b.com. What can you do?"}'

Erwartete Reasoning-Kette: check_order_status(ORD1002) → sieht, dass es noch in Bearbeitung ist → faq_search("shipping delay") für Richtlinienkontext → entscheidet, dass der Kunde eine Eskalation benötigt → create_support_ticket(...) → gibt eine Ticket-ID und eine klare Erklärung zurück.

Mock-Daten

• data/faq.txt — Rückgabe-/Versand-/Stornierungsrichtlinie, aus der die RAG-Schicht abruft.

• app/tools.py — In-Memory-Fake-Bestelldatenbank (ORD1001, ORD1002, ORD1003) und Ticket-Speicher. In Produktion durch eine echte Datenbank/CRM ersetzen; die Funktionssignaturen der Tools bleiben gleich.

Als MCP-Server ausführen

python -m app.mcp_server

Stellt faq_search, check_order_status, create_support_ticket, get_ticket_status für jeden MCP-Host bereit.

Gesprächspunkte für Interviews

• Warum Tools strukturierte Dicts zurückgeben, keinen Freitext: Das LLM argumentiert zuverlässiger über strukturierte Daten, und genau das ermöglicht es, dieselben Funktionen für die einfachen REST-Endpunkte (/orders/{id}) und die Agentenschleife wiederzuverwenden.

• Der System-Prompt weist das Modell explizit an, wann es zu einem Ticket eskalieren soll, im Gegensatz zur Beantwortung aus FAQ-/Bestelldaten – eine wichtige Designentscheidung für Agenten (übermäßige Ticket-Erstellung ist ein häufiger Fehlermodus, den man erwähnen sollte).

• max_steps schützt vor unendlichen Tool-Aufrufschleifen – ein echtes Zuverlässigkeitsproblem in agentischen Systemen.

Mögliche Erweiterungen

• Tickets/Bestellungen in Postgres persistieren statt in In-Memory-Dicts.

• Eine /agent/chat-Konversations-ID + gespeicherten Verlauf für mehrteilige Support-Chats hinzufügen.

• Human-in-the-Loop-Eskalation (Slack-Webhook) hinzufügen, wenn ein Ticket erstellt wird.

• Rate-Limiting und API-Key-Authentifizierung vor jeder öffentlichen Bereitstellung hinzufügen.