2025 podría ser el año de los agentes de IA, si logran sobrevivir al infierno empresarial

Durante décadas, las empresas han buscado automatizar las tareas administrativas, la entrada de datos, los procesos de facturación y otros flujos de trabajo repetitivos. Pero, a pesar de que el software ha evolucionado, la automatización integral sigue siendo difícil de alcanzar para la mayoría de las empresas. Ahora, con el rápido aumento de los modelos de lenguaje grandes (LLM, por sus siglas en inglés) y la aparición de "agentes de inteligencia artificial" capaces de razonar y actuar de manera autónoma, existe una creciente creencia de que 2025 podría ser el año en que finalmente veamos un avance significativo en la automatización empresarial.

Sam Altman ha declarado públicamente que “en 2025, es posible que veamos a los primeros agentes de IA unirse a la fuerza laboral y cambiar materialmente el resultado de las empresas”, mientras que Marc Benioff está orientando Salesforce hacia “AgentForce” en previsión de un futuro en el que muchos procesos organizacionales se deleguen a agentes especializados. Estas predicciones plantean una pregunta central: ¿pueden los agentes de IA superar los obstáculos complicados de los sistemas empresariales del mundo real? En este artículo, examinaremos las dificultades únicas de la automatización empresarial y exploraremos algunas de las soluciones prometedoras (pero aún en maduración) de la actualidad. También compartiremos pruebas prácticas con un flujo de trabajo aparentemente sencillo en Salesforce (SFDC) (crear un pedido de revendedor para una nueva cuenta) que revela la complejidad que se esconde tras bambalinas.

¿Por qué la automatización empresarial supone un desafío tan grande?

En teoría, automatizar las tareas empresariales parece sencillo: basta con crear un script para iniciar sesión, completar formularios y hacer clic en "Enviar". En la práctica, la complejidad es asombrosa. Las empresas dependen de una gran cantidad de sistemas de registro, como Salesforce, SAP, Oracle y muchas soluciones locales. Cada sistema tiene su propia red de permisos, flujos de autenticación y lógica empresarial personalizada. Además, estos sistemas suelen estar muy personalizados. Es habitual ver interfaces de usuario especializadas, campos de datos adicionales y flujos de trabajo personalizados que difieren de una empresa a otra.

Según una encuesta conjunta de MuleSoft y Deloitte, las grandes empresas pueden utilizar un promedio de 976 sistemas diferentes para respaldar las operaciones diarias ( fuente ). Esta fragmentación significa que una herramienta de automatización debe comunicarse con múltiples sistemas, cada uno con sus propios matices; algunos con API robustas, otros sin ninguna. A menudo, las tareas más simples implican unir datos entre aplicaciones antiguas y heredadas y nuevos servicios basados en la nube. Incluso las plataformas estándar como Salesforce pueden volverse laberínticas una vez que se implementan flujos de trabajo personalizados e integraciones de terceros.

En este contexto, los agentes con tecnología LLM prometen un enfoque más flexible: pueden analizar datos, razonar sobre los pasos siguientes e incluso navegar por interfaces gráficas de usuario complejas, al menos en teoría. Pero, como verá en el siguiente ejemplo, la realidad de lograr que un agente de IA realice incluso un flujo de trabajo básico de Salesforce sin ayuda humana es más complicada de lo que muchos creen.

Un ejemplo práctico: creación de un pedido de revendedor personalizado en Salesforce

La tarea

Imagina que eres un vendedor en una empresa de fabricación de bicicletas que utiliza Salesforce. Acabas de vender una bicicleta Dynamo X1 grande por $5000 a un nuevo revendedor llamado “Northern Trail Cycling”. Tu trabajo es:

1 - Autenticarse en Salesforce (con las credenciales proporcionadas).

2 - Crear una nueva cuenta para el revendedor.

3 - Cree un pedido de revendedor y agregue el artículo de línea (la bicicleta).

4 - Envíe ese pedido a fabricación para su aprobación.

