«He actualizado el documento» puede ser una afirmación verdadera, la descripción de algo que se intentó o una frase generada sin que haya ocurrido ninguna actualización. Un modelo que conversa sin acceso a herramientas no modifica con sus palabras ningún archivo externo. Dentro de un sistema conectado, en cambio, ciertas salidas pueden convertirse en operaciones sobre documentos, bases de datos o interfaces. En ese caso la diferencia entre decir y hacer tiene consecuencias técnicas y pragmáticas inmediatas. Un agente lingüístico combina un modelo de lenguaje con procedimientos para observar un entorno, seleccionar acciones y utilizar sus resultados al continuar una tarea. El término designa una organización funcional cuyo alcance depende de las herramientas, los permisos y los controles disponibles, sin atribuir al sistema conciencia, intención moral ni autonomía ilimitada. Un sistema que consulta una calculadora y otro que modifica un sitio web pueden compartir el mismo modelo central y tener capacidades prácticas muy distintas.
Esta lectura examina cómo se traduce una petición en acciones, qué información necesita circular entre un paso y el siguiente y cómo se comprueba que el objetivo se cumplió. La dimensión lingüística del problema va más allá de formular comandos e incluye interpretar referencias, reconocer restricciones, separar instrucciones de datos y comunicar con precisión el estado del trabajo. Es posible que el agente ejecute bien una operación y la describa mal, o que describa con claridad una operación que nunca se ejecutó. Ambas discrepancias necesitan evaluación.
La herramienta como contrato operativo
Una herramienta expone una operación con entradas, salidas y condiciones de uso. Puede recibir una expresión matemática y devolver un resultado, consultar un registro por su identificador o guardar contenido en una ruta. El modelo debe elegir la herramienta pertinente y producir argumentos compatibles con su interfaz. La corrección sintáctica de esos argumentos es necesaria e insuficiente a la vez, porque una fecha bien formada puede ser la fecha equivocada y un identificador válido puede corresponder a otro documento. La descripción de la herramienta es, en este sentido, un contrato operativo que especifica qué hace la operación y qué puede concluirse de su respuesta. Cuando una búsqueda devuelve cero coincidencias, solo consta que esa consulta no halló resultados en esa colección, aunque el objeto podría estar en otro lugar. Una operación que acepta una solicitud, por su parte, puede haberla puesto en cola sin terminarla. El agente ha de interpretar esos estados y reservar la declaración de éxito definitivo para las respuestas que la justifican.
Toolformer, presentado por Schick y colaboradores, exploró cómo un modelo aprende a decidir cuándo llamar a interfaces externas, qué argumentos pasarles y cómo incorporar sus resultados a la predicción posterior. Con un procedimiento de entrenamiento específico, el trabajo mostró una manera de integrar herramientas en el comportamiento de los modelos de lenguaje, aunque cada combinación de modelo e interfaz necesita su propia evaluación (Schick et al., 2023).
La selección de herramientas fija también los límites de la capacidad del sistema. Un sistema de solo lectura carece de base para decir que editó un archivo. Si puede crear borradores pero no enviarlos, debe distinguir ambos estados en lo que comunica. Como la interfaz conversacional puede ocultar estas diferencias al usuario, la responsabilidad de hacerlas explícitas recae en el sistema. La frase final de una tarea debería describir operaciones observadas y dejar fuera cualquier reconstrucción verosímil de cómo habría terminado el trabajo.
Un buen diseño reduce la ambigüedad de las salidas. Los identificadores estables, los estados explícitos y los mensajes de error diferenciados ayudan a decidir el paso siguiente. Si todo fallo se presenta como «algo salió mal», resulta difícil distinguir una entrada inválida de una interrupción temporal. El diseño de las herramientas influye directamente en la calidad del razonamiento operativo que puede sostener el agente.
Interpretar un objetivo antes de actuar
Las peticiones humanas suelen omitir detalles que el contexto permite recuperar. «Sube estas lecturas» presupone cuáles son, dónde deben publicarse y qué cuenta como publicación terminada. El agente necesita resolver esas referencias con la información autorizada de que dispone y separar las decisiones rutinarias de las ambigüedades que alteran materialmente el objetivo. Consultar cada detalle puede volver inútil al agente, aunque suponer sin evidencia puede producir cambios equivocados.
Hay además restricciones expresadas de manera indirecta. «Conserva la bibliografía» obliga a que la conversión de formato mantenga todas las referencias y «no cambies el contenido» delimita qué modificaciones son aceptables. Una indicación como «hazlo uno a uno» fija, en cambio, un orden de trabajo, aunque el sistema pueda realizar consultas auxiliares de forma independiente. Estas instrucciones deben persistir durante toda la tarea, también cuando un paso técnico concentra la atención del sistema. Algo parecido ocurre con los subobjetivos que la petición no menciona. Publicar un documento puede requerir convertir su formato, comprobar los enlaces y verificar la página final, pasos razonables cuando forman parte del resultado solicitado. Esa ampliación del encargo ha de mantenerse vinculada al propósito. Rediseñar todo el sitio, enviar anuncios a terceros o modificar otras colecciones queda fuera de lo que cubre la petición de publicar.
La incertidumbre debe tratarse según sus consecuencias. Una pregunta está justificada cuando la información ausente altera una decisión que no puede resolverse con la evidencia disponible y cuyo error tendría un costo apreciable, criterio que descarta tanto preguntar siempre como no preguntar nunca. Escoger entre dos archivos con títulos idénticos y versiones diferentes sin revisar fechas o contenido puede resultar arriesgado, mientras que ante una preferencia menor de formato puede bastar una convención razonable.
Esta interpretación tiene una dimensión pragmática. La petición crea un compromiso de trabajo cuyas condiciones se construyen con el contexto compartido. Si el agente pierde la representación de lo que se le pidió, de lo ya decidido y de lo pendiente, puede completar muchas operaciones correctas e incumplir de todos modos el encargo principal.
Observar, actuar y revisar el estado
Un agente operativo suele alternar observaciones y acciones. Lee el estado disponible, elige una operación, recibe un resultado y decide cómo seguir. ReAct exploró la combinación de pasos de razonamiento expresados en lenguaje con acciones sobre fuentes o entornos y obtuvo ventajas en tareas concretas. Su aporte fue estudiar una interacción iterativa entre la planificación y el acceso a la información, con ambas actividades entrelazadas a lo largo de la tarea (Yao et al., 2023).
La observación posterior a cada acción es indispensable porque una acción puede no producir el resultado esperado. Puede ocurrir que un botón esté deshabilitado, que una solicitud falle o que el archivo se guarde en otra ubicación. Un agente que repite el plan original sin incorporar el estado nuevo sigue un guion rígido. El agente debe comparar lo que esperaba que ocurriera con lo que observó y ajustar a esa diferencia su acción siguiente. La información con que se actúa tiene una vigencia limitada. En una interfaz gráfica la posición de un elemento puede cambiar después de una operación; en un servicio estructurado, otra persona puede haber actualizado la versión del documento. Reutilizar referencias obsoletas puede llevar a editar el objeto equivocado o a sobrescribir cambios recientes. La gestión del estado incluye saber cuándo hay que renovar una observación antes de continuar.
El ciclo necesita también condiciones de término. Si el objetivo es dejar disponible un archivo, iniciar la carga es apenas el primer paso; falta comprobar que el archivo existe en el destino y que su contenido es el previsto. Cuando el servicio devuelve un identificador de tarea, puede ser necesario consultar más tarde su finalización. La evidencia suficiente varía entre operaciones. No todas requieren una inspección visual, aunque todas necesitan un criterio de éxito adecuado.
Un plan útil permanece revisable y puede señalar las dependencias próximas sin fijar de antemano cada detalle de un entorno cambiante. Ante un error, el agente debe diagnosticarlo antes de repetir acciones. Según lo que encuentre, unas veces convendrá cambiar de herramienta y otras corregir los argumentos o detenerse por falta de acceso, con el procedimiento ajustado a la evidencia y sin abandonar el objetivo.
Dependencias, trabajo acumulado y cambios concurrentes
Las tareas largas contienen dependencias. No se puede verificar una página antes de construirla ni citar un documento que todavía no se ha localizado. Otras operaciones son independientes; consultar dos fuentes distintas al mismo tiempo puede acelerar una revisión sin alterar sus resultados. Algunas acciones, por último, compiten por el mismo estado, como dos ediciones simultáneas de un documento que pueden sobrescribirse entre sí. Reconocer esa estructura ayuda a organizar el trabajo sin confundir simultaneidad con progreso. La rapidez ganada al superponer trabajo se pierde si el resultado queda inconsistente o ya no puede saberse qué modificación quedó vigente. La secuencia correcta se deduce de las relaciones entre resultados, que una lista de acciones de apariencia razonable puede pasar por alto.
Hay planes que fracasan por omitir una dependencia oculta. Convertir un manuscrito con fórmulas requiere un mecanismo que preserve o renderice esas expresiones; si esa necesidad se descubre al final, habrá que rehacer parte del trabajo. La lectura inicial debe buscar las condiciones que cambian la implementación, además de confirmar que el archivo lleva el título esperado.
Durante una tarea extensa, el estado acumulado necesita una representación durable. Puede incluir archivos terminados, decisiones tomadas, versiones de fuentes y pendientes concretos. Para mantener la continuidad basta con conservar aquello que permite reanudar sin repetir acciones ni contradecir restricciones, sin necesidad de guardar cada frase del diálogo. Un resumen de trabajo útil separa los hechos verificados de las hipótesis y conserva los identificadores que evitan confundir objetos similares. Esa compresión puede, sin embargo, introducir pérdidas. Si «la lectura está redactado pero falta comprobar la extensión» se resume como «capítulo terminado», la etapa siguiente parte de una premisa falsa. Por eso cada etiqueta de estado, sea borrador, validado o publicado, debería corresponder a una condición explícita y verificable.
El trabajo acumulado debe protegerse también frente a interrupciones. Guardar resultados parciales permite recuperarlos sin recrearlos de memoria y deja constancia exacta de qué se produjo y con qué fuentes. Un agente que solo mantiene una narración de sus avances puede dar por guardado un contenido que planeaba generar.
Los mecanismos de control de versiones ayudan a detectar cambios concurrentes. Antes de reemplazar un archivo, una operación puede comprobar que la versión actual coincide con la que se leyó. Si alguien lo modificó entretanto, el sistema debe revisar la nueva versión y resolver el conflicto sin forzar una escritura ciega. Con esa comprobación se conserva una relación verificable entre la evidencia usada para decidir y el estado sobre el que se actúa. Cuando una operación modifica varios elementos relacionados, también es útil separar la preparación de la aplicación. Actualizar un índice antes de que existan sus páginas puede dejar enlaces rotos; el contenido que nunca se incorpora a la navegación quizá quede fuera del alcance de muchos lectores. La coordinación tiene que atender al conjunto de propiedades que definen el objetivo, además del éxito aislado de cada llamada.
Estas cuestiones no exigen atribuir al modelo una capacidad extraordinaria de planificación. Pueden resolverse combinando procedimientos explícitos, estados bien definidos y decisiones lingüísticas acotadas. Quizá la fortaleza del sistema resida precisamente en distribuir las funciones, de modo que el modelo interprete y proponga mientras otros componentes validen versiones y apliquen los cambios de manera consistente. Evaluar el agente completo permite reconocer ese reparto de funciones sin atribuir al generador de texto todo el mérito o toda la responsabilidad por los errores.
Errores, reintentos y efectos duplicados
Un error de comunicación no siempre significa que la acción no ocurrió. Ocurre a veces que un servicio guarda un documento y falla al devolver la confirmación; si el agente repite entonces la operación de manera automática, puede crear duplicados. Ante esa incertidumbre sobre el estado procede una comprobación dirigida, como buscar el resultado o consultar el identificador correspondiente, antes de dar por supuesto el fracaso. Esta precaución pesa sobre todo en las acciones que producen efectos externos. Para gestionar los reintentos es útil la noción de idempotencia. Una operación es idempotente cuando repetirla en las mismas condiciones no añade efectos nuevos después de la primera aplicación. Establecer un valor concreto puede ser idempotente, cosa que por lo general no ocurre al añadir otro registro. El agente no necesita usar siempre ese término, aunque el sistema sí debe distinguir ambos casos. Para la escritura o el envío, una estrategia segura en la lectura puede resultar inadecuada.
Las operaciones también pueden completarse a medias. Un lote de archivos puede guardar diecinueve y fallar en uno. Cuando la interfaz informa resultados por elemento, hay que revisarlos además del indicador global de éxito. Repetir todo el lote podría duplicar lo ya completado. El procedimiento debe registrar qué objetos cambiaron, cuáles no y cuáles quedaron en un estado incierto. Un registro exacto evita tanto las omisiones como el trabajo innecesario.
La corrección debería dirigirse al problema observado. Repetir sin cambios una llamada rechazada por un campo inválido no aporta información, aunque ante un fallo temporal un reintento limitado sí puede tener sentido. Cuando falta autorización, buscar otra ruta para eludir el control no es una solución legítima. El agente debe leer en los errores evidencia sobre las condiciones de operación, sin tomarlos por obstáculos que justifiquen cualquier alternativa disponible.
La comunicación al usuario debe recoger estas diferencias. «No pude confirmar si se guardó» y «no se guardó» describen situaciones distintas. Informar que «se completaron diecinueve archivos y uno sigue pendiente» es más útil que declarar un fracaso global, ya que con una formulación imprecisa la persona podría repetir acciones o confiar en un resultado inexistente.
Permisos, alcance y acciones con consecuencias
Tener acceso a una herramienta es distinto de estar autorizado para usarla con cualquier fin. Un agente capaz de enviar mensajes puede carecer de una instrucción que autorice el envío, o estar autorizado a editar un documento sin permiso para ampliar su audiencia. Separar capacidad y autorización impide que la disponibilidad de una interfaz amplíe en silencio el encargo.
A veces la autorización ya es suficientemente concreta desde el comienzo. Si la persona pide publicar un conjunto identificado de textos en un sitio determinado, los pasos necesarios para esa publicación pueden darse por incluidos en la petición. Solicitar confirmación para cada operación rutinaria añadiría fricción y podría incluso impedir el objetivo. Una acción nueva que cambia los destinatarios, los compromisos o la exposición de la información sí puede requerir una aclaración. La decisión debería atender al alcance real de cada acción, sin recurrir a fórmulas automáticas de cautela.
Cuando la confirmación es necesaria, debería recaer sobre un resultado revisable. Preguntar «¿procedo?» antes de haber preparado nada obliga al usuario a aprobar una abstracción. Es más informativo mostrarle qué se publicará, dónde y con qué cambios relevantes. Si la preparación reversible se adelanta, la decisión final versa sobre un objeto concreto y la persona ejerce el control sin cargar con cada detalle técnico.
Los permisos deberían aplicarse también en componentes externos al modelo. Las restricciones de acceso, la validación de argumentos y la separación entre lectura y escritura hacen que la seguridad dependa menos de que el generador interprete siempre bien cada instrucción. Un sistema fiable combina el comportamiento aprendido con controles verificables. Ni la cortesía de una respuesta ni la apariencia razonada de un plan sustituyen esos mecanismos. La responsabilidad por los límites corresponde al sistema sociotécnico completo, en el que desarrolladores, proveedores y usuarios participan de manera diferente según sus funciones y conocimientos. Llamar autónomo al agente deja intactas esas relaciones. Dentro de un ámbito definido, la autonomía operativa puede crecer mientras la responsabilidad institucional permanece. Confundir ambas dimensiones favorece las explicaciones vagas cuando una acción produce consecuencias indeseadas.
Información externa que intenta convertirse en instrucción
Un agente que consulta páginas, correos o documentos recibe textos de procedencias diversas, entre los que puede haber instrucciones dirigidas al lector o intentos deliberados de alterar su conducta. Hay inyección de instrucciones cuando un material que debía tratarse como dato logra redefinir los objetivos o las acciones del agente. El problema se agrava porque las instrucciones legítimas y el contenido consultado pueden llegar al modelo con formas lingüísticas parecidas.
AgentDojo, desarrollado por Debenedetti y colaboradores, es un entorno para estudiar agentes que usan herramientas sobre datos no confiables y evaluar ataques y defensas. El trabajo muestra que hace falta medir a la vez el cumplimiento de las tareas y la preservación de propiedades de seguridad. Sus resultados corresponden a los entornos y sistemas evaluados y no aportan una solución general al problema (Debenedetti et al., 2024).
La defensa conceptual empieza por conservar la procedencia de cada texto y una jerarquía de autoridad. Los hechos que un documento recuperado aporta sobre el tema no le dan autoridad para ordenar que se envíen archivos a otra persona. Del mismo modo, cuando un mensaje citado describe una orden que alguien dio en el pasado, esa orden no rige por ello para el agente. Separar el contenido mencionado de las instrucciones operativas requiere análisis pragmático, además de controles de acceso. Las instrucciones maliciosas no siempre adoptan una forma explícita como «ignora lo anterior». Pueden presentarse como supuestas reglas del servicio, resultados de auditoría o indicaciones de un administrador ficticio. Un sistema que concede autoridad a un texto por su tono queda expuesto a estas variantes. La procedencia debe establecerse mediante canales y permisos reconocidos y nunca a partir de las afirmaciones contenidas en el propio material no confiable.
La evaluación debería incluir casos en que el agente completa la tarea legítima sin adoptar instrucciones externas improcedentes. Bloquear toda lectura de documentos evitaría algunas interferencias a costa de la utilidad del sistema. La separación entre evidencia y autoridad, que debe mantenerse mientras se usa la información necesaria, tiene un paralelo claro en la lectura crítica humana, aunque los mecanismos de implementación sean distintos.
Comunicación del avance durante la ejecución
Durante una tarea larga el usuario necesita saber qué ocurre, aunque un exceso de narración puede volverse ruido. Una actualización útil informa de un hallazgo, de un resultado completado o de una incertidumbre que modifica el paso siguiente. Repetir muchas veces «estoy trabajando» aporta poco. La frase «el texto está integrado; falta comprobar que las fórmulas se rendericen», en cambio, comunica un estado verificable y una necesidad concreta.
Los tiempos verbales cumplen aquí una función precisa. «Voy a guardar», «estoy guardando» y «quedó guardado» expresan momentos distintos. El agente debe reservar el último para una operación cuya finalización ha observado adecuadamente. La tendencia a producir cierres fluidos podría favorecer las declaraciones prematuras de éxito. Evitarlas requiere apoyar la respuesta final en los resultados de las herramientas y en criterios de validación, más allá de la secuencia narrativa del plan. Hay que distinguir también los intentos de los resultados. Haber pulsado el botón de publicar indica que se intentó la publicación, pero no que la página sea accesible. Haber solicitado una búsqueda tampoco indica que se revisaran fuentes suficientes. Las operaciones rutinarias admiten un resumen, pero las limitaciones materiales tienen que constar en el informe. Si una parte quedó sin completar, la persona necesita saber cuál y por qué, sobre todo cuando el resto del resultado puede utilizarse de manera independiente.
La transparencia que se pide es acotada. Sin revelar todo el funcionamiento interno ni presentar largas trazas de razonamiento, el informe ha de concentrarse en la evidencia pertinente, como el enlace al artefacto, el alcance de la comprobación y los estados que siguen inciertos. Una explicación verbal de por qué el agente creyó haber terminado no sustituye el resultado. La relación entre afirmación y evidencia debe ser tan estricta en un informe de trabajo como en una respuesta factual.
En las tareas colaborativas, los mensajes que el usuario envía durante la ejecución suelen modificar el encargo en curso. Una aclaración de estilo no obliga, en principio, a abandonar el objetivo original. El agente debe integrar la nueva restricción y continuar, salvo que haya cancelación o incompatibilidad clara. Mantener esa continuidad requiere interpretar cada mensaje como un acto conversacional dentro del encargo, sin tratarlo como una tarea aislada que borra los compromisos anteriores.
Evaluar agentes por cambios de estado
Los agentes deben evaluarse por los resultados que dejan en el entorno, además de por la calidad de sus respuestas. WebArena propuso tareas sobre sitios web funcionales y evaluó la corrección de los resultados en escenarios de interacción; AgentBench extendió la evaluación a entornos de distinto tipo. Estas propuestas ayudan a estudiar secuencias de decisiones en las que un error temprano puede afectar a los pasos posteriores y donde la respuesta verbal final es insuficiente para determinar si hubo éxito (Zhou et al., 2024; Liu et al., 2024).
Un criterio de éxito puede comprobar si el archivo correcto quedó en la carpeta esperada, si una tabla contiene los valores solicitados o si una página refleja el cambio autorizado. Ha de evitar también premiar estados que solo en apariencia equivalen al buscado, para lo cual necesita identificar los objetos y las propiedades relevantes. Un documento con el título adecuado y sin contenido deja incumplida una tarea de redacción; modificar una copia equivocada tampoco satisface una edición sobre el original.
Las métricas deberían incluir el costo y los efectos secundarios cuando corresponda. Dos agentes pueden alcanzar el mismo estado final aunque uno de ellos haya realizado muchas operaciones innecesarias o introducido cambios ajenos al objetivo. Un criterio que solo comprueba el resultado deseado podría pasar por alto esos daños. La evaluación tiene que considerar también qué se preservó y qué otras modificaciones ocurrieron, de acuerdo con el alcance autorizado. En el análisis de fallos pueden separarse la interpretación de la petición, la selección de la herramienta, la construcción de argumentos, la lectura de resultados y el mantenimiento del estado. Estas categorías se superponen en parte, pero orientan las correcciones. Un fallo de referencia, por ejemplo, no se corrige igual que uno causado por una herramienta inestable. Esa clasificación ayuda a mejorar componentes concretos sin atribuir cada problema a una falta general de inteligencia.
Consistencia entre intentos repetidos
Cuando un agente resuelve una tarea una vez y falla en repeticiones similares, integrarlo en un flujo de trabajo estable puede resultar difícil. El benchmark τ-bench estudió interacciones sujetas a reglas de dominio entre usuario, agente y herramientas e incorporó medidas de consistencia a lo largo de varios ensayos. El enfoque recuerda que el éxito ocasional y el comportamiento fiable son propiedades diferentes (Yao et al., 2024).
La notación distingue dos preguntas. La medida pass@k pregunta si al menos uno de k intentos tiene éxito, mientras que pass^k exige que lo tengan todos. Consideremos un ejemplo hipotético con intentos independientes y una probabilidad constante de éxito de 0,8. Con cinco intentos, la primera medida da 1 − (1 − 0,8)⁵ = 0,99968 y la segunda, 0,8⁵ = 0,32768. Con esos valores, un sistema conseguiría casi siempre algún resultado correcto y mostraría al mismo tiempo poca consistencia. Estas cuentas ilustran una sola tarea bajo esos supuestos y no sustituyen los estimadores que emplea τ-bench ni su promedio por tareas (Yao et al., 2024).
Traducción de expresiones humanas a argumentos exactos
Las herramientas suelen exigir valores precisos allí donde el lenguaje admite referencias flexibles. «El viernes», «la versión nueva» o «el documento de Ana» pueden bastar entre personas que comparten contexto, pero una operación necesita una fecha o un identificador inequívoco. La traducción debe conservar el significado de la petición y apoyarse en la evidencia disponible. Un formato correcto no repara una referencia mal resuelta. Una fecha válida escrita en el campo equivocado sigue siendo un error de acción.
Las fechas muestran bien la dificultad. «Mañana por la mañana» depende del momento y del lugar desde los que habla la persona. Si el sistema trabaja con otra zona horaria, es posible que seleccione un día diferente. Una hora sin zona puede bastar para un archivo local y resultar ambigua para una reunión internacional. El agente debe determinar qué precisión requiere la operación y evitar que una expresión contextual se convierta, sin aviso, en un valor que cambia el propósito del usuario. Con los posesivos y las descripciones ocurre algo semejante. «Mi último borrador» puede designar el documento modificado más recientemente, una versión marcada como final o el archivo que se acaba de adjuntar. La conversación y los metadatos pueden resolver esa ambigüedad. Cuando no lo hacen, una pregunta breve es preferible a modificar un objeto distinto, siempre que se limite a la ambigüedad material y deje al agente la investigación que puede realizar por su cuenta.
Estos casos muestran que el uso de herramientas convierte fenómenos clásicos de la pragmática y de la referencia en condiciones de ejecución. La deixis, las presuposiciones y las relaciones anafóricas determinan aquí qué objeto cambia, además de cómo se interpreta una respuesta. La evaluación de agentes debería incluir, por ello, referencias que haya que resolver a lo largo de varios turnos, con cambios de tema y con versiones competidoras. Las pruebas de sintaxis de argumentos también hacen falta, aunque no cubren ese nivel de adecuación.
Un encargo editorial de principio a fin
Imaginemos un agente que debe incorporar varios capítulos a una biblioteca digital. Empieza por identificar los archivos y el índice vigente. Comprueba luego que los títulos correspondan, convierte el formato y conserva la bibliografía, las tablas y las expresiones matemáticas. Durante el proceso registra qué capítulos están integrados y cuáles siguen pendientes. La publicación solo se da por terminada cuando los contenidos están disponibles y los enlaces principales funcionan.
Una primera dificultad aparece cuando una ecuación se muestra como texto sin formato. Basta entonces con localizar el problema de representación, corregirlo y comprobar el resultado, sin reinterpretar toda la teoría de la lectura. Distinto es el caso de una afirmación dudosa en el contenido. Como el encargo de publicación puede excluir una revisión sustantiva amplia, el agente debe separar la reparación técnica necesaria de una modificación editorial que alteraría lo que el autor afirma.
Otra dificultad surge cuando la actualización del sitio ha terminado y el servicio de despliegue todavía está trabajando. El agente mantiene el estado como pendiente y consulta después la finalización. Declarar el éxito antes de esa comprobación confundiría la preparación con la disponibilidad pública. Si el despliegue falla, el manuscrito ya integrado sigue siendo trabajo real que hay que preservar, aunque el objetivo completo continúe sin cumplirse.
Al terminar, el informe puede ser breve, porque detrás de él hay evidencia suficiente. Indica qué capítulos se publicaron y dónde pueden consultarse, con las comprobaciones relevantes que superaron. Buena parte de la dificultad y del valor de un agente útil está en la doble traducción que realiza, desde el lenguaje de la petición hasta las acciones verificables sobre el entorno y desde los resultados de esas acciones hasta un informe preciso.
Referencias
Debenedetti, E., Zhang, J., Balunović, M., Beurer-Kellner, L., Fischer, M., y Tramèr, F. (2024). AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. https://arxiv.org/abs/2406.13352
Liu, X., et al. (2024). AgentBench: Evaluating LLMs as Agents. En International Conference on Learning Representations. https://proceedings.iclr.cc/paper_files/paper/2024/hash/e9df36b21ff4ee211a8b71ee8b7e9f57-Abstract-Conference.html
Schick, T., et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. Advances in Neural Information Processing Systems. https://arxiv.org/abs/2302.04761
Yao, S., et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR; prepublicación inicial de 2022. https://arxiv.org/abs/2210.03629
Yao, S., Shinn, N., Razavi, P., y Narasimhan, K. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. https://arxiv.org/abs/2406.12045
Zhou, S., et al. (2024). WebArena: A Realistic Web Environment for Building Autonomous Agents. En International Conference on Learning Representations. https://proceedings.iclr.cc/paper_files/paper/2024/hash/4410c0711e9154a7a2d26f9b3816d1ef-Abstract-Conference.html