Contexto y objetivo

Una plataforma de negocio con backend en Laravel necesitaba IA conversacional que fuera más allá de "llamar a un LLM". Me centré en construir un servicio de IA operable en producción: capaz de razonar sobre la intención del usuario, repartir el trabajo entre agentes de dominio, usar herramientas reales y, sobre todo, no caerse cuando falla el proveedor de IA o el runtime.

La dificultad real no estaba en el "prompt", sino en la orquestación, la resiliencia, el despliegue y la observabilidad: la parte que convierte un experimento en una plataforma.

Arquitectura de orquestación

El flujo central reparte la responsabilidad en piezas con un contrato claro:

• Supervisor — interpreta la intención de la consulta y selecciona el agente adecuado.
• Workers especializados — cada agente trabaja con su prompt de dominio y puede invocar herramientas externas vía MCP / function calling.
• Synthesizer — recompone la respuesta final cuando intervienen varios agentes o herramientas.

La respuesta no devuelve solo texto: incluye metadatos técnicos (agente seleccionado, tools usadas, proveedor, versión de prompt), lo que mejora la trazabilidad y la depuración en producción. El diagrama mental es: Laravel API → FastAPI → Supervisor → Worker → MCP tools → Synthesizer → Response.

Runtime dual y rollout controlado

La plataforma convive entre un runtime legacy y uno nuevo basado en LangGraph, para evolucionar sin big-bang. La transición se gobierna por configuración:

• Canary rollout: un porcentaje del tráfico va al runtime de grafo, ajustable sin redeploy.
• Fail-open: si el grafo falla, la petición cae automáticamente al runtime legacy.
• Fallback de proveedor: soporta varios proveedores LLM (mock, OpenAI, LM Studio, Amazon Bedrock) con modo degradado si el proveedor principal no responde.

Colas y cargas asíncronas

Redis actúa como broker (con workers ARQ), y la topología de colas separa el tráfico por criticidad para que una carga pesada no ahogue lo interactivo:

• Realtime — chat síncrono de baja latencia.
• Tools pesadas — ejecuciones largas de herramientas.
• Batch — procesos diferidos.
• Dead-letter queue — captura de fallos para inspección y reproceso.

El servicio expone endpoints síncronos (respond) y asíncronos (submit) para que el backend Laravel elija según el caso.

Integración backend-to-backend

La conexión con Laravel es un contrato explícito, no un acoplamiento frágil: autenticación por token de servicio, callbacks y base URL configurables, y una validación de variables cruzadas (un preflight de entorno) que detecta incoherencias entre tokens, endpoints y credenciales antes de romper producción.

CI/CD y despliegue en AWS

• Pipeline GitLab CI/CD con stages de validate, test y deploy.
• Empaquetado del artefacto y publicación del bundle en S3.
• CodeDeploy ejecuta el despliegue en la instancia con hooks de ciclo de vida.
• Docker para empaquetado y ejecución reproducible.

Observabilidad y operación

La plataforma se diseñó para ser operable, con señales que un equipo puede vigilar:

• GET /health — estado del servicio y sus dependencias.
• GET /metrics — latencias (percentiles), counters, estado de colas y error rate.
• GET /alerts — alertas activas sobre colas, errores y fallbacks.
• Gestión de prompts en producción: versionado, override, preview, publish e histórico vía API administrativa.

Resultado e impacto

• Una plataforma de IA operable en producción, no una integración aislada con un LLM.
• Resiliencia real: fallback de runtime y de proveedor, dead-letter queue y preflight de entorno.
• El proyecto resuelve a la vez la capa IA (orquestación multiagente, tools, prompts) y la capa de infraestructura y operación (CI/CD, despliegue, observabilidad).