Para una ejecución exitosa, esperamos que el resultado final se vea así:

Parece bastante simple, pero el diablo está en los detalles. La instancia de Salesforce de la empresa está personalizada: utiliza un objeto y un flujo de "pedido de revendedor" personalizados, una función especial de arrastrar y soltar para agregar productos y un paso oculto de "enviar a fabricación" sin etiquetas claras. Probé este escenario utilizando varios enfoques emergentes de automatización impulsados por IA para ver cómo se comparan.

Uso de la computadora por Claude

¿Qué es?

Claude Computer Use es una nueva característica de Anthropic, introducida con Claude 3.5 Sonnet v2 . Lleva el paradigma de llamada de funciones LLM estándar un paso más allá al brindarle a Claude un entorno de escritorio contenedorizado completo para "ver" y "controlar". Puede capturar capturas de pantalla, interpretarlas mediante razonamiento visual/espacial y realizar acciones a nivel de sistema operativo como clics del mouse, desplazamientos y pulsaciones de teclas.

Desde la perspectiva del usuario, le asignas a Claude una tarea de alto nivel (“Iniciar sesión en Salesforce y crear este pedido de revendedor”), y Claude intenta hacer exactamente eso. Repite una secuencia de lo siguiente:

1. Capturar una captura de pantalla e interpretarla.
2. Emisión de acciones de UI (clics del mouse, pulsaciones de teclas, comandos bash).
3. Repitiendo hasta que se complete la tarea (o se dé por vencido).

Poniéndolo a prueba

Comencemos con el enfoque más simple de ejecutar la implementación de referencia de Anthropic sin realizar cambios en el mensaje del sistema . Aquí se muestra el comienzo de la interacción, que muestra el mensaje inicial, el plan propuesto por Claude y el escritorio con el que se inicia la interacción.

Al principio, observar el escritorio contenedorizado de Claude fue impresionante. Abrió el navegador, visitó la URL de Salesforce, inició sesión con las credenciales proporcionadas y navegó hasta "Cuentas". Creó sin problemas una nueva cuenta para Bike Production Company , ingresó los detalles correctos en el formulario y luego intentó crear un nuevo pedido de revendedor. Todo iba bien hasta que encontró la interfaz personalizada de arrastrar y soltar para agregar la bicicleta. El sistema se quedó bloqueado al intentar realizar una función de arrastrar y soltar basada en píxeles.

Después de varios intentos fallidos, intentó encontrar un método alternativo (como un botón oculto "Agregar elemento"). Su primer intento con el botón "Editar" no tuvo éxito.

“Observo que en el cuadro de diálogo de edición no hay una forma clara de agregar productos. Permítanme probar un enfoque diferente haciendo clic en el menú desplegable Pedidos de revendedor para ver si hay otras opciones”.

Finalmente, encontró su camino al descubrir una forma de agregar nuevos elementos a través de la pestaña “relacionados”, pero falló cuando los activadores dinámicos de la aplicación no actualizaron el total del pedido automáticamente. Los desarrolladores de la aplicación SFDC no completaron el desarrollo de esta ruta de código, ya que esperaban que el usuario humano simplemente siguiera el método de arrastrar y soltar. En resumen, el flujo fue diseñado para humanos, no para un agente de IA.

Luego, Claude intentó localizar el botón "Enviar a fabricación", que estaba oculto bajo una pestaña personalizada. Como no tenía conocimiento previo de ese paso, se tambaleó durante varios minutos más. Finalmente, tuve que intervenir, agregar manualmente la bicicleta al pedido y señalarle a Claude el botón correspondiente. Después de aproximadamente 10 minutos y unos 0,80 dólares en costos de uso, el proceso aún no estaba completamente automatizado. Fue fácil ver por qué Anthropic llama a esta función experimental: se necesitan muchas barreras y mejoras del mundo real antes de que Computer Use pueda estar realmente listo para producción.

¿Puede mejorar?

