Creé agentes de IA para ahorrar tiempo. Terminé trabajando para ellos.
En marketing siempre tenemos más ideas que capacidad para ejecutarlas. Cuando empecé a trabajar con agentes de IA, pensé que había encontrado una manera extraordinaria de ampliar esa capacidad sin ampliar proporcionalmente el equipo.
Iba a poder delegar tareas repetitivas, automatizar procesos, recuperar horas de trabajo y, finalmente, dedicarme a eso que siempre queda relegado porque lo urgente se come lo importante.
Funciona. Al menos al principio.
Empezás creando una automatización. Después otra. Descubrís que podés conectar herramientas, darles contexto, hacer que ejecuten tareas completas. Que ya no necesitás sentarte a escribir cada instrucción. Que podés pedirles un resultado y dejarlos trabajando.
Es genial. Hasta que un día te descubrís respondiendo mensajes de tus propios agentes, revisando sus entregables, destrabando sus procesos, resolviendo sus conflictos y preguntándote en qué momento te convertiste en la supervisora de un ejército de bots.
A medida que genero capacidad productiva, me vuelvo el cuello de botella de esa capacidad productiva.
Después lo resumí de una manera menos elegante, pero bastante más precisa:
No puedo ser bot sitter de diecisiete cosos. Me vuelven loca. 😂
Ahí empecé a entender algo que me parece fundamental para quienes estamos incorporando agentes de IA a nuestros equipos: si tenés cuellos de botella y aplicás IA sin modificar la manera en que se toman decisiones, esos cuellos de botella no necesariamente desaparecen. Se trasladan a quienes están gestionando los agentes.
Si no hacemos algo al respecto, la tecnología que supuestamente venía a liberarnos puede terminar consumiendo todavía más de nuestro tiempo.
La paradoja de crear capacidad productiva
Uno de los mayores entusiasmos que me genera la IA es la posibilidad de ampliar la capacidad de un equipo sin tener que ampliar proporcionalmente su estructura.
Pienso especialmente en marketing, donde siempre hay más ideas que manos disponibles para ejecutarlas.
Tenemos campañas que lanzar, contenidos que producir, productos que comunicar, datos que analizar, clientes que acompañar, oportunidades que investigar. Una lista interminable de cosas que sabemos que deberíamos hacer, pero que nunca llegan a convertirse en prioridad.
Entonces aparecen los agentes.
De repente, tareas que antes requerían días pueden resolverse en horas. Otras, que directamente no hacíamos por falta de recursos, empiezan a ser posibles.
Pero hay una trampa.
Si cada agente necesita que yo le explique qué hacer, le conteste preguntas, apruebe cada paso, revise lo producido y gestione la entrega, no eliminé necesariamente el trabajo: cambié su naturaleza.
Posiblemente lo fragmenté en decenas de pequeñas interrupciones.
Antes tenía una tarea grande que resolver. Ahora tengo varios agentes trabajando simultáneamente y todos necesitan algo de mí.
Cada uno, individualmente, parece estar ahorrándome tiempo. Pero juntos pueden convertirse en una nueva fuente de sobrecarga.
Es una situación bastante absurda: creé capacidad para tener más libertad y terminé trabajando para sostener la capacidad que creé.
Creo que acá aparece la primera pregunta que deberíamos hacernos antes de construir otro agente: ¿estoy automatizando un proceso o estoy creando una nueva responsabilidad de gestión?
Porque si es lo segundo, necesito empezar a pensar de otra manera.
De Executor a Delegate: cuando la IA deja de esperar instrucciones
Durante mucho tiempo usamos la IA como una especie de ejecutora de tareas.
Le pedíamos que redactara un texto, analizara una planilla, resumiera un documento o generara algunas ideas.
Nosotros seguíamos dirigiendo el proceso. La IA ejecutaba una parte.
A esta primera etapa me gusta llamarla Executor.
El modelo responde a una instrucción y entrega un resultado. Puede hacerlo extraordinariamente bien, pero el trabajo de organizar, decidir y conectar todas las partes sigue estando en nuestras manos.
Con los agentes aparece otra posibilidad: Delegate.
Ya no necesito indicarle cada acción. Puedo darle un objetivo, contexto, fuentes de información, criterios de calidad y cierto margen de autonomía para decidir cómo alcanzar el resultado.
Mi fantasía de delegación es bastante sencilla:
El objetivo es este, tenés este contexto, el producto es este, estas son las fuentes autorizadas, esta marca. Entregame todo hecho. Y me voy a hacer el mate y cuando vuelvo tengo el PDF. 🧉
Eso es lo que quiero.
No quiero supervisar cómo arma cada página. Quiero recibir un trabajo terminado, revisar que cumpla con lo que necesito y continuar con mi día.
Porque ya quiero que haga algo solo. Si no, me está sumando trabajo, no me está restando.
Ahora bien, lograr esa autonomía requiere algo que curiosamente ya conocemos quienes trabajamos liderando equipos: aprender a delegar.
Una de las cosas que más me sorprendió trabajando con agentes es cuánto se parece el desafío de darles autonomía al de acompañar a una persona que recién se incorpora a un equipo.
Si le das a un compañero una tarea sin explicarle el contexto, sin definir qué esperás y sin darle acceso a la información necesaria, probablemente te haga veinte preguntas.
Con la IA pasa algo parecido.
La autonomía depende en gran medida de la calidad del contexto, de las instrucciones y de los límites que establecemos.
Pero hay una diferencia importante: las personas aportan experiencia, criterio social y comprensión de consecuencias que un agente puede no tener. Un agente, además, puede ejecutar acciones a una velocidad que nos deja muy poco margen para intervenir.
Ahí aparece otro problema.
El junior más junior del mundo. Y encima, lanzado.
Una de mis comparaciones favoritas es que trabajar con ciertos agentes se parece a tener al junior más junior del mundo.
Pero no cualquier junior.
Uno particularmente lanzado.
El junior no te publica el artículo, te llama a vos para que lo revises. Este se manda, lo publica.
En mis primeras experiencias con agentes descubrí que no alcanza con esperar que pidan autorización: hay que diseñar explícitamente los límites de ejecución y los puntos de aprobación humana.
Porque hay algo que los agentes hacen particularmente bien: ejecutar.
Cuando están suficientemente conectados con herramientas y procesos, esa capacidad puede traducirse en acciones concretas que van mucho más allá de generar un texto.
Pueden modificar archivos, enviar comunicaciones, actualizar información o publicar contenidos.
Vos les das la mano y te toman el codo. 😅
Autonomía no significa permiso para cualquier cosa
Pero acá quiero hacer una distinción.
No es lo mismo darle autonomía a un agente que darle permiso para hacer cualquier cosa.
En febrero de 2026, Anthropic publicó una investigación sobre cómo las personas utilizan agentes autónomos en la práctica. Me resultó interesante porque observa que, a medida que los usuarios ganan experiencia, tienden a permitir períodos más largos de ejecución independiente, pero también desarrollan otras formas de supervisar e intervenir.
Es decir, la supervisión no necesariamente desaparece. Cambia de forma.
Creo que ese es exactamente el desafío.
Un agente puede tener autonomía para investigar, recopilar información, preparar materiales y proponer decisiones, pero eso no significa que deba tener autorización para publicar cualquier cosa o modificar información sensible.
Hay decisiones que pueden delegarse. Hay otras que necesitan controles. Algunas acciones, por su riesgo, exigen aprobación humana explícita.
El objetivo no debería ser revisar absolutamente cada movimiento, sino definir qué puede decidir el agente por su cuenta, qué necesita validar y qué directamente no está autorizado a hacer.
Yo misma sigo siendo bastante exigente con esto.
No entrego nada si no lo leí.
Aunque hoy tengo agentes capaces de producir trabajos sorprendentemente buenos, sigo creyendo que el criterio humano es indispensable.
De hecho, también aprendí a reconocer la otra cara de la moneda.
Cuando un agente está bien configurado, tiene información suficiente y comprende lo que se espera de él, puede trabajar con una consistencia y concentración extraordinarias.
Cuando ya funciona bien no labura como un junior. Labura como una persona inteligente e hiperconcentrada.
La comparación es imperfecta, claro. La IA no es una persona ni reemplaza las responsabilidades humanas. Pero sirve para ilustrar ese cambio tan grande entre pedirle una tarea aislada y confiarle un proceso completo.
Ahí es cuando empezamos a entrar en la tercera etapa.
De Delegate a Product: el agente dejó de ser una automatización
Supongamos que conseguimos construir un agente que funciona.
Tiene instrucciones claras. Conoce su objetivo. Puede acceder a las fuentes correctas. Ejecuta con autonomía razonable y entrega resultados que cumplen nuestros criterios de calidad.
Fantástico.
¿Terminamos?
En realidad, recién empieza otra parte del trabajo.
Porque cuando ese agente empieza a funcionar de manera recurrente, cuando otras personas dependen de lo que produce o cuando se convierte en parte de un proceso habitual, deja de alcanzar con preguntarnos si funciona. Tenemos que preguntarnos para quién funciona, qué valor genera, quién responde por él y cómo vamos a mejorarlo. Ahí empezamos a gestionarlo como un producto.
No me refiero necesariamente a un producto comercial, sino a un producto interno: una capacidad que tiene usuarios, un propósito, un responsable, costos, reglas de funcionamiento y un ciclo de vida.
Hace poco encontré una guía de Microsoft sobre gestión del ciclo de vida de agentes que lo dice de una manera que me encantó:
«Agents are products, not projects».
Los agentes son productos, no proyectos.
Me gusta porque resume algo que fui descubriendo a fuerza de implementar, equivocarme y volver a intentar.
Un proyecto tiene un comienzo y un final. Lo construís, lo entregás y, en principio, está terminado.
Un producto sigue vivo después de su lanzamiento.
Necesita que alguien lo cuide, que se revise su rendimiento, que se escuche a sus usuarios, que evolucione cuando cambian las necesidades y, eventualmente, que se retire cuando deja de aportar valor.
Esto, para quienes venimos del mundo del Product Management y las metodologías ágiles, debería resultarnos muy familiar.
Sin embargo, no siempre aplicamos esos mismos principios a nuestras propias soluciones de IA.
Nos entusiasmamos creando agentes, pero no necesariamente construimos las condiciones para que funcionen y generen valor en el tiempo.
Ahí aparece otro cuello de botella.
El agente que nadie usa también es un problema
Hace un tiempo desarrollé un agente redactor que, técnicamente, prometía bastante.
Tenía un propósito claro y podía ayudarnos a crear contenidos.
Pero nunca terminó de prosperar.
¿Por qué?
Porque nadie se puso realmente a usarlo.
Eso me dejó pensando.
Podés construir un agente extraordinario, pero si las personas que deberían aprovecharlo no lo conocen, no entienden cómo usarlo o no incorporan su resultado al trabajo cotidiano, su capacidad es prácticamente irrelevante.
Es exactamente lo mismo que sucede con tantos productos digitales que se desarrollan con entusiasmo y después quedan abandonados.
El problema no siempre está en la tecnología.
A veces está en la adopción.
Yo genero bots, pero si no logro que el equipo y que toda la empresa los conozca y los adopten, y los bots no tienen un onboarding, dependen todos de mí, y todos pasan por mí.
Ahí entendí que necesitaba pensar en los agentes como algo que debía transferirse, explicarse y sostenerse más allá de su creadora.
Porque un agente que solo funciona mientras yo estoy disponible para operarlo no es realmente autónomo.
Esto no se resuelve únicamente mejorando sus instrucciones.
Necesita onboarding. Necesita que las personas sepan qué hace, qué pueden esperar de él, cuándo usarlo, cuándo no y cómo informar un problema.
Necesita un responsable, pero también mecanismos para aprender de sus errores. Si cada corrección depende de que yo detecte el problema, explique qué pasó y vuelva a enseñarle lo mismo, sigo siendo parte indispensable del proceso.
También necesita integrarse en un flujo de trabajo que tenga sentido.
Cuando el cuello de botella se traslada a la distribución
También me pasó algo bastante revelador cuando empezamos a producir contenidos con agentes.
Conseguimos acelerar muchísimo la creación de materiales. Podíamos desarrollar calendarios editoriales, generar borradores, adaptar textos a la voz de una marca y preparar distintas piezas de comunicación.
La capacidad de producción creció.
Pero la capacidad de publicación y distribución no había escalado al mismo ritmo. Habíamos acelerado la producción sin rediseñar el proceso completo.
Antes, el cuello de botella estaba en la producción. Ahora estaba en la distribución.
¿De qué sirve tener un ejército de agentes creando contenidos si nadie tiene capacidad de publicarlos, distribuirlos o convertirlos en algo que llegue a las personas?
Más todavía, ¿de qué sirve producir materiales que nadie necesita o que nadie termina utilizando?
Acá hay otro tema enorme: la facilidad de producir cosas con IA puede llevarnos a crear cosas que nunca hubiéramos necesitado. Nos enamoramos de la posibilidad de hacerlas y dejamos de preguntarnos para qué.
Pero eso merece otro artículo.
Por ahora, me interesa quedarme con una idea: crear capacidad no es lo mismo que generar valor.
Si los agentes trabajan, también tienen que rendir cuentas
En algún momento empecé a preguntarme cómo podía medir realmente el retorno de mis agentes.
Hasta entonces, una parte importante de la conversación giraba alrededor del costo de ejecución: cuántos tokens consumían, cuánto costaba cada modelo, qué infraestructura necesitaban.
Son preguntas válidas.
Pero insuficientes.
Porque un agente barato que produce trabajo innecesario puede salirnos carísimo, especialmente cuando consideramos el tiempo humano que consume.
Un agente relativamente costoso que resuelve de manera confiable un proceso importante puede ser una inversión extraordinaria.
Entonces cambié mi forma de pensar el ROI.
Empecé a hacer que los agentes registraran su propio trabajo.
Pero que un agente reporte diez tareas completadas no significa que haya generado diez tareas de valor. Necesito contrastar ese registro con los entregables reales, su utilización y sus resultados.
Si completan una tarea, quiero que quede registrada. Si producen un entregable, quiero poder identificarlo. Si encuentran un bloqueo, necesito saber dónde se detuvieron.
Sobre todo, quiero tener información para responder algunas preguntas bastante simples:
- Capacidad: ¿qué trabajo está resolviendo el agente que antes requería intervención humana?
- Calidad: ¿cuánto de lo producido realmente sirve y cuánto necesita revisión o retrabajo?
- Adopción: ¿alguien utiliza sus resultados o los materiales quedan acumulados?
- Autonomía: ¿cuántas veces necesita intervención humana para completar una tarea?
- Costo: ¿cuánto cuesta operarlo, incluyendo supervisión, mantenimiento y correcciones?
- Valor: ¿qué resultado concreto habilita para las personas, el equipo o el negocio?
Esto no significa que haya que convertir cada pequeño agente en un proyecto burocrático de medición.
Significa que necesitamos poder distinguir entre estar ocupados y ser productivos.
También entre producir mucho y producir algo que importa.
La capacidad neta importa más que la cantidad
Me interesa especialmente la capacidad neta: no solamente cuánto trabajo ejecuta un agente, sino cuánto trabajo útil entrega después de considerar los recursos que consume.
Si un agente me ahorra una hora de producción, pero necesito dos horas para corregir lo que hizo, no me está liberando capacidad.
Si produce diez materiales y ninguno se utiliza, no puedo considerar que esos diez entregables representan automáticamente un beneficio.
Si genera contenidos que necesitan una etapa posterior que no tiene recursos disponibles, lo que conseguí fue acumular trabajo en otra parte del proceso.
Microsoft también aborda esta distinción en su guía sobre cómo medir el valor de los agentes. Plantea que la cantidad de agentes implementados no dice demasiado sobre los resultados obtenidos y propone observar adopción, valor, gobernanza y calidad.
Coincido.
No quiero saber solamente cuántos agentes tengo funcionando. Quiero saber qué capacidad útil están sosteniendo.
Hay una variable que me parece especialmente interesante: la cantidad de trabajo que queda frenado esperando respuestas humanas.
Porque muchas veces el agente está preparado para avanzar, pero no puede hacerlo.
Necesita una decisión, un dato, una autorización o una revisión.
En esos casos, el problema ya no es su capacidad técnica. Es cómo está organizado el trabajo alrededor de él.
Eso también tenemos que aprender a medirlo.
La autonomía también necesita infraestructura
Hay un ejemplo de mi propia experiencia que me ayuda a entender por qué un agente debería gestionarse como producto.
Tengo un agente dedicado a clasificar y priorizar correos electrónicos que funciona solo desde marzo.
Hoy es uno de esos procesos que considero bastante maduros porque ya no necesitan mi intervención constante para ejecutar su tarea.
Pero no nació así.
Empezó como una serie de automatizaciones en ChatGPT.
Después lo llevé a Codex de ChatGPT, donde funcionaba desde mi computadora.
El problema era bastante evidente: si mi computadora estaba apagada, el proceso dejaba de funcionar.
Yo no quería tener que preocuparme por eso cada vez que me iba de vacaciones.
Entonces lo migré a Hermes Agent, ejecutándose en un VPS, para que pudiera seguir trabajando independientemente de mi computadora.
Más adelante, volví a cambiarlo de plataforma. Ahora está en Grok Bot, principalmente por comodidad de administración.
Fijate que, en todo ese recorrido, la necesidad que resolvía el agente seguía siendo esencialmente la misma.
Lo que cambiaba era su implementación.
Esos cambios no fueron necesariamente consecuencia de un error. Fueron decisiones de evolución del producto.
Primero necesitaba comprobar que funcionaba. Después, que pudiera ejecutarse sin depender de mi computadora. Más adelante, que fuera más sencillo de administrar.
También aprendí que tener un agente funcionando no equivale a tener un sistema sostenible.
Importan la continuidad operativa, la facilidad de mantenimiento, la posibilidad de revisar errores, la seguridad de los accesos y qué sucede cuando una herramienta deja de funcionar como esperábamos.
Un producto no debería depender indefinidamente del entorno particular en el que su creador consiguió ponerlo en marcha.
Si la solución deja de funcionar porque me fui de vacaciones, cambié de computadora o no estoy disponible para responder una pregunta, todavía tiene un problema importante de madurez.
No significa que todos los agentes necesiten arquitecturas complejas o infraestructura dedicada.
Significa que la infraestructura también debería evolucionar según el valor, el uso y las necesidades reales del producto.
Agile Marketing: iterar agentes, no acumular automatizaciones
Creo que quienes trabajamos con Agile Marketing tenemos una ventaja interesante para abordar este desafío.
Estamos acostumbrados a pensar en términos de entregas incrementales, feedback, retrospectivas, priorización y mejora continua.
En lugar de preguntarnos únicamente qué nuevo agente podemos crear, podemos empezar a gestionar los que ya tenemos como un portafolio de productos en evolución.
Para mí, esto implica incorporar su mejora al trabajo de cada sprint.
No hace falta rediseñarlos todos permanentemente. Pero sí revisar qué necesitan.
- Quizás un agente tiene un problema de calidad y necesita mejores evaluaciones.
- Otro produce buenos resultados, pero nadie lo utiliza porque nunca tuvo un onboarding adecuado.
- Otro funciona perfectamente, pero consume demasiadas horas de revisión humana.
- Otro está entregando materiales más rápido de lo que el proceso siguiente puede absorberlos.
- Otro, sencillamente, dejó de tener sentido.
No todos necesitan más autonomía. Algunos necesitan mejores límites. Otros necesitan usuarios. Y algunos necesitan dejar de existir.
Esto último también me parece importante.
Crear un agente no debería convertirse en un compromiso eterno de mantenerlo.
Si ya no resuelve un problema relevante, si cuesta más de lo que aporta o si existe una alternativa mejor, retirarlo puede ser una decisión perfectamente saludable.
En gestión de productos estamos bastante acostumbrados a discutir funcionalidades, prioridades y roadmap.
Con los agentes deberíamos hacer lo mismo.
Tener un backlog de mejoras, identificar problemas, incorporar feedback de quienes los utilizan y decidir qué vale la pena evolucionar.
Incluso podríamos pensar en un product owner para cada agente relevante, aunque ese rol no necesariamente tenga que convertirse en un puesto exclusivo.
Alguien tiene que hacerse responsable de que funcione, de que se utilice y de que siga aportando valor.
Principalmente, de que no dependa eternamente de quien lo construyó.
Eso sí: tampoco quiero que esto se convierta en otra capa innecesaria de gestión.
La idea no es crear burocracia alrededor de la IA.
La idea es exactamente la contraria: establecer las condiciones mínimas para que los agentes puedan sostener su trabajo sin requerir nuestra atención permanente.
La agilidad también consiste en saber qué no hacer. Si un agente no destraba un proceso, mejora un resultado o resuelve una necesidad real, no merece prioridad en el backlog solo porque ahora podamos construirlo.
Con IA, ese principio sigue siendo igual de válido.
La madurez no está en cuántos agentes tenés
Hay algo que cambió bastante en mi forma de pensar la IA.
Al principio, me entusiasmaba la cantidad de cosas que podía automatizar.
Después, la complejidad de los procesos que podía delegar.
Hoy me interesa mucho más saber cuánta capacidad útil puedo sostener con autonomía y sin que todo dependa de mí.
Esa es, para mí, una medida mucho más interesante de madurez.
Podés tener un montón de agentes ejecutando tareas, pero si todos necesitan preguntarte qué hacer, todavía estás administrando un sistema altamente dependiente de vos.
Podés tener agentes técnicamente brillantes, pero si nadie los conoce ni utiliza, su capacidad no está generando valor.
Podés tener agentes funcionando de manera completamente autónoma, pero si no conocés sus costos, sus errores o las decisiones que toman, probablemente tengas un problema de gobernanza.
La autonomía, entonces, no debería confundirse con desentendernos de ellos.
Un agente maduro no es el que hace cualquier cosa sin preguntarte. Es el que puede sostener una capacidad útil dentro de límites claros, con controles proporcionales a sus riesgos y sin depender de su creador para cada paso.
Creo que eso también modifica nuestra manera de liderar.
Porque aparece una tentación bastante humana: centralizar las decisiones para asegurarnos de que todo salga bien.
Yo misma la tengo.
Me gusta revisar, corregir y saber qué está pasando.
Pero si quiero que los agentes me devuelvan tiempo, necesito empezar a distinguir entre las decisiones que realmente requieren mi criterio y aquellas que puedo delegar con seguridad.
Exactamente como sucede cuando lideramos personas.
No se trata de abandonar la responsabilidad. Se trata de diseñar un sistema donde la responsabilidad no implique estar presente en cada movimiento.
Hay algo que no quiero perder de vista en medio de todo este entusiasmo tecnológico.
Si hay IA y no hay creatividad, no sirve. Ahora, si tenés IA más creatividad y criterio, vamos bien.
Porque la IA puede ampliar muchísimo nuestra capacidad de ejecución.
Pero no decide por nosotros qué merece la pena construir, qué problema es verdaderamente importante ni qué tipo de relación queremos tener con las personas que reciben nuestro trabajo.
Eso sigue siendo parte de nuestra responsabilidad.
¿Para qué queríamos liberarnos de trabajo?
Me parece interesante volver al principio.
Empezamos incorporando IA porque queríamos recuperar tiempo.
Tiempo para pensar, crear, aprender, conversar con nuestros equipos, entender mejor a nuestros clientes y trabajar en problemas que realmente importan.
Pero si terminamos supervisando permanentemente agentes que producen cosas que nadie usa, probablemente nos hayamos alejado bastante de esa intención original.
Por eso hoy, antes de entusiasmarme con otro agente, intento hacerme una pregunta distinta.
No solamente: «¿Podemos automatizar esto?».
Sino: «¿Vale la pena crear y sostener esta capacidad?».
Porque cada agente nuevo también incorpora decisiones, costos, riesgos y necesidades de mantenimiento.
El verdadero objetivo nunca fue tener más bots.
Era poder hacer mejor nuestro trabajo.
Al final, creo que lo más interesante no es cuánto trabajo podemos poner en manos de la IA, sino qué hacemos nosotros con la capacidad que conseguimos liberar.
Si la IA me devuelve tiempo para pensar, crear y decidir mejor, funcionó. Si tengo que pasarme el día cuidando diecisiete cosos, evidentemente todavía nos queda bastante por resolver.