OrderOps Agent
Agente de soporte de una tienda: responde sobre políticas, consulta pedidos y propone reembolsos que aprueba un operador.
- Un grafo de agente con 4 rutas (políticas, pedidos, reembolsos, fuera de alcance). Las reglas de reembolso viven en código, no en el prompt, y un operador aprueba cada reembolso.
- En AWS con CI/CD en GitHub Actions: cada merge se despliega solo, con smoke test y rollback automático.
- Cada solicitud queda trazada en un dashboard en vivo y en Langfuse: cerca de $0.012 por conversación, con latencia p50/p95 y tasa de failover.
- 41/41 casos de eval aprobados, 13 de ellos adversariales, como control de regresión en cada pull request. 457 pruebas automatizadas.
Cómo está hecho
Por qué las reglas viven en código
El modelo convierte el mensaje en una solicitud estructurada; 4 funciones simples deciden si está permitida. A un prompt se le puede convencer de saltarse una regla. A una función no.
Por qué el agente solo ve tus pedidos
El token de sesión del cliente viaja con cada tool call, así que la autorización se queda donde ya vivía.
Modelos y memoria
Anthropic, OpenAI y AWS Bedrock detrás de una sola interfaz, con failover automático y prompt caching. El agente recuerda cada conversación y datos útiles de cada cliente, en PostgreSQL.
Despliegue
Una instancia EC2 de AWS detrás de Caddy con TLS automático y un rol IAM de instancia, sin access keys en el servidor. Cada pull request corre lint, typecheck, pruebas unitarias y e2e, un chequeo de migraciones y evals sin claves. Cada merge se despliega con OIDC, imágenes en ECR etiquetadas por commit, SSM, un smoke test y rollback automático.
Por qué una sola instancia EC2
Es una demo. ECS Fargate con RDS y un balanceador de carga cuesta varias veces más; es el siguiente paso documentado para escalar.
Observabilidad
Cada solicitud guarda su ruta, herramientas, proveedor, failover, tokens, costo y latencia en PostgreSQL, más spans de Langfuse por nodo del grafo. La demo muestra cada decisión con su costo y latencia, y un dashboard con latencia p50/p95, costo por conversación y tasa de failover. La cifra de $0.012 viene de una carga de demo de 40 solicitudes.
Evals
41 casos: 20 normales, 8 fuera de alcance y 13 adversariales, todos aprobados en la última corrida. Cada pull request corre los chequeos sin claves y falla si la tasa de aprobación baja más de 10%.
Protecciones de la demo pública
Límites de solicitudes por IP y por cliente (30 mensajes de chat por minuto por cliente), un tope de $1 al día en gasto de modelos con una respuesta fija al superarlo, y un reinicio nocturno de los datos.