# 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

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

## Run

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

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

### Example: full agentic flow

```bash
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

```bash
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.