Agentic Customer Support Assistant (FastAPI + RAG + MCP)

Un agente de soporte de comercio electrónico que consulta datos reales de pedidos, responde preguntas sobre políticas basándose en un FAQ mediante RAG y crea tickets de soporte de forma autónoma cuando no puede resolver un problema — todo decidido por el LLM en un bucle de uso de herramientas, no una lógica if/else codificada.

Este es intencionadamente un dominio distinto de un proyecto RAG de "preguntas y respuestas sobre documentos" (las consultas de pedidos y la creación de tickets son acciones, no solo recuperación), lo que resulta útil si quieres dos piezas independientes en un currículum en lugar de la misma idea dos veces.

Qué demuestra

• IA agéntica: uso de herramientas en varios pasos — el modelo encadena check_order_status → faq_search → create_support_ticket en una sola conversación cuando es necesario.

• FastAPI: endpoints REST con validación de solicitudes mediante Pydantic y documentación autogenerada.

• RAG: documentos de FAQ fragmentados y recuperados por relevancia antes de responder preguntas sobre políticas.

• MCP: las mismas herramientas de pedidos/tickets/FAQ se exponen como un servidor MCP (app/mcp_server.py) para usarse fuera de esta API, p. ej. desde Claude Desktop.

Related MCP server: Commerce MCP Server

Configuración

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

Ejecución

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

Documentación en http://localhost:8001/docs.

Ejemplo: flujo agéntico completo

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

Cadena de razonamiento esperada: check_order_status(ORD1002) → ve que sigue en Processing → faq_search("shipping delay") para contexto de política → decide que el cliente necesita escalado → create_support_ticket(...) → devuelve un ID de ticket y una explicación clara.

Datos simulados

• data/faq.txt — política de devoluciones, envíos y cancelación de la que recupera la capa RAG.

• app/tools.py — base de datos de pedidos simulada en memoria (ORD1001, ORD1002, ORD1003) y almacén de tickets. Sustitúyela por una base de datos/CRM real en producción; las firmas de las funciones de herramienta permanecen iguales.

Ejecutar como servidor MCP

python -m app.mcp_server

Expone faq_search, check_order_status, create_support_ticket, get_ticket_status a cualquier host MCP.

Puntos de conversación para la entrevista

• Por qué las herramientas devuelven diccionarios estructurados, no texto libre: el LLM razona sobre datos estructurados de forma más fiable, y es lo que permite reutilizar las mismas funciones para los endpoints REST simples (/orders/{id}) y el bucle del agente.

• El prompt del sistema le indica explícitamente al modelo cuándo escalar a un ticket o responder desde los datos de FAQ/pedidos — una decisión clave de diseño de agentes (la creación excesiva de tickets es un modo de fallo común que vale la pena mencionar).

• max_steps protege contra bucles infinitos de llamadas a herramientas — una preocupación real de fiabilidad en sistemas agénticos.

Posibles extensiones

• Persistir tickets y pedidos en Postgres en lugar de diccionarios en memoria.

• Añadir un ID de conversación /agent/chat + historial almacenado para chats de soporte de varios turnos.

• Añadir escalado con intervención humana (webhook de Slack) cuando se crea un ticket.

• Limitar la tasa y añadir autenticación con clave API antes de cualquier despliegue público.