A pesar de sus imperfecciones, el concepto es apasionante. La IA basada en visión para la interacción con GUI está mejorando rápidamente y la curva de costos de inferencia está disminuyendo rápidamente. Un estudio reciente de a16z sugiere que, para el mismo rendimiento, los costos de LLM están disminuyendo aproximadamente 10 veces por año. En principio, las futuras versiones de Claude podrían ser más rápidas, más económicas y más precisas en tareas visuales/espaciales como arrastrar y soltar.

Sin embargo, el problema fundamental sigue siendo que las interfaces de usuario empresariales, especialmente las más antiguas o muy personalizadas, rara vez se crean teniendo en cuenta la automatización. Las interacciones a nivel de píxel son frágiles. Pequeños cambios en el diseño o en las ventanas emergentes dinámicas pueden interrumpir todo el flujo. También hay cada vez más investigaciones sobre los marcos de interfaz gráfica de usuario basados en lo visual, pero convertirlos en aptos para producción para cientos de flujos de trabajo diferentes es una tarea importante.

Navegadores sin interfaz gráfica: cómo evitar la interfaz gráfica de usuario

Un enfoque alternativo es ignorar por completo los “cuadros delimitadores visuales”. Si la aplicación de destino se ejecuta en un navegador web, puede automatizar a nivel de DOM, omitiendo las capturas de pantalla y las interacciones basadas en píxeles. Si bien los navegadores sin interfaz gráfica tradicionales como Playwright y Selenium suelen asociarse con marcos de prueba, está surgiendo una nueva generación de navegadores sin interfaz gráfica centrados en casos de uso de IA. Estas plataformas más nuevas se basan en Playwright y Selenium para permitir interacciones más dinámicas impulsadas por LLM.

Base del navegador

BrowserBase es un ejemplo de ello. Funciona como una plataforma de infraestructura que aloja y escala las sesiones del navegador sin necesidad de que los desarrolladores administren contenedores. El patrón de interacción gira en torno al análisis del contenido HTML de una página en componentes (por ejemplo, formularios, botones) asignados a sus xPaths y al paso de esta estructura a un LLM de su elección. El LLM luego genera el siguiente conjunto de código Playwright para ejecutar, lo que permite la interacción con el DOM a través del código en lugar de los clics tradicionales de la GUI. Debido a que es completamente sin interfaz gráfica, utiliza menos capturas de pantalla o ninguna, lo que mantiene la longitud del contexto corta y la latencia más baja que un enfoque de "entorno de escritorio" completo.

Más recientemente, BrowserBase lanzó su biblioteca de código abierto StageHand para facilitar las cosas a los desarrolladores. En el modelo original, las interacciones aún eran muy manuales, lo que requería que los desarrolladores trabajaran con los detalles de bajo nivel del navegador sin interfaz gráfica, incluida la escritura directa del código Playwright y el análisis manual del HTML. Con StageHand, BrowserBase proporciona un mayor nivel de abstracción, lo que permite a los desarrolladores utilizar comandos de lenguaje natural basados en la intención, como "navegar" o "extraer". Este enfoque también incorpora cierto procesamiento para convertir HTML sin procesar en componentes, lo que facilita que el LLM gestione las tareas. Sin embargo, los usuarios aún necesitan crear sus propias capas de orquestación para conectar y administrar los flujos de trabajo, ya que StageHand en sí no ofrece orquestación incorporada.

Para probar BrowserBase, utilicé su área de juegos para desarrolladores, que ofrece una consola para escribir código Playwright y un generador de indicaciones LLM para producir automáticamente esos guiones. La idea es hacer una navegación de varios pasos: iniciar sesión, crear una cuenta, crear un pedido de revendedor. Pero la plataforma espera que organices los pasos tú mismo. Al comenzar con la misma indicación que le di a Claude, BrowserBase tuvo problemas porque no podía razonar en varios pasos. Entonces procedí a proporcionar una indicación en lenguaje natural para cada paso y a observar si el código Playwright generado estaba haciendo lo que se esperaba. En la captura de pantalla a continuación, puedes ver la serie de indicaciones y el código Playwright generado.

