Exponer las capacidades del agente como contratos de herramienta acotados, no como API de sistema en bruto
Cada herramienta declara propósito, entrada, salida, permisos, precondiciones, efecto, fallo y reversibilidad, y los impone en código, para que el prompt no sea la última línea de defensa.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01Contexto
Un agente piloto usaba un usuario de integración con acceso general a la API del CRM. Podía leer y escribir cualquier objeto al que llegara la integración. Las salvaguardas vivían en el prompt de sistema. Un cambio de prompt durante las pruebas le permitió actualizar etapas de oportunidad que solo debía leer.
02Factores de decisión
- F01
Mínimo privilegio para un actor que razona de forma probabilística
- F02
Reglas impuestas donde no se pueden sortear con argumentos
- F03
Idempotencia ante reintentos y peticiones duplicadas
- F04
Capacidades que se puedan revisar y probar
03Opciones consideradas
Acceso general a la API con salvaguardas en el prompt
Prototipos con datos sintéticos
Coste: El prompt es el único control; una edición amplía la autoridadAcceso de solo lectura; las personas hacen todas las escrituras
Asistencia pura
Coste: Sin borradores; valor limitadoUn pequeño catálogo de herramientas específicas con contratos impuestos
Agentes que preparan borradores o actúan en sistemas de registro
Coste: Herramientas que diseñar, versionar y probar04Decisión
Exponer solo herramientas específicas de la tarea. Cada una tiene un contrato (propósito, entrada y salida tipadas, permisos, precondiciones, efecto, comportamiento ante fallos y reversibilidad) que la propia herramienta impone: los borradores no pueden convertirse en registros, los mensajes no pueden enviarse sin una referencia de aprobación y los ID de petición duplicados devuelven el resultado existente. Las capacidades con consecuencias (aprobación de descuentos, creación de clientes en el ERP, fusión de cuentas) no son herramientas. Las herramientas se ejecutan con la visibilidad del usuario que hace la petición, y cada llamada queda registrada en la traza.
05Consecuencias
- La autoridad se puede revisar leyendo el catálogo de herramientas.
- Los cambios de prompt no pueden ampliar lo que el agente puede hacer.
- Los reintentos y las peticiones duplicadas son seguros por construcción.
- Añadir una capacidad es una decisión de diseño con contrato, no un cambio de configuración.
06Cuándo revisarla
La plataforma ofrece de forma nativa permisos de agente granulares y exigibles.
El agente solo lee y resume.
07Dónde se aplica esta decisión
Casos que adoptan esta decisión, y por qué importa en cada uno.