Un agente con herramientas tiene efectos (y por lo tanto riesgo). Puede abrir tickets, ejecutar cambios, tocar datos o llamar APIs. Eso lo vuelve valioso, pero también impredecible si no está acotado. En un entorno serio, el agente se trata como un sistema: permisos, auditoría, límites y pruebas.
Qué es un agente en la práctica
No es “un prompt largo”. Es una aplicación con:
- Estado (memoria de sesión, contexto, objetivos).
- Herramientas (APIs, bases, despliegues, archivos).
- Políticas (qué puede y qué no puede hacer).
- Observabilidad (logs, trazas, decisiones reproducibles).
Guardrails que sí pagan
- Mínimo privilegio: herramientas por rol y por operación.
- Entrada tipada: esquemas y validación; nunca “texto libre” a una herramienta peligrosa.
- Confirmación humana para acciones irreversibles.
- Límites operativos: timeouts, rate limiting, presupuesto de costo.
Evaluaciones: lo mínimo viable
Construye un set pequeño y útil:
- 20–50 casos reales (no inventados) del dominio.
- Casos de falla: herramienta caída, dato incompleto, ambigüedad.
- Criterios: exactitud, citas/evidencia, seguridad y “degradación correcta”.
Si el modelo cambia o se agregan herramientas, las evals corren antes del despliegue.
Regla simple
Si el agente toca datos o ejecución, exige: permisos acotados, trazabilidad y un camino seguro para detenerse.