En la práctica, me encontré con desajustes ocasionales entre el entorno del navegador de Playground y los formularios HTML que debían completarse. Los botones se representaban de manera extraña, los tiempos de espera se alargaban y los campos del formulario no se cargaban exactamente como se esperaba. A pesar de estos fallos, el código de Playwright generado por LLM logró iniciar sesión, crear una cuenta y completar parcialmente el formulario de pedido del revendedor. Sin embargo, arrastrar y soltar para agregar el artículo fue nuevamente un obstáculo. Pasé unos siete minutos jugando con él antes de darme por vencido. Estaba claro que la plataforma aún no es apta para ese tipo de automatización. Probablemente funcione mejor para casos de uso de raspado web.

Verna del cielo

Skyvern es un enfoque más integral y sin interfaz gráfica que agrega orquestación de forma predeterminada. A diferencia de BrowserBase, que requiere que los usuarios definan y administren los pasos manualmente, Skyvern intenta manejar la orquestación de manera inmediata. En esencia, funciona de manera similar a BrowserBase (como se ve en su código de fuente abierta ), pero también agrega un agente web que puede orquestar y razonar sobre los pasos. Esto incluye un modo de visión opcional que envía capturas de pantalla al LLM junto con los componentes extraídos y sus xPaths para ayudar en la toma de decisiones.

Para abordar las limitaciones de la creación manual de pasos en BrowserBase, decidí probar Skyvern usando su servicio administrado, enfocándome específicamente en el modo de flujo de trabajo. Este modo está diseñado para procesos de varios pasos y quería evaluar qué tan bien funciona con nuestro flujo de trabajo de Salesforce. Desafortunadamente, la ejecución gastó más de 15 pasos de razonamiento y $1 de créditos atascados en el proceso de autenticación de dos factores (2FA). La IP alojada de Skyvern estaba marcada, lo que activaba la 2FA, y no había forma de proporcionar un código manualmente o compartir una cookie para evitar la situación. Esto resalta el desafío continuo de la autenticación en entornos empresariales y subraya por qué están surgiendo empresas emergentes como Anon que se enfocan únicamente en soluciones de autenticación para agentes de IA.

El equipo de Skyvern considera que la plataforma es adecuada para tareas más sencillas y pequeñas, siendo la automatización de formularios de contacto el principal caso de uso admitido. Otros casos de uso potenciales (por ejemplo, trabajos, facturas) todavía figuran como "en formación", lo que indica que la plataforma está comenzando con una automatización centrada en casos de uso simples en lugar de las necesidades más complejas de los flujos de trabajo empresariales. Si bien es prometedor, está claro que Skyvern es más adecuada para escenarios menos intrincados en esta etapa de su desarrollo.

Compensaciones

Los navegadores sin interfaz gráfica evitan las conjeturas a nivel de píxeles, lo que suele generar menos errores y una ejecución más rápida. Pero tan pronto como acceda a funciones avanzadas como arrastrar y soltar o aplicaciones complejas de una sola página, es posible que deba volver al análisis de capturas de pantalla parciales o al código especializado. Los navegadores también pueden encontrarse con la autenticación de dos factores y la inclusión en listas negras de IP. Para las aplicaciones empresariales multiusuario, la autenticación por sí sola puede ser complicada y es posible que aún necesite capas de orquestación personalizadas.

Otra limitación es que estas plataformas dependen de la generación dinámica de código a través de LLM cada vez que se ejecuta el flujo de trabajo. Dado que los LLM son inherentemente no deterministas, el código generado puede variar entre ejecuciones, lo que dificulta la auditoría o verificación de la coherencia. Esta imprevisibilidad puede generar problemas, especialmente en flujos de trabajo sensibles. Si bien el almacenamiento en caché del código generado parece estar en la hoja de ruta para algunas plataformas, plantea desafíos importantes para los LLM. Incluso cambios menores en el indicador o el procesamiento por lotes durante la inferencia pueden producir resultados completamente diferentes, lo que complica el proceso de almacenamiento en caché.

