«Si no puedes explicarlo de forma sencilla, es que no lo entiendes suficientemente bien.»

Albert Einstein

Llevaba meses leyendo sobre agentes de IA. Artículos, hilos de LinkedIn, demos en YouTube. Todo muy bonito, todo muy impresionante. Pero en algún momento decidí que la única manera de entenderlo de verdad era hacerlo yo misma.

Así que lo hice.

Creé mi propio agente con ChatGPT. Sin ser desarrolladora en activo, sin un equipo de ingeniería detrás, y con bastante curiosidad por delante. Y aunque el resultado me gustó, lo que más me quedó no fue el agente en sí. Fue lo que aprendí por el camino.

Esto no es un tutorial técnico. Es un relato honesto de lo que pasa cuando te metes de cabeza en algo nuevo y tienes que pensar con claridad para que funcione. Si estás considerando crear tu propio agente, o si ya lo estás intentando y algo no cuadra, quédate. Creo que esto te va a sonar.

Antes de empezar: ¿qué es exactamente un agente de IA?

Porque si no lo tenemos claro, todo lo demás se complica.

Un agente de IA no es solo un chatbot que responde preguntas. Es un sistema al que le das un objetivo y tiene cierta autonomía para decidir cómo alcanzarlo, ejecutar pasos, usar herramientas y adaptarse según lo que va encontrando.

La diferencia práctica es esta: un chatbot responde. Un agente actúa.

ChatGPT, en su versión con herramientas y configuración adecuada, puede funcionar como base para construir agentes sencillos pero útiles. No necesitas saber programar para empezar, aunque sí necesitas saber pensar con precisión. Y eso, te lo adelanto, es la parte más difícil.

Lección 1: La claridad del objetivo lo es todo

Cuando empecé, cometí el error más habitual: darle al agente un objetivo vago.

Le dije algo parecido a «ayúdame a facilitar retrospectivas». Claro, razonable, con sentido para mí. El resultado fue un agente que hacía de todo un poco, sin profundidad en nada. Respondía, sí. Pero no era útil de verdad porque yo misma no había definido bien qué quería que hiciera.

Tuve que volver al principio y hacerme tres preguntas concretas:

• ¿Qué tarea exacta quiero que resuelva este agente?
• ¿Cuál es el input que va a recibir siempre?
• ¿Cuál es el output que necesito de forma consistente?

Cuando respondí esas tres preguntas con precisión, todo cambió. El agente pasó de ser un asistente genérico a convertirse en Retro Coach: una herramienta que, a partir del contexto del equipo, sus necesidades y el momento del proyecto, te sugiere dinámicas concretas de retrospectiva y te explica por qué esa dinámica tiene sentido para esa situación específica.

La lección práctica: antes de construir nada, escribe en una sola frase lo que quieres que tu agente haga. Una frase. Si necesitas más de una, todavía no tienes claridad suficiente.

En mi caso quedó así: «Retro Coach sugiere dinámicas de retrospectiva adaptadas al contexto, las necesidades y el momento del equipo.» Una frase. Sin ambigüedad. A partir de ahí, todo lo demás encajó.

Lección 2: El prompt es el diseño. Trátatelo como tal

Mucha gente subestima el prompt. Lo ven como una instrucción rápida, algo que se escribe en dos minutos y se ajusta sobre la marcha. Yo pensaba lo mismo hasta que me pasé varias horas intentando entender por qué mi agente tomaba decisiones que no quería que tomara.

La respuesta, casi siempre, estaba en el prompt.

El prompt del sistema (el que le defines al agente al inicio, no las preguntas de cada conversación) es básicamente la constitución de tu agente. Define su personalidad, su rol, sus límites, su tono, qué puede hacer y qué no. Si ese documento tiene ambigüedades, el agente las va a interpretar a su manera. Y rara vez coincide con la tuya.

Aprendí a tratar el prompt como trataría cualquier otro documento de diseño: con iteraciones, con versiones, con criterios claros de qué quiero mejorar en cada revisión. Empecé a guardarlo en un documento aparte, a anotar qué cambié y por qué, y a probarlo con casos concretos antes de darlo por bueno.

Hay un concepto en ingeniería de prompts que se llama few-shot prompting: en lugar de solo decirle al modelo qué hacer, le das ejemplos de cómo hacerlo. La diferencia en calidad es notable. No es magia, es contexto. Los modelos de lenguaje funcionan mejor cuando tienen referencias concretas que cuando trabajan solo con descripciones abstractas.

La lección práctica: dedica tiempo real al prompt del sistema. No es el primer paso que haces rápido para llegar a la parte interesante. Es la parte interesante.

Lección 3: La memoria y el contexto no funcionan como crees

Este fue el que más me costó.

Asumí que el agente «recordaría» lo que habíamos hablado antes. Que si le daba información en una sesión, la tendría disponible en la siguiente. Que iría aprendiendo de mis preferencias con el tiempo.

Nada de eso es cierto por defecto.

Los modelos de lenguaje, incluyendo GPT-4, no tienen memoria persistente entre conversaciones a menos que tú se la des de forma explícita. Cada sesión empieza desde cero. Lo que el modelo «recuerda» dentro de una conversación es lo que está dentro de su ventana de contexto: una cantidad limitada de texto que puede procesar a la vez.

Esto tiene implicaciones prácticas enormes:

