Lo difícil no era crear el agente, sino definir el trabajo

Empecé construyendo un agente de IA dedicado para preparar un menú semanal y terminé resolviendo esa necesidad con una tarea programada en otra plataforma. Entre ambas soluciones hubo trabajo de infraestructura, búsquedas, documentos y ajustes. Pero lo que más cambió fue mi manera de explicar qué tenía que hacer el sistema para que yo pudiera considerar terminado el encargo.

La petición inicial parecía bastante concreta: planificar comidas y cenas para dos personas, localizar recetas, preparar la lista de la compra y entregar un documento práctico. Había que respetar algunas condiciones: comidas laborables aptas para táper, cenas sencillas, tiempos razonables y cierta variedad sin perder de vista el precio y la comodidad.

Con esa descripción pensé que tenía el problema suficientemente definido. Al desarrollar la solución descubrí cuántas decisiones seguían escondidas dentro de «preparar un menú».

Un agente parecía una forma razonable de empezar

La tarea combinaba cosas que no encajaban fácilmente en una secuencia cerrada. Había que interpretar preferencias, buscar información en páginas distintas, descartar opciones y generar un documento. Si una receta no servía, hacía falta encontrar otra. Si una fuente no respondía, convenía poder cambiar de camino.

Preparé un agente con su propio entorno, herramientas y automatizaciones. Esa estructura me permitía explorar el recorrido completo: desde la petición hasta el entregable, pasando por las búsquedas y las comprobaciones. Quería que pudiera resolver los pasos intermedios sin que yo tuviera que dirigir cada consulta.

Al principio presté bastante atención a las capacidades del agente y a cómo organizar su entorno. Era trabajo necesario para aquella aproximación, pero disponer de herramientas no resolvía las decisiones sobre el contenido. El sistema podía buscar recetas; yo todavía tenía que precisar qué significaba aceptar una de ellas.

Las recetas hicieron visibles los requisitos que faltaban

La primera diferencia importante apareció entre encontrar una receta y comprobarla. Un resultado del buscador ofrecía un título, un resumen y una dirección. Eso ayudaba a localizar candidatos, pero no bastaba para utilizarlos como base del menú y de la compra.

Empecé a exigir que se abriera la página y se revisaran los ingredientes, la preparación y las raciones. El enlace tenía que respaldar el plato que aparecía en el documento. También necesitaba que las cantidades fueran coherentes con la planificación para dos personas y que las restricciones no se perdieran al elegir una alternativa.

La lista de la compra volvía especialmente importante esa relación. Si el menú, las recetas y las cantidades no encajaban, podía recibir un documento aparentemente completo que me obligara a rehacer parte del trabajo antes de comprar. «Hay una receta enlazada» era una condición demasiado débil para aceptar el resultado.

Con las fuentes externas aparecieron también esperas, consultas que había que reformular y páginas que convenía sustituir. Fui dando margen al flujo para recuperarse: reintentar de forma razonable, buscar otra fuente o descartar una opción. Pero necesitaba un límite. Si no conseguía comprobar una receta, no quería que completara el hueco con información supuesta.

Así fue cambiando el encargo. Ya no consistía solo en proponer platos. Incluía decidir qué información permitía incorporarlos y qué debía quedar pendiente cuando esa información no estuviera disponible.

El documento me enseñó dónde terminaba el trabajo

Cuando pude revisar el menú y la lista resultantes, encontré otro desajuste. La respuesta contaba búsquedas, reintentos, páginas descartadas y decisiones intermedias con demasiado detalle. Para entender lo que había obtenido tenía que recorrer buena parte de lo que el agente había hecho.

Esa visibilidad me servía durante el desarrollo. Me permitía observar el comportamiento y ajustar el encargo. Sin embargo, la entrega que quería recibir cada semana tenía otro propósito: ayudarme a organizar las comidas y la compra sin reconstruir la conversación.

Fui concentrando el resultado en el documento. El PDF debía reunir el menú, los enlaces consultables, la lista de la compra y la preparación anticipada que tuviera sentido. La conversación podía acompañarlo con una confirmación breve, siempre que no hubiera nada relevante pendiente.

Eso me obligó a distinguir mejor las excepciones. Un reintento resuelto no tenía por qué convertirse en una interrupción. En cambio, si no se encontraba una fuente adecuada, faltaban cantidades o no podía generarse el documento, necesitaba saberlo claramente. Una sustitución también podía requerir explicación si alteraba de forma relevante lo que había pedido.

El exceso de información acabó señalando un problema más profundo: todavía estaba afinando qué debía entregarse y en qué condiciones. Acortar la respuesta no bastaba. Antes tenía que quedar claro qué significaba terminar y qué impedía dar el trabajo por terminado.

Cuando pude acotar el encargo, cambió la arquitectura

Mientras concretaba esos requisitos, también tuve que valorar el coste de repetir el proceso. El primer enfoque suponía mantener un agente de IA en infraestructura propia, con su entorno de ejecución, herramientas, automatizaciones y conexión a un modelo de lenguaje. Proyectos como OpenClaw, CrewAI o LangGraph ofrecen distintas formas de construir o ejecutar sistemas con agentes. En mi caso, operar el entorno y mantenerlo disponible formaba parte del trabajo, además del consumo de las ejecuciones.

Cada vez podía describir mejor la necesidad: una ejecución semanal, unas restricciones conocidas, fuentes comprobadas, un documento utilizable y una comunicación clara de lo que quedara pendiente. Mantener un agente dedicado había dejado de ser una condición del encargo.

La solución terminó evolucionando hacia una tarea programada en una plataforma de IA gestionada. Las funciones de programación de plataformas como ChatGPT, Gemini o Microsoft 365 Copilot permiten ese otro enfoque. Podía delegar la programación y la ejecución recurrente sin sostener un entorno de agente propio para aquel caso de uso.

En ambas soluciones seguía utilizando IA y necesitaba satisfacer los mismos requisitos de calidad: comprobar las fuentes, validar el documento y gestionar las incidencias. Había reducido la infraestructura a mi cargo, pero esos criterios seguían siendo necesarios para aceptar el resultado.

El cambio de arquitectura llegó cuando pude separar mejor el trabajo que necesitaba de la forma en que había empezado a resolverlo. Lo que dio continuidad al proyecto fueron los criterios que había aprendido a expresar. Con ellos, una tarea programada resultaba suficiente para atender aquella necesidad.

La primera solución también produjo conocimiento

Al empezar, podía describir el resultado que deseaba, pero no todas las condiciones que lo hacían útil. Trabajar con el agente me permitió descubrirlas en las búsquedas, en las cantidades, en el documento y en las respuestas que tenía que leer.

No creo que todo ese conocimiento pudiera haberse obtenido simplemente redactando una petición más larga antes de comenzar. Parte apareció al utilizar la primera solución y observar la distancia entre lo que hacía y lo que yo necesitaba. Sí me sirve para afrontar el siguiente proyecto con más atención a esa distancia y menos apego a la forma inicial de resolverlo.

El agente dedicado no fue la solución definitiva, pero su desarrollo tuvo valor. Los requisitos y los criterios de aceptación sobrevivieron al cambio de arquitectura. Con ellos pude elegir una solución más sencilla sin empezar de cero en lo importante: entender el trabajo que quería delegar.