Reflexiones aleatorias sobre el estado actual de los agentes de IA:
Algunos no los llaman agentes, pero los "agentes de flujo de trabajo" con flujos deterministas están por todas partes y funcionan. Cualquiera puede crear agentes de flujo de trabajo sencillos, incluso con herramientas sin código como Zapier y n8n. Los agentes de flujo de trabajo complejos requieren mucha más planificación para crearlos de forma fiable y eficiente. Un flujo de trabajo complejo para un caso de uso común y valioso, con integraciones relevantes incorporadas, puede funcionar como un negocio independiente y, además, ser una excelente estrategia de comercialización para expandirse posteriormente a otros flujos de trabajo o a un trabajo más autónomo.
Los agentes más dinámicos/autónomos están empezando a funcionar y resultan útiles para la investigación (sobre todo si son web) y la programación. Sin embargo, pierden fiabilidad al añadir más fuentes de datos (por ejemplo, API). Los agentes de solo lectura parecen seguros y fáciles de probar, pero permitir que los agentes autónomos actúen (escriban) genera inquietud. (Una idea al respecto: sería genial que herramientas como un CRM permitieran crear una copia de seguridad de un repositorio de desarrollo y ejecutar experimentos de automatización que luego se pudieran revertir o integrar).
Los agentes dinámicos funcionan bien cuando pueden (1) crear y dar seguimiento a un buen plan y (2) ejecutar las tareas correctamente, a la vez que (3) encuentran el contexto adecuado para cada paso (tanto en la planificación como en cada tarea). Finalmente, necesitan (4) reflexionar durante el proceso (con o sin intervención humana) para ajustar el plan según corresponda y mejorar la ejecución de tareas fallidas o con bajo rendimiento.
Planificación de tareas: capacidades de razonamiento de llm Funcionan bien para listas de tareas sencillas que no requieren contexto privado (como una investigación exhaustiva o una serie de búsquedas web con resumen). Si se desea investigar muchas entidades, la investigación exhaustiva no funciona tan bien porque la gestión de la lista de tareas es relativamente básica. Las herramientas de IA basadas en hojas de cálculo funcionan mejor para investigar muchas entidades porque se delega la gestión de tareas a la hoja de cálculo, ya que pasar listas de tareas largas entre solicitudes no funciona aquí. La gestión de tareas en los agentes de programación funciona con problemas sencillos, código simple o cuando se empieza desde cero. Una vez que se trabaja en proyectos preexistentes más complejos, son menos fiables, y los desarrolladores aumentan la fiabilidad documentando cómo funciona y está organizado su código (archivos .md), lo que permite al agente crear listas de tareas mejor informadas. El código complejo requiere más documentación y, eventualmente, extraer dinámicamente solo el contexto relevante de esos documentos. Muchas personas y empresas tienen opiniones firmes, pero no documentadas, sobre el orden, el enfoque y las herramientas correctas para abordar un proyecto, y necesitamos más enfoques para documentar esto de antemano y sobre la marcha. Otra razón por la que los agentes de investigación basados en codificación y en la web funcionan bien es que todos utilizan el mismo conjunto de herramientas, por lo que no hay necesidad de “aprender” a usar esas herramientas (más sobre esto a continuación).
Ejecución de tareas: Las tareas suelen ser llamadas a la API (que requieren autenticación y conocimiento de su uso, así como de la estructura de datos subyacente, que puede ser única, como en un CRM o una base de datos con tablas/columnas personalizadas), razonamiento LLM (por ejemplo, resumen), una combinación de ambos e incluso agentes de flujo de trabajo*. Un agente de investigación es básicamente una búsqueda web y un resumen iterativo. Los agentes de codificación realizan operaciones CRUD en la base de código y, posiblemente, búsquedas web para aprender sobre las API. La autenticación y el acceso básico a la API parecen estar resueltos (los MCP encajan aquí), pero me gustaría ver más contexto específico de la herramienta (preguntar al usuario, pero también analizar la conexión inicial, profundizar en los datos existentes para comprender cómo se usa la herramienta, cómo se estructuran los datos y para qué escenarios/proyectos la usamos). Los errores, las reflexiones y la retroalimentación deben convertirse en aprendizajes organizados que se retroalimenten como contexto cuando sea relevante. Las mismas herramientas pueden usarse para diferentes propósitos y de diferentes maneras entre organizaciones, y necesitamos capturar y documentar esto de alguna manera para ejecutar las tareas correctamente.
Contexto: Imagina que eres un nuevo empleado en una empresa. Aprendes mucho durante la inducción (y cuanto mejor sea la inducción, más eficaz serás desde el principio), y luego viene el aprendizaje en el trabajo, que se divide en aprender de la experiencia de la organización ("así es como hacemos las cosas") y aprender de la propia experiencia; lo primero predomina en las grandes organizaciones. La gestión del contexto es similar. Hay capas de contexto como metadatos (usuario/empresa), específicos del proyecto/departamento, específicos de la tarea, específicos de la herramienta, etc. Hemos evolucionado desde simples avisos del sistema hasta estrategias RAG híbridas (vector, palabra clave, gráfico), pero más allá de tener los datos/contexto, necesitamos orientación sobre cuándo y cómo recuperar el contexto, que ya vemos en sus primeras versiones, pero con mucho margen de mejora. Esto no es solo un problema técnico, sino también un problema de negocio, ya que básicamente necesitas crear un documento de inducción que cubra todos los escenarios posibles. A medida que los proyectos se vuelven más complejos, se requiere más reflexión para depurar correctamente el contexto, de modo que solo se incluya información relevante en los avisos, minimizando al mismo tiempo el contexto irrelevante.
Reflexión: Contamos con herramientas de monitorización de agentes que cubren los costes de LLM/API y la observación, pero determinar el éxito o el fracaso sigue siendo un desafío. Una ventaja de los agentes de programación sobre otros sistemas reside en la capacidad de detectar fallos de forma determinista (mediante pruebas del código). Para muchas otras tareas agentivas, aún estamos buscando la mejor manera de recopilar información humana para mejorar los resultados futuros. Hasta donde sé, la reflexión actual implica la intervención humana, donde la retroalimentación se proporciona principalmente a los desarrolladores para mejorar el agente. Sin embargo, el verdadero avance se producirá cuando logremos convertir la reflexión en autoaprendizaje, donde el agente aprenda de los fallos en la generación y ejecución de listas de tareas para mejorar en el futuro. Básicamente, la reflexión debe transformarse en un contexto bien organizado que pueda utilizarse en las solicitudes cuando y solo cuando sea relevante. Esto evoluciona hacia el ajuste fino de componentes del agente y, posteriormente, hacia entornos de aprendizaje por refuerzo agentivo. Aún estamos en una fase muy temprana de este proceso.
Anteriormente mencioné la delegación de tareas a agentes de flujo de trabajo, lo cual cobra sentido cuando un agente se beneficia al no depender de agentes de flujo de trabajo (en lugar de tener que procesar una lista de tareas predefinida cada vez) o cuando el sistema es lo suficientemente complejo como para que agentes especializados con contexto y herramientas específicas ofrezcan un mejor rendimiento. También es útil si se utilizan agentes desarrollados por terceros (un patrón que he observado es el uso de API de lenguaje natural para facilitar la colaboración entre agentes).
Si contáramos con la calidad del modelo actual, con una ventana de contenido infinita (sin degradación de la calidad), capacidad de cómputo y almacenamiento ilimitados, acceso a través del navegador y un método de pago, probablemente un solo bucle LLM sería suficiente para lograr mucho. El sentido de la observación anterior (nada es infinito) es que la orquestación de agentes se trata en gran medida de gestionar las limitaciones diseñando formas de descargar trabajo del LLM a través de la estructura y el código.
Los agentes en producción se presentan en diversas modalidades: como herramientas internas, como productos independientes que combinan varias herramientas, o integrados como funcionalidad en una herramienta principal. Pueden ser genéricos o especializados. Los agentes de chat, voz y en segundo plano parecen ser las interfaces de usuario más comunes para activar flujos de agentes.
¿Qué más me estoy perdiendo?