Agentic Customer Support Assistant (FastAPI + RAG + MCP)

An e-commerce support agent that looks up real order data, answers policy questions grounded in an FAQ via RAG, and files support tickets autonomously when it can't resolve an issue — all decided by the LLM in a tool-use loop, not hardcoded if/else logic.

This is intentionally a different domain from a plain "document Q&A" RAG project (order lookups + ticket creation are actions, not just retrieval), which is useful if you want two distinct pieces on a resume rather than the same idea twice.

What it demonstrates

• Agentic AI: multi-step tool use — the model chains check_order_status → faq_search → create_support_ticket in a single conversation when needed.
• FastAPI: REST endpoints with request validation via Pydantic and auto-generated docs.
• RAG: FAQ documents chunked and retrieved by relevance before answering policy questions.
• MCP: the same order/ticket/FAQ tools are exposed as an MCP server (app/mcp_server.py) for use outside this API, e.g. from Claude Desktop.

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

Docs at http://localhost:8001/docs.

Example: full agentic flow

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?"}'

Expected reasoning chain: check_order_status(ORD1002) → sees it's still Processing → faq_search("shipping delay") for policy context → decides the customer needs escalation → create_support_ticket(...) → returns a ticket ID and a clear explanation.

Mock data

• data/faq.txt — returns/shipping/cancellation policy the RAG layer retrieves from.
• app/tools.py — in-memory fake order DB (ORD1001, ORD1002, ORD1003) and ticket store. Swap for a real database/CRM in production; the tool function signatures stay the same.

Run as an MCP server

python -m app.mcp_server

Exposes faq_search, check_order_status, create_support_ticket, get_ticket_status to any MCP host.

Interview talking points

• Why tools return structured dicts, not free text: the LLM reasons over structured data more reliably, and it's what lets the same functions be reused for the plain REST endpoints (/orders/{id}) and the agent loop.
• The system prompt explicitly tells the model when to escalate to a ticket vs. answer from FAQ/order data — a key agent-design decision (over-eager ticket creation is a common failure mode worth mentioning).
• max_steps guards against infinite tool-call loops — a real reliability concern in agentic systems.

Possible extensions

• Persist tickets/orders in Postgres instead of in-memory dicts.
• Add a /agent/chat conversation ID + stored history for multi-turn support chats.
• Add human-in-the-loop escalation (Slack webhook) when a ticket is created.
• Rate-limit and add API-key auth before any public deployment.