Dos de las cuatro mejoras de la auditoría del agente.
1. Las herramientas aceptan cliente_nombre además de cliente_id.
De 27 parámetros que eran IDs, 10 eran de cliente. Para cada acción el
modelo tenía que encadenar: listar_clientes → leer la respuesta →
encontrar la fila → extraer el número → recién ahí llamar a la
herramienta. Cuatro pasos, y basta que falle uno para que no se guarde
nada — es la explicación más probable de la factura que nunca se creó,
porque ese cliente podía no venir en la primera página del listado.
Ahora el modelo pasa el nombre y el servidor lo resuelve, con búsqueda
completa y no paginada. Si hay varios candidatos devuelve la lista para
que el modelo pregunte cuál, en vez de elegir uno: cargarle una factura
a la empresa equivocada es peor que preguntar. Una coincidencia exacta
gana sobre las parciales, así "Metropolitana" no queda ambiguo solo
porque existe "Metropolitana Norte".
2. Contadores de uso y fallo por herramienta, expuestos como
estado_herramientas.
Cada problema se venía diagnosticando de a un caso, reconstruyendo qué
pasó después de que el usuario avisara. Ahora se puede preguntar
directamente qué viene fallando y ver si es una herramienta puntual o el
modelo eligiendo mal. En memoria a propósito: alcanza para responder eso
y no agrega una tabla.
Quedan las otras dos: adelgazar el prompt de 5,4 KB moviendo los manuales
por dominio a las descripciones de las herramientas, y comparar modelos con
un mismo caso. La primera conviene hacerla con el sistema estable, porque
toca cómo decide el modelo en todos los flujos a la vez.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Confirmado que la factura nunca se creó: la lista de /app/facturas no
filtra nada que pudiera esconderla. La herramienta falló y el modelo
informó "FACTURA GUARDADA EXITOSAMENTE" igual.
El commit anterior le prohíbe eso por prompt, pero un prompt es una
sugerencia. Esto es la garantía: el código junta los errores que
devolvieron las herramientas durante la conversación y los agrega a la
respuesta. Si algo no se completó, se ve, diga lo que diga el modelo.
No reemplaza al prompt — el modelo sigue debiendo explicar el fallo con
sus palabras. Es la red por debajo, para que un "guardado exitosamente"
sobre algo que no se guardó no pueda pasar desapercibido otra vez.
Sigue sin saberse por qué falló aquella vez, porque hasta hoy el resultado
de las herramientas no se registraba. Con el log y este aviso, el próximo
intento lo va a decir en el momento.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Por qué no aparecía la factura: la única herramienta de venta del bot era
adjuntar_factura, y exige un documento pendiente en el chat. Al dictarle
los datos por texto el modelo no tenía con qué guardar — y como el prompt
tampoco se lo prohibía, informó "guardada exitosamente" sobre algo que
nunca se creó.
/api/v2/facturas ya permitía crearlas, pero el bot no llama a la API REST:
usa su propio registro de herramientas, así que solo puede hacer lo que ese
registro expone. El hueco estaba ahí, no en la API.
crear_factura toma cliente_id y monto (obligatorios), número, concepto y
fechas. Devuelve el monto realmente guardado y el id, que es lo que el
prompt le exige informar en vez de repetir lo que dijo el usuario.
Las descripciones de las dos herramientas se remiten entre sí para que el
modelo no elija la equivocada: con documento adjunto va adjuntar_factura,
con datos dictados va crear_factura. El test verifica esa distinción,
porque elegir mal reproduce exactamente el fallo original.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