Si tu agente necesita recordar cosas entre sesiones, tienes que diseñar ese mecanismo tú. Puede ser tan sencillo como un documento de texto que le pasas al inicio de cada conversación con el «estado actual» del trabajo. O tan sofisticado como una base de datos externa conectada al sistema. La solución depende de la complejidad del caso de uso, pero la responsabilidad de diseñarla es tuya.

Además, la ventana de contexto tiene un límite. Si intentas meter demasiado en una sola conversación, el modelo empieza a «olvidar» las cosas que están al principio del hilo. He visto esto ocurrir en sesiones largas: el agente toma decisiones contradictorias con lo que había acordado veinte mensajes antes, no porque sea inconsistente por naturaleza, sino porque esa parte del hilo ya no está dentro de lo que puede procesar.

La lección práctica: diseña tu agente asumiendo que no tiene memoria. Construye ese contexto tú, de forma explícita, y pásaselo en cada sesión. Es un paso extra, pero evita sorpresas desagradables.

Lección 4: Evaluar no es opcional, es la mitad del trabajo

Crear el agente fue la parte emocionante. Evaluarlo fue la parte incómoda. Y, a posteriori, la más valiosa.

Al principio lo probaba de forma intuitiva: le hacía preguntas, revisaba si las respuestas tenían sentido, ajustaba si algo me parecía raro. El problema de ese enfoque es que solo detectas los errores obvios. Los errores sutiles, los que ocurren en casos límite, los que solo aparecen cuando el agente lleva un rato trabajando en algo complejo, esos se te escapan completamente.

Tuve que aprender a evaluar con criterios, no con intuición.

¿Qué significa eso en la práctica? Significa definir casos de prueba concretos antes de usar el agente en producción. Casos donde sepas cuál debería ser la respuesta correcta. Casos extremos. Casos ambiguos. Y revisar los resultados de forma sistemática, no solo cuando algo «parece raro».

Hay un paralelismo directo con las retrospectivas. En retrospectivas, no esperamos a que el equipo explote para hacer una revisión. La hacemos de forma regular, con estructura, para detectar patrones antes de que se conviertan en problemas. Con los agentes de IA pasa lo mismo. Si esperas a que falle de forma obvia, ya has perdido confianza en el sistema y tiempo en arreglarlo.

También aprendí algo más sutil: los errores del agente casi siempre me decían algo sobre mis instrucciones, no sobre el modelo. Cuando el agente hacía algo que no esperaba, la primera pregunta que aprendí a hacerme fue «¿qué parte de mi prompt lo llevó aquí?» casi siempre había una respuesta. El modelo no es arbitrario. Sigue instrucciones con más literalidad de lo que esperamos.

La lección práctica: define al menos diez casos de prueba antes de usar tu agente en algo real. Incluye casos fáciles, casos difíciles y al menos dos casos donde la respuesta «correcta» no sea obvia. Repasa los resultados con criterios claros.

Lo que me llevo después de todo esto

Crear Retro Coach me enseñó cosas que no habría aprendido leyendo sobre ello.

Me enseñó que la IA no compensa la falta de claridad humana. Si tú no tienes claro qué quieres, el agente va a inventarse algo, y probablemente no será lo que necesitas. Me enseñó que diseñar bien un sistema de IA no es tan diferente de diseñar bien cualquier otro sistema: requiere iteración, criterios, pruebas y humildad para revisar lo que no funciona.

Pero sobre todo me enseñó algo que no esperaba: que esto era solo el primer paso.

Porque una vez que entiendes cómo funciona un agente, cómo se diseña su objetivo, cómo se construye su contexto, cómo se evalúa de verdad, algo cambia en tu cabeza. Empiezas a ver tus procesos cotidianos de otra manera. Empiezas a preguntarte qué más podrías delegar, qué más podrías automatizar, qué tareas que hoy haces manualmente podrían tener un sistema detrás que las resuelva mejor y más rápido que tú.

Yo llegué ahí. Y lo que encontré fue un nivel completamente distinto de trabajo con IA.

Pasé de usar ChatGPT como asistente de conversación a construir flujos reales con Claude, sus skills y sus conectores. Flujos que se conectan con mis herramientas del día a día, que recuerdan mi contexto, que saben cómo trabajo y para qué trabajo. No es ciencia ficción ni requiere un equipo técnico. Requiere exactamente lo mismo que aprendí construyendo Retro Coach: claridad sobre qué quieres conseguir, un diseño pensado, iteración honesta y criterios para saber si funciona.

La diferencia entre usar IA y trabajar con IA es esa. Una es reactiva: abres la herramienta cuando la necesitas y cierras cuando terminas. La otra es proactiva: construyes sistemas que trabajan contigo, que te conocen, que te liberan tiempo y energía para lo que realmente necesita tu cabeza.

Yo quiero lo segundo. Y Retro Coach fue el primer agente que me demostró que era posible.

Si estás pensando en crear el tuyo, empieza. No para tener algo perfecto a la primera, sino para aprender lo que solo se aprende haciéndolo. El primer agente que construyas probablemente no será el que uses dentro de seis meses. Pero el criterio que desarrollas construyéndolo, ese sí se queda. Y con ese criterio, lo que puedes llegar a hacer después no tiene mucho límite.

¿Quieres saber cómo lo hice? Déjamelo en comentarios

¡Feliz miércoles!