En general, la navegación sin interfaz gráfica puede ser más barata y más estable que la manipulación completa de la interfaz gráfica de usuario, pero está lejos de ser una solución mágica. Muchas soluciones, como BrowserBase y Skyvern, se centran en casos de uso más específicos (por ejemplo, formularios, extracción de datos) en lugar de ser la "plataforma única para automatizar todo".

Ingeniería inversa de API internas

Un tercer enfoque consiste en omitir la página web por completo interceptando las llamadas de red que se producen cuando haces clic. Si puedes capturar las solicitudes que envía tu navegador, puedes reconstruir esas llamadas en código. En principio, esto evita los pasos complicados basados en la interfaz de usuario y garantiza que estás utilizando la misma lógica de backend que utiliza tu aplicación. Esta tendencia no es completamente nueva, ya que la ingeniería inversa de las API existe desde hace mucho tiempo. Sin embargo, la novedad es incorporar un agente de IA para razonar sobre las solicitudes de red, lo que hace que el proceso sea más inteligente y adaptable.

Hace unos meses, se lanzó en Hackernews un producto llamado Integuru que ha llamado la atención por su enfoque de código abierto y su novedosa metodología. Intrigado por su potencial, decidí probarlo, atraído por su interesante enfoque basado en gráficos y la integración de agentes de IA para razonar sobre las solicitudes de red. La promesa de reducir drásticamente el tiempo y el costo de la automatización lo convirtió en una opción atractiva para explorar.

El repositorio de Integuru es relativamente nuevo, pero promete. En esencia, registra todo el tráfico de red y las cookies en Chromium durante una tarea. Luego crea una representación gráfica de las solicitudes, asignando qué páginas llaman a qué puntos finales. Con este gráfico, realiza un recorrido y lo pasa a un LLM para generar código para cada nodo que reproduce las mismas solicitudes, inyectando sus parámetros dinámicos (como "Bike Production Company") según sea necesario y uniéndolos en función de las dependencias. En teoría, este enfoque podría agilizar significativamente el proceso de automatización.

Sin embargo, en la práctica, no funcionó bien para nuestro caso de uso, principalmente debido a las limitaciones de la ventana de contexto. El flujo podría haber sido demasiado largo para que el LLM lo manejara de manera efectiva. Incluso los intentos de acortar el proceso incorporando cookies de inicio de sesión directamente y comenzando desde la página de inicio no tuvieron éxito. Si bien sospecho que mi clave de API OpenAI de bajo nivel contribuyó a estos problemas, está claro que Integuru todavía está en sus primeras etapas. El potencial está ahí, pero el producto requiere un mayor refinamiento. Sus demostraciones (como la descarga de documentos fiscales de Robinhood) funcionaron mejor en marcos web modernos con flujos más simples. Salesforce, con su interfaz complicada y sus objetos personalizados laberínticos, introdujo errores.

Dicho esto, este método aún no es una solución universal. La necesidad de registrar todos los pasos limita su flexibilidad y se inclina hacia un enfoque más estático de generación de código para flujos específicos con antelación, que recuerda a las herramientas de RPA basadas en reglas que eran populares hace una década. Esto pone de relieve una limitación fundamental: si bien la incorporación del razonamiento de IA a las solicitudes de red es interesante y puede abrir las puertas a la integración con sistemas que no tienen API, sigue siendo más adecuada para tareas más controladas o repetidas en lugar de flujos de trabajo dinámicos y diversos en entornos empresariales.

AgentForce: la solución nativa de Salesforce

Ninguna conversación sobre la automatización impulsada por IA en Salesforce estaría completa sin mencionar AgentForce , la gran apuesta de Marc Benioff por la creación de "agentes" dentro del ecosistema de Salesforce. A diferencia de otras soluciones que probamos anteriormente, que están centradas en los desarrolladores y tienen como objetivo automatizar los flujos de trabajo en varios sistemas, AgentForce se posiciona como una solución integrada de poco código específicamente para Salesforce. Empaqueta muchos componentes juntos y se centra en todo el flujo dentro de la plataforma Salesforce.

