desvarío aleatorio sobre dónde estamos con los agentes de IA:

algunos no los llaman agentes, sino "agentes de flujo de trabajo" con flujos deterministas están en todas partes y funcionan. cualquiera puede construir agentes de flujo de trabajo simples, incluso comenzando sin herramientas de código como Zapier y n8n. los agentes de flujo de trabajo complejos requieren mucho más pensamiento para construir de manera confiable 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 por sí solo, y también ser una gran estrategia de entrada al mercado para expandirse más tarde a otros flujos de trabajo o a un trabajo más autónomo.

más agentes dinámicos/autónomos están comenzando a trabajar y son útiles para la investigación (especialmente si están basados en la web) y la codificación. son menos fiables una vez que comienzas a añadir más fuentes de datos (por ejemplo, APIs). los agentes de solo lectura se sienten seguros y son fáciles de probar, pero dejar que los agentes autónomos tomen acción (escriban) da miedo. (una idea aleatoria sobre esto: sería genial si herramientas como un CRM te permitieran "forkear" un espejo de desarrollo y ejecutar experimentos de automatización que puedas revertir o fusionar de nuevo.)

los agentes dinámicos funcionan bien cuando pueden (1) crear y seguir un buen plan y (2) ejecutar tareas correctamente, mientras (3) encuentran el contexto adecuado para alimentar cada paso (tanto en la planificación como en cada tarea). finalmente, necesita (4) reflexionar en el camino (ya sea con o sin la intervención humana) para poder ajustar el plan de manera adecuada, y también mejorar la forma en que ejecuta tareas fallidas o de bajo rendimiento.

planificación de tareas: las capacidades de razonamiento de los LLM funcionan bien para listas de tareas simples que no requieren contexto privado (como investigación profunda, solo una serie de búsquedas en la web mientras se resume). si quieres investigar muchas entidades, la investigación profunda no funciona tan bien porque la gestión de listas de tareas es relativamente básica. las herramientas de IA basadas en hojas de cálculo funcionan mejor para investigar muchas entidades porque efectivamente estás delegando la gestión de tareas a la hoja de cálculo, ya que pasar largas listas de tareas entre indicaciones no funciona aquí. la gestión de tareas en agentes de codificación funciona con problemas simples, código simple, o cuando estás comenzando desde cero. una vez que entras en proyectos preexistentes más complejos, son menos confiables - y los desarrolladores aumentan la confiabilidad documentando cómo funciona y está organizado su código (archivos .md) lo que permite al agente construir listas de tareas mejor informadas. el código complejo requiere más documentos y eventualmente extraer dinámicamente solo el contexto relevante de esos documentos. muchas personas/empresas tienen opiniones fuertes no documentadas sobre el orden/enfoque/herramientas correctas para abordar un proyecto, y necesitamos más enfoques para documentar esto de manera anticipada y sobre la marcha. otra razón por la que los agentes de codificación y de investigación 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 (requiriendo autenticación y comprensión de cómo usar la API, y la estructura de datos subyacente - que puede ser única como en un CRM o base de datos con tablas/columnas personalizadas), razonamiento LLM (por ejemplo, resumir), una combinación, e incluso agentes de flujo de trabajo*. un agente de investigación es realmente solo búsqueda en la web y resumir en un bucle. los agentes de codificación son CRUD en tu base de código, y tal vez búsqueda en la web para aprender sobre APIs. la autenticación y el acceso básico a la API parecen estar resueltos (los MCPs encajan aquí), pero me gustaría ver más sobre el contexto específico de la herramienta (preguntar al usuario, pero también analizar al momento de la conexión inicial, profundizar en los datos existentes para entender cómo se usa la herramienta, cómo está estructurada la data, para qué escenarios/proyectos usamos la herramienta). los errores/reflexión/retroalimentación necesitan 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/documentar esto de alguna manera para ejecutar bien las tareas.

contexto: imagina ser un nuevo empleado en una empresa. Aprendes mucho durante la incorporación (y cuanto mejor sea la incorporación, más efectivo serás desde el principio), y luego está el aprendizaje en el trabajo, que se descompone en aprender de la experiencia de la organización ("así es como hacemos las cosas") y aprender de la propia experiencia, siendo la primera más predominante en organizaciones grandes. La gestión del contexto es similar. Hay capas de contexto como meta (usuario/empresa), específico de proyecto/departamento, específico de tarea, específico de herramienta, etc. Hemos evolucionado de simples indicaciones del sistema a estrategias híbridas de RAG (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, lo cual vemos en las primeras versiones de hoy, pero hay mucho margen de mejora. Este no es meramente un problema técnico, sino también un problema empresarial, ya que básicamente necesitas crear un documento de incorporación que cubra cada escenario que esperas. A medida que los proyectos se vuelven más complicados, se requiere más reflexión para podar correctamente el contexto, de modo que solo se incluya información relevante en la indicación, minimizando el contexto irrelevante.

reflexión: tenemos herramientas de monitoreo de agentes que cubren los costos de LLM/api, observación, pero asignar éxito/fracaso es un desafío - una área donde los agentes de codificación tienen una ventaja sobre otros es una forma determinista de notar fallos (a través de pruebas del código). para muchas otras tareas agenciales, todavía estamos descubriendo la manera correcta de recopilar la entrada humana para mejorar la salida futura. hasta donde sé, la reflexión hoy es con humanos en el bucle, donde la retroalimentación se está alimentando en gran medida a los desarrolladores humanos para mejorar el agente, pero el desbloqueo llega cuando descubrimos cómo convertir la reflexión en auto-mejora - donde el agente toma ideas de los fracasos en la generación de listas de tareas y la ejecución de tareas para hacerlo mejor la próxima vez. básicamente, la reflexión necesita convertirse en un contexto bien organizado que pueda ser incorporado en los prompts cuando y solo cuando sea relevante. esto evoluciona en el ajuste fino de partes del agente, y luego en entornos de RL agenciales - todavía se siente bastante temprano aquí.

*anteriormente mencioné la entrega de tareas a agentes de flujo de trabajo, lo cual comienza a tener sentido cuando tu agente se beneficiaría de no tener agentes de flujo de trabajo como herramientas (en lugar de tener que resolver una lista de tareas conocida cada vez) o cuando tu sistema es lo suficientemente complicado como para que agentes especializados con contexto y herramientas especializadas funcionen mejor. O si estás aprovechando agentes construidos por otras personas (un patrón que he comenzado a ver aquí son los puntos finales de API de lenguaje natural para facilitar la colaboración entre agentes).

si tuviéramos la calidad del modelo de hoy con una ventana de contenido infinita (sin degradación en la calidad), computación infinita, almacenamiento infinito, acceso a navegador y un método de pago, un solo bucle de LLM probablemente sería suficiente para hacer mucho el punto del punto sin sentido anterior (nada es infinito) es que la orquestación de agentes se trata en gran medida de gestionar limitaciones mediante la arquitectura de formas para descargar trabajo del LLM a través de estructura y código.

los agentes en producción vienen en varias modalidades: como herramientas internas, como un producto independiente que combina varias herramientas, y como una característica integrada en una herramienta principal. pueden ser genéricos o especializados. los agentes de chat, voz y de fondo parecen ser la interfaz de usuario más común para activar flujos agenticos.

¿Qué más me falta?