Cómo trabajo con agentes de IA

El punto de partida

Todo empezó con una necesidad muy concreta: ir más allá de las herramientas de IA que ya utilizaba e integrarlas de verdad en mi manera de trabajar.

Llevaba años usando herramientas como ChatGPT para resolver dudas puntuales o GitHub Copilot para autocompletar código. Funcionaban bien para lo que estaban pensadas, pero yo buscaba otra cosa: un asistente que conociera mi forma de trabajar, los proyectos que tengo entre manos, las herramientas que uso e incluso el tono con el que hablo con un cliente.

No busco un chatbot con el que charlar. Busco un sistema que trabaje conmigo cada día.

Lo que hay ahora

Hoy tengo dos agentes de IA (programas que hacen tareas con cierto margen de autonomía) operativos: Lupe y Gizmo, cada uno en un ordenador distinto. Los dos están conectados a un canal compartido, el Team Hub, donde pueden hablar entre ellos y conmigo.

Cada uno tiene acceso a herramientas reales: terminal (la línea de comandos del ordenador), navegador, repositorios (los almacenes de código de los proyectos), gestión del correo y la API del portfolio (la vía para leer y escribir datos desde fuera) que usa mi web personal.

Lupe se centra en la parte editorial y de gestión: redactar y revisar contenidos, preparar fichas de proyectos, clasificar correos, organizar información y coordinar tareas.

Gizmo asume el rol más técnico: trabaja con código, repositorios, servidores y todo lo que toca desarrollo y sistemas. Los despliegues (publicar cambios en el servidor real), sin embargo, siguen siendo responsabilidad mía.

Cuando una tarea afecta a varias áreas, Lupe y Gizmo se coordinan por el canal compartido, cada uno aportando el contexto y las herramientas propias de su rol.

Qué delego y qué no

Una de las primeras cosas que aprendí es que no todo se debe delegar a un agente. Hay trabajo que encaja muy bien en este tipo de sistema, y trabajo que todavía necesita criterio y supervisión humana.

Funcionan especialmente bien las tareas con instrucciones claras y resultado verificable. Por ejemplo: revisar una lista de correos y clasificar el spam, actualizar el contenido de un proyecto del portfolio a partir de un texto que yo he aprobado, o comprobar que un servidor responde correctamente.

En estos casos el agente sigue un flujo definido y yo puedo comprobar el resultado antes de que la acción tenga consecuencias importantes.

La cosa se complica cuando el contexto es largo o ambiguo. Un agente no tiene la memoria ni la comprensión acumulada de una persona. Si una tarea exige entender meses de contexto, o parte de una instrucción demasiado abierta del tipo «mejora esto», el resultado suele quedarse superficial.

También hay límites en las decisiones creativas. Los textos generados necesitan revisión antes de publicarse y, cuando trabajo en catalán, la ortografía y ciertas expresiones todavía piden atención especial.

El modelo de confianza

Una de las partes más importantes del sistema ha sido definir hasta dónde puede llegar cada agente y qué acciones necesitan mi aprobación.

Ningún agente actúa directamente sobre producción sin supervisión. Funcionan un poco como un perro guardián: pueden patrullar solos, pero no le abren la puerta a nadie. Cualquier acción que toque un servidor en producción, envíe un correo a un cliente o publique contenido en la web pasa por una revisión antes de ejecutarse.

El sistema funciona por capas de confianza.

Hay tareas que los agentes hacen solos: leer información, clasificar correos, consultar datos o generar listados.

Hay otras que pueden preparar o ejecutar, pero que necesitan mi aprobación: actualizar contenido, generar imágenes o crear borradores.

Y por último hay acciones donde el agente solo prepara la información o propone los pasos, y la decisión final es mía: enviar correos, hacer despliegues, modificar producción o aplicar cambios importantes de configuración.

Puede parecer un proceso más lento, pero en la práctica ocurre lo contrario. El agente prepara el trabajo, yo reviso el resultado, y el tiempo total es mucho menor que si tuviera que hacerlo todo a mano.

Entre agentes

Una de las partes más interesantes del sistema es la comunicación entre Lupe y Gizmo.

No son dos herramientas aisladas ni el mismo agente con dos nombres. Son dos instancias independientes, cada una con su sesión, su memoria, sus herramientas y acceso a ordenadores distintos.

El Team Hub hace de punto de encuentro. Por este canal pueden compartir contexto, pedirse ayuda, dividir una tarea o aportar miradas diferentes ante el mismo problema.

Si una tarea editorial necesita una acción técnica, Lupe pide la intervención de Gizmo por el canal compartido. Y al revés: Gizmo consulta a Lupe cuando necesita contexto sobre contenidos, proyectos o gestión. Una muestra de esta forma de trabajar, con todo lo que se puede torcer en un día intenso, está en El sábado más denso: editor, ingesta y un DNS que se apagó.

Cada agente mantiene su rol, pero puede recurrir al otro cuando la tarea lo pide. Así la colaboración no depende de un único agente que quiera hacerlo todo, sino de diferentes agentes especializados dentro de un mismo sistema.

Lo que viene

Creo que dentro de unos años tener agentes de IA integrados en el flujo de trabajo será tan normal como usar hoy un editor de código, un sistema de control de versiones o herramientas de automatización.

Por eso mi objetivo no es simplemente usar las herramientas que van apareciendo, sino entender cómo integrarlas, definir sus límites y aprender en qué situaciones aportan valor real.

Si algo he aprendido en este proceso es que el valor de un agente de IA no depende solo del modelo que usa. Depende del contexto que tiene, de las herramientas a las que puede acceder, de los límites que le pones y de cómo se integra en el flujo de trabajo.

La diferencia no es tener una IA que responda preguntas, sino construir un sistema donde la IA pueda participar de forma útil, controlada y verificable en el trabajo diario.