La idea es crear agentes que residan completamente en Salesforce y se basen en sus personalizaciones. Los usuarios definen la descripción general de un agente, asignan temas y vinculan acciones asociadas que son flujos prediseñados definidos en código o a través de la interfaz de usuario de Salesforce. Luego, se configuran los permisos, los roles de usuario y las instrucciones para permitir que el agente funcione. En teoría, este concepto permite a las empresas aprovechar sus datos y flujos de trabajo de Salesforce existentes para impulsar la automatización sin una codificación extensa.

Quería probar AgentForce directamente con nuestro ejemplo de pedido de revendedor de bicicletas eléctricas. Lamentablemente, se requiere acceso a Einstein (funciones de IA), que no está disponible en una cuenta de desarrollador gratuita. En su lugar, exploré su área de juegos de 30 minutos con la aplicación ficticia "Coral Beach Resort". La tarea de prueba era configurar un agente para automatizar la creación de una reserva, un proceso algo análogo a un pedido de revendedor en nuestro escenario de bicicletas eléctricas.

La configuración fue bastante compleja y requirió varios pasos: definir permisos, habilitar temas, conectarse a acciones predefinidas, mapear campos de datos y aclarar instrucciones. Si bien se comercializó como una solución de poco código, quedó claro que es necesario un conocimiento significativo de las complejidades de Salesforce. Si la instancia de Salesforce de una empresa carece de campos personalizados bien documentados y flujos de acción preconfigurados, el aumento inicial puede ser sustancial. Siendo realistas, la mayoría de las empresas probablemente necesitarían contratar integradores de sistemas o consultores para implementar y optimizar completamente estos agentes.

La naturaleza basada en reglas de AgentForce también se destacó. Los usuarios deben mapear cuidadosamente qué campos se completan o pasan para que la automatización funcione con precisión, lo que lo hace más práctico que algunas plataformas impulsadas por IA. Si bien este enfoque garantiza la precisión, refuerza la dependencia de la sólida experiencia de Salesforce y la infraestructura existente.

Aunque AgentForce se limita al ecosistema de Salesforce, esto tiene ventajas y desventajas. Por un lado, es una solución empaquetada que unifica la autenticación, los permisos de usuario, las definiciones de herramientas y la lógica de orquestación dentro de una única plataforma. Por otro lado, muchos flujos de trabajo empresariales abarcan varios sistemas, y la naturaleza aislada de AgentForce limita su aplicabilidad para necesidades de automatización más amplias. Marc Benioff ha declarado que cientos de clientes ya han firmado acuerdos para utilizar AgentForce, por lo que valdrá la pena seguir su evolución.

Entonces… ¿Ya llegamos?

A partir de estos experimentos, queda claro que las soluciones actuales de agentes de IA pueden hacer un buen trabajo de razonamiento sobre tareas de varios pasos y elaborar un plan. El verdadero desafío es la ejecución en un entorno desordenado del mundo real con un conocimiento tribal sobre cómo se comportan realmente estos sistemas. Las interfaces gráficas de usuario se crearon para la interacción humana, y la lógica personalizada de cada empresa es como un pequeño agujero negro de complejidad. Incluso si se omite la interfaz gráfica de usuario para adoptar un enfoque sin interfaz gráfica de usuario o se realiza ingeniería inversa de las API de back-end, aún se enfrentan casos extremos, obstáculos de autenticación, límites de velocidad o flujos de trabajo dinámicos que echan por tierra lo mejor de los LLM.

