Agente con herramientas
El agente de recuperación puede salir de la información inmediata del modelo y buscar evidencia en fuentes externas.
Pero recuperar documentos es solamente una clase de interacción posible.
Una tarea profesional también puede exigir:
- abrir un PDF;
- consultar un sistema de gestión documental;
- calcular un plazo;
- completar una planilla;
- crear un borrador;
- actualizar un ticket;
- registrar qué ocurrió.
Estas operaciones no son simplemente “más texto”.
Requieren que la aplicación pueda invocar herramientas.
Una herramienta es un medio que permite al sistema obtener información, calcular o actuar fuera de la generación del modelo.
En el agente, la diferencia importante es que el sistema puede seleccionar cuándo utilizar una herramienta, con qué parámetros y qué hacer con el resultado.
Las clases agrupan cinco funciones especialmente intuitivas para abogados:
buscar · leer · calcular · escribir · registrar.
La herramienta no es el agente
Las páginas anteriores distinguieron skill, tool, API y otros conceptos.
No necesitamos volver a desarrollarlos.
El punto nuevo es la relación entre herramienta y ciclo agente.
Podemos imaginar:
modelo selecciona una acción
↓
orquestación valida
↓
herramienta ejecuta
↓
resultado vuelve al contexto
↓
modelo decide nuevamenteLa herramienta amplía el espacio de acciones.
Pero no es quien mantiene el objetivo general ni quien necesariamente decide cuándo debe utilizarse.
Herramientas como “manos”: una analogía útil y limitada
Google y las clases utilizan la analogía de las herramientas como las “manos” del agente.
La analogía ayuda porque separa dos funciones:
- el modelo puede producir una selección o instrucción;
- la herramienta ejecuta una operación concreta.
La analogía deja de servir si imaginamos unas manos libres para hacer cualquier cosa.
Una herramienta real debería tener:
- una finalidad definida;
- entradas esperadas;
- salidas esperadas;
- permisos;
- errores posibles;
- límites de alcance.
La calidad de un agente depende también de la calidad de esas interfaces.
1. Buscar
La herramienta de búsqueda permite localizar información fuera del contexto actual.
Puede consultar:
- web;
- DMS;
- base jurídica;
- repositorio contractual;
- base de datos interna.
Buscar como herramienta versus agente de recuperación
La diferencia puede parecer pequeña.
Herramienta de búsqueda: capacidad técnica para ejecutar una consulta.
Agente de recuperación: arquitectura que decide qué necesita buscar, filtra, recupera, cita y utiliza evidencia.
Por tanto:
TOOL DE BÚSQUEDA
≠
SISTEMA DE RECUPERACIÓN COMPLETOUn agente con herramientas puede usar una búsqueda como una de varias acciones.
2. Leer
Leer significa obtener contenido desde un objeto o sistema.
Puede implicar:
- abrir un PDF;
- leer un Word;
- consultar un correo;
- inspeccionar una fila de una base;
- recuperar metadatos.
“Leer” no es una capacidad abstracta ilimitada
Una herramienta necesita límites concretos.
Por ejemplo:
leer_documento(expediente, archivo)puede estar restringida al expediente activo.
La aplicación no debería asumir que, porque técnicamente existe acceso a un repositorio, el agente puede inspeccionar cualquier documento de la organización.
Herramientas de lectura y confidencialidad
Las acciones de lectura suelen percibirse como menos riesgosas porque no modifican información.
Sin embargo, pueden exponer:
- datos personales;
- secretos comerciales;
- comunicaciones privilegiadas;
- información de otros clientes.
Por eso read-only no significa risk-free.
3. Calcular
Los modelos de lenguaje pueden producir resultados numéricos, pero muchas operaciones conviene delegarlas a herramientas deterministas.
Ejemplos jurídicos:
- calcular días entre fechas;
- aplicar un porcentaje;
- convertir moneda;
- sumar montos;
- verificar un plazo;
- comparar fechas de vigencia.
Por qué usar una herramienta
Supongamos que necesitamos calcular:
“30 días corridos desde el 15 de septiembre.”
Podemos pedir al modelo que razone.
Pero si existe una función de fechas fiable, el agente puede delegar esa operación y recibir un resultado estructurado.
La arquitectura combina capacidades:
MODELO
identifica qué cálculo necesita
HERRAMIENTA
realiza cálculo
MODELO
interpreta resultado en contextoEsto muestra que un buen agente no intenta resolver todo mediante lenguaje.
4. Escribir
Aquí aparece un cambio de riesgo importante.
Una herramienta de escritura puede:
- crear un borrador;
- completar una planilla;
- generar una minuta;
- escribir en un sistema;
- modificar un campo;
- producir un archivo.
Escribir un borrador no es lo mismo que modificar un sistema oficial
Comparemos:
crear_borrador_correo()con:
actualizar_estado_contrato("APROBADO")Ambas son acciones de escritura.
Pero su impacto es radicalmente distinto.
La primera puede ser reversible y quedar bajo revisión.
La segunda puede desencadenar procesos institucionales.
La palabra “write” por sí sola no basta para gobernar permisos.
De contenido a efecto
Cuando una IA únicamente genera un texto dentro de un chat, el usuario todavía debe copiarlo o utilizarlo.
Cuando una herramienta escribe directamente en otro sistema, la frontera entre recomendación y acción se acorta.
Por eso las clases formulan una regla transversal:
mientras más irreversible sea la acción, más explícito debe ser el permiso humano.
La página específica sobre permisos desarrollará esta idea. Aquí basta reconocer que la herramienta determina el radio de impacto posible.
5. Registrar
Registrar puede parecer una función administrativa menor.
En realidad, es central para agentes gobernables.
Una herramienta puede dejar constancia de:
- hallazgo;
- estado;
- tarea completada;
- error;
- aprobación;
- documento faltante;
- acción ejecutada.
Registrar resultado versus registrar trayectoria
Podemos guardar únicamente:
resultado: riesgo altoO conservar una estructura más útil:
resultado: riesgo alto
fuente: contrato cláusula 9.2
criterio: playbook sección 4
acción: escalado a privacidad
fecha: ...
estado: pendiente de revisiónLa segunda permite reconstruir mejor el trabajo.
No desarrollaremos todavía logs y traces en detalle, porque pertenecen a la página de observabilidad.
El delta aquí es más sencillo:
registrar también puede ser una herramienta que el agente utiliza para convertir una acción efímera en un estado institucional.
Cómo sabe el agente qué herramienta utilizar
Una herramienta debe estar descrita de manera suficientemente clara para que el sistema pueda seleccionar correctamente.
La descripción puede incluir:
- nombre;
- propósito;
- parámetros;
- tipos de resultado;
- restricciones.
Por ejemplo:
Herramienta: buscar_clausula
Propósito: localizar cláusulas dentro del contrato activo.
Entrada: categoría contractual.
Salida: fragmentos + ubicación.
Límite: no busca fuera del expediente activo.El modelo puede entonces seleccionar la herramienta cuando corresponda.
Herramienta correcta, parámetros incorrectos
Huyen identifica varios modos de falla agentiva:
- seleccionar una herramienta inexistente;
- utilizar una herramienta correcta con parámetros inválidos;
- utilizar parámetros formalmente válidos pero equivocados;
- ejecutar una herramienta que devuelve un resultado erróneo.
Esta clasificación es útil porque muestra que “el agente eligió la tool correcta” todavía no garantiza éxito.
El resultado de una herramienta vuelve al ciclo
Supongamos:
Acción seleccionada: buscar DPA.
La herramienta puede devolver:
status: not_foundEl agente no debería interpretar automáticamente:
“El proveedor no tiene DPA.”
La herramienta sólo informó que no lo encontró en esa búsqueda.
El siguiente paso puede ser:
- reformular búsqueda;
- consultar otra fuente;
- registrar faltante;
- preguntar al usuario.
Esta diferencia entre resultado técnico e inferencia sustantiva es fundamental.
Un caso completo: revisión de contrato con herramientas
Objetivo:
“Preparar una matriz de riesgos del contrato de proveedor.”
El agente dispone de cinco herramientas:
buscar_documento
leer_documento
calcular_plazo
escribir_matriz
registrar_estadoPaso 1. Buscar
Busca contrato, DPA y SLA.
Resultado:
- contrato: encontrado;
- DPA: encontrado;
- SLA: no encontrado.
Paso 2. Leer
Abre contrato y DPA.
Paso 3. Calcular
Encuentra:
“notificación de incidentes dentro de 72 horas desde conocimiento.”
La política exige 48 horas.
Una herramienta puede comparar plazos o calcular diferencias.
Paso 4. Escribir
Completa un borrador de matriz:
| Tema | Evidencia | Criterio | Diferencia |
|---|---|---|---|
| Incidentes | 72h | 48h | +24h |
Paso 5. Registrar
Marca:
SLA: pendiente
privacidad: revisión preliminar completada
aprobación: no iniciadaLa herramienta no “decidió el contrato”.
Permitió ejecutar operaciones concretas dentro de un proceso más amplio.
Herramientas y superficie de acción
Una manera útil de analizar riesgo consiste en ordenar herramientas por el efecto que pueden producir.
OBSERVAR
buscar → leer
TRANSFORMAR
calcular → generar borrador
MODIFICAR
escribir registro → enviar → ejecutar cambioNo es una escala jurídica universal.
Sirve para una intuición:
cuanto más puede modificar el entorno una herramienta, más importantes se vuelven permisos, validación y reversibilidad.
Herramientas para interacción humana
Una herramienta también puede servir para pedir intervención.
Google incluye dentro del diseño agentivo mecanismos de human-in-the-loop mediante los cuales el sistema puede detenerse y solicitar confirmación o información.
Conceptualmente, podemos imaginar:
pedir_aprobacion(
accion = "enviar mensaje al proveedor",
motivo = "documentación faltante"
)Esto es importante porque una herramienta no tiene que ampliar autonomía.
También puede reducirla deliberadamente, creando un punto de control.
No entregar herramientas innecesarias
Más herramientas no significa necesariamente mejor agente.
Un inventario demasiado amplio puede:
- dificultar selección;
- aumentar errores;
- ampliar permisos;
- complicar evaluación;
- crear acciones accidentales.
Si un agente sólo necesita investigar, probablemente no necesita una herramienta para modificar registros críticos.
La arquitectura debería aplicar una regla conocida de seguridad:
conceder únicamente las capacidades necesarias para la tarea.
Seleccionar una herramienta no es lo mismo que confiar en su resultado
En sistemas simples tendemos a pensar en una herramienta como una función determinista: se la llama y devuelve una respuesta. En un agente conviene separar al menos tres controles.
Primero, selección: ¿era ésta la herramienta correcta para la necesidad actual?
Segundo, ejecución: ¿la llamada utilizó parámetros válidos y produjo una respuesta técnicamente exitosa?
Tercero, interpretación: ¿qué significa realmente el resultado para la tarea?
Supongamos una herramienta denominada buscar_documento que devuelve:
resultados = 0Ese dato puede significar que el documento no existe, que está mal nombrado, que la búsqueda utilizó filtros incorrectos o que el repositorio no está disponible. Un agente que transforma inmediatamente 0 resultados en la afirmación “el proveedor no tiene ese documento” está agregando una inferencia no justificada.
El diseño debería conservar la cadena:
selección de tool
↓
parámetros
↓
resultado técnico
↓
interpretación
↓
próxima acciónEsta separación es especialmente valiosa cuando la herramienta consulta sistemas jurídicamente relevantes. Un error de parámetros en una búsqueda de expedientes puede parecer luego una “falta de evidencia”, aunque la evidencia estuviera disponible.
Fallbacks y errores de herramienta
Una herramienta puede fallar sin que toda la tarea deba fracasar. El agente puede necesitar una estrategia de fallback, es decir, una alternativa previamente autorizada.
Por ejemplo:
1. buscar en repositorio contractual
2. si el servicio no responde, registrar error
3. intentar repositorio secundario autorizado
4. si sigue sin resultado, pedir intervención humanaEl fallback no debería convertirse en una excusa para ampliar silenciosamente el universo de acceso. Si la fuente autorizada falla, el agente no debería decidir por sí mismo buscar en cualquier repositorio disponible.
La regla de fondo es simple: las rutas alternativas también necesitan límites.
La herramienta como objeto de evaluación y contratación
Desde una perspectiva jurídica y de procurement, no basta saber que “el agente puede conectarse a sistemas”. Conviene identificar qué integración produce cada capacidad.
Para una herramienta crítica pueden importar preguntas como:
- quién la provee y mantiene;
- qué datos recibe;
- qué autenticación utiliza;
- qué disponibilidad ofrece;
- qué registros conserva;
- qué ocurre cuando cambia su interfaz;
- qué permisos necesita;
- cómo se deshabilita.
Una capacidad agentiva puede depender de varias relaciones contractuales. Si el agente puede consultar una base jurídica licenciada, por ejemplo, su funcionamiento depende tanto del diseño del agente como de la continuidad, condiciones de uso y cobertura de esa fuente.
Qué debes recordar
Un agente con herramientas puede salir del lenguaje y operar sobre recursos externos.
Las cinco funciones pedagógicas del curso son:
buscar, leer, calcular, escribir y registrar.
La herramienta amplía capacidad, pero cada ampliación crea nuevas preguntas:
- ¿qué puede ejecutar?;
- ¿sobre qué objeto?;
- ¿con qué parámetros?;
- ¿qué devuelve?;
- ¿qué ocurre si falla?;
- ¿qué impacto tiene?;
- ¿qué requiere aprobación?
El punto no es que el agente “tenga manos”.
El punto es que cada mano debe tener alcance, interfaz y límites.
El problema que todavía queda abierto
Las herramientas permiten ejecutar acciones.
Pero una organización no trabaja como una colección de acciones aisladas.
Existen procedimientos, etapas, responsables y aprobaciones.
La siguiente página estudia el agente de workflow: un sistema que no inventa libremente toda la ruta, sino que opera dentro de un proceso institucional previamente diseñado y selecciona qué etapa corresponde.