Tool Design

Las tools definen qué puede hacer un agente; su diseño define si lo hace bien. Cuatro decisiones lo determinan: la granularidad —una herramienta que resuelve una intención de negocio completa, no cinco llamadas técnicas que el agente debe encadenar y donde puede equivocarse—; el nombre y la descripción, que son el manual con el que el agente elige y no documentación decorativa; el retorno, porque un error que explica cómo corregirse vale más que un código de falla; y el número, porque cada herramienta consume ventana de contexto y añade una decisión más donde equivocarse.

Es la diferencia entre una mesa de quirófano y un cajón de herramientas. En el cajón está todo — y por eso no se encuentra nada. La mesa tiene seis instrumentos, rotulados, en el orden en que se van a usar. El cirujano no se volvió más hábil: la mesa decidió por él. Un agente con cuarenta herramientas sin diseño está operando desde el cajón.

El equipo de TI expone el catálogo completo de APIs al agente y lo llama integración. El agente elige mal, encadena mal, quema tokens y falla de maneras que nadie puede reproducir — y el diagnóstico que llega al comité es "el modelo no sirve", cuando el problema era el instrumental. Hay además un costo de seguridad: cada herramienta es superficie de ataque, y una mal acotada es la puerta por donde una inyección de prompt convierte un acceso lícito en daño — el problema que mide el Least Agency Ratio.

En VDA el set de herramientas de cada agente es decisión de arquitectura, no resultado de lo que había disponible: granularidad de intención de negocio y no de endpoint, descripciones escritas para que el agente elija bien a la primera, errores que enseñan a corregirse y privilegio mínimo por rol. Cada agente del C-Suite opera con el instrumental que su rol exige — y con ninguno más.