Los desafíos pendientes son predominantemente problemas de ingeniería: construir herramientas robustas, integrarlas profundamente con los sistemas empresariales, establecer barreras de protección y crear marcos de monitoreo y orquestación confiables. Estos se pueden resolver con un esfuerzo dedicado y especialización. Los LLM actuales ya demuestran capacidades de razonamiento que van mucho más allá de las que estaban disponibles incluso hace un año, y su costo está disminuyendo rápidamente. Ahora el enfoque debe cambiar a construir la infraestructura y los procesos necesarios para implementar estas capacidades de manera efectiva.

Sin embargo, estas dificultades no deberían eclipsar el progreso constante que se está produciendo. Ya estamos viendo automatizaciones de IA especializadas y enfocadas verticalmente (por ejemplo, agentes de soporte al cliente o de SDR) que pueden ofrecer una alta precisión en un dominio controlado. A medida que cada una de estas automatizaciones de un solo uso madure, es posible que las veamos encadenadas en flujos de trabajo más amplios. Esa podría ser, en última instancia, la forma en que logremos la automatización de extremo a extremo en las grandes empresas: combinando múltiples agentes especializados en lugar de esperar que un solo agente de propósito general haga todo. Por ahora, el retorno de la inversión de crear un agente desde cero podría no ser suficiente para todas las tareas, excepto las de mayor volumen.

La especialización y el camino por delante

Una lección de estas pruebas es la importancia de la especialización. Lograr una confiabilidad casi perfecta en un solo dominio (por ejemplo, crear facturas en NetSuite) requiere un ajuste importante. Las empresas emergentes o los equipos internos que se centran en un flujo de trabajo especializado pueden ofrecer una mejor experiencia que una solución amplia y genérica. Ya estamos viendo una ola de "agentes verticales" que abordan tareas específicas en finanzas, logística, recursos humanos o cadena de suministro. Cada agente se integraría profundamente, tal vez combinando la automatización de la interfaz de usuario cuando sea necesario con llamadas directas a la API cuando sea posible, además de lógica de respaldo y barandillas específicas del dominio.

La gran pregunta sigue siendo: ¿será 2025 realmente el año en que estos agentes se generalicen o estamos ante un camino más largo? La tecnología avanza rápidamente y abunda el optimismo. Pero, así como los ingenieros de software no desaparecieron cuando la generación de código mejoró, probablemente no veremos una automatización empresarial “manos libres” para todos los procesos. En cambio, veremos mejoras iterativas en áreas especializadas, que eventualmente se unirán como un mosaico de automatizaciones parciales.

Conclusión

El concepto de agentes autónomos de IA es indudablemente atractivo, especialmente en entornos empresariales donde abundan las tareas repetitivas. Los beneficios potenciales (ahorro de tiempo, reducción de errores y posibilidad de que los empleados se concentren en tareas más creativas y estratégicas) son enormes. Sin embargo, si bien las capacidades básicas de los agentes de IA son sólidas, el camino hacia una adopción generalizada depende de la superación de los desafíos de ingeniería, además de avanzar en la investigación subyacente.

La clave está en construir la infraestructura adecuada: herramientas sólidas, integraciones confiables y soluciones específicas para cada dominio con barreras de protección y capas de orquestación bien definidas. La complejidad de los sistemas empresariales del mundo real requiere soluciones especializadas, y aquí es donde los agentes verticales pueden destacarse. Concentrarse en flujos de trabajo estrechos y bien definidos permite a los equipos refinar sus soluciones con un alto grado de precisión y confiabilidad, abordando los desafíos únicos de cada dominio. Con el tiempo, estos agentes especializados podrían interconectarse, creando una red más amplia de automatizaciones.

Es muy posible que en 2025 se produzcan avances impresionantes y un número cada vez mayor de programas piloto. En lugar de un mundo que funcione con el piloto automático, es más probable que veamos automatizaciones específicas y muy eficaces que aborden problemas específicos. El camino hacia la automatización total de las empresas será iterativo, impulsado por la especialización y la colaboración. El impulso está cobrando fuerza y la solución de estos desafíos de ingeniería allanará el camino para la próxima ola de innovación empresarial.

(Créditos de la imagen destacada a DALL-E)