Empleados de IA en Python: arma un equipo nocturno que trabaje mientras duermes

Introducción

Imaginen despertar un viernes a las 8 a.m. con un borrador de newsletter listo, fact-check realizado y una nota que les pide sólo un click para publicar. No lo escribió una sola persona: fue el trabajo coordinado de tres agentes de IA. Esa es la diferencia entre un asistente y un empleado: estructura, permisos y un responsable humano para las decisiones riesgosas.

En esta guía adaptada y condensada aprenderán a construir en Python un equipo de tres agentes que trabaja en conjunto sobre un mismo motor LLM. La idea no es usar un framework complejo de entrada, sino entender y programar la lógica fundamental —unas 150 líneas de código según la referencia— para que el sistema sea auditable y modificable según sus necesidades.

Visión general del proyecto

El objetivo es un flujo de trabajo que reproduzca el ciclo editorial: investigación, redacción y edición. Cada agente tiene:

• Un rol claro (Scout, Quill, Red).
• Una lista limitada de herramientas que puede usar (por ejemplo: leer archivos, buscar URLs, escribir archivos).
• Carpetas específicas donde puede dejar su resultado.
• Prohibiciones estrictas implementadas en código: nada se publica sin aprobación humana.

Además, el proyecto incluye:

• Guardrails programáticos para evitar publicaciones no autorizadas o filtraciones.
• Un sistema de transferencia de archivos entre agentes (workflows por archivos, no por conversaciones directas).
• Un “desk” de aprobación donde un humano puede autorizar operaciones de riesgo antes de que algo salga a producción.
• Programación (cron) para que el equipo haga su turno automáticamente durante la noche.

Arquitectura del equipo y flujo de trabajo

Piensen en una pequeña empresa con tres empleados y un gerente:

• Scout: se encarga de la investigación y deja links y hallazgos en una carpeta compartida.
• Quill: toma la investigación y produce un borrador.
• Red: revisa el borrador, corrige invenciones o errores y, si todo está bien, crea un ticket de aprobación.

Todos los agentes usan el mismo motor LLM y la misma configuración. Cambiar de modelo implica cambiar el comportamiento de todo el equipo de golpe. La comunicación entre agentes no es directa; cada uno termina su turno escribiendo un archivo en una carpeta que el siguiente agente puede leer.

Clave: nadie puede publicar, enviar o borrar archivos importantes. Cuando Red considera el documento listo, en lugar de publicarlo, crea un ticket para que el gerente (ustedes) revise y apruebe.

¿Por qué no empezar con un framework?

Los frameworks son útiles una vez que ustedes saben exactamente qué necesitan. Al principio, abstraen demasiado: ¿quién controla el bucle?, ¿cómo se verifican permisos?, ¿qué ocurre si una URL falla? Programar las reglas y el flujo ustedes mismos en unas pocas docenas de líneas obliga a responder estas preguntas y a entender la superficie de fallo. Cuando cambien a un framework más adelante, podrán elegir uno que encaje realmente con su diseño.

Requisitos y puesta en marcha

Se requiere Python 3.10+ y un modelo LLM capaz de llamadas a herramientas. Pueden usar una API compatible con OpenAI o modelos locales (por ejemplo, con Ollama). En la referencia se muestra una estructura básica de proyecto (roles, memoria, inbox) y un archivo .env con la variable MODEL y la API key. Un ejemplo de configuración menciona modelos como gpt-4.1-mini o qwen2.5:7b y una variable MAX_STEPS.

La idea es seleccionar un motor al inicio y usarlo para todo el equipo. Más adelante será sencillo cambiarlo editando el .env.

Pasos esenciales (resumen ejecutivo)

1. Reglas como código: en lugar de confiar solo en prompts que piden “no publicar”, determinen en el código qué herramientas y rutas de escritura están permitidas para cada rol. El tutorial original sugiere un archivo roster.py donde cada agente tiene una lista de herramientas y rutas de escritura autorizadas.

2. Proveer herramientas: implementen funciones seguras para leer y escribir archivos, consultar URLs y cualquier otro utilitario que los agentes necesiten. No expongan herramientas sensibles a todos.

3. Menú de herramientas: cada agente recibe un “toolbelt” explícito. Por ejemplo, Scout puede leer archivos, extraer links y escribir resultados en una carpeta de handoffs; Quill puede leer esos handoffs y escribir borradores; Red puede leer borradores y escribir tickets de aprobación.

4. Contratos de trabajo: formalicen en archivos la descripción del rol, las restricciones y los formatos de salida. Estos contratos facilitan el debugging y la auditoría.

5. Bucle de agente: implementen un loop que haga funcionar al agente por pasos limitados (la referencia usa una variable MAX_STEPS). Cada agente recoge su entrada, ejecuta su tarea y salva la salida en la carpeta designada.

6. Validación de archivos: diseñen reglas que verifiquen que los artefactos cumplen requisitos antes de que el siguiente agente los procese (por ejemplo, formato mínimo, presencia de fuentes, etc.). Si falta algo, el agente falla y deja notas para revisión.

7. Escritorio de aprobación: cuando Red detecta que un documento está listo pero hay riesgos (publicación, envío a lista, acciones que impliquen privacidad), crea un ticket para un humano. Ustedes revisan y aprueban manualmente.

Operación nocturna y consideraciones prácticas

Programen el script principal con cron o tareas programadas para que el equipo haga su turno durante la noche. Mantengan logs y versiones de cada archivo para poder auditar cualquier decisión tomada por los agentes.

Algunas prácticas recomendadas:

• Mantener las reglas críticas fuera de prompts y dentro del código.
• Limitar las herramientas disponibles por rol.
• Hacer que el flujo transite por archivos para tener rastro y permitir reintentos.
• Mantener una única configuración de modelo central (archivo .env) para controlar el comportamiento del equipo de forma coherente.

Mejoras posibles (ideas para iterar)

La referencia propone upgrades que pueden explorarse una vez el sistema base funcione: añadir métricas de calidad, un agente de fact-check más autónomo, o integración con sistemas de publicación con stages que requieran varias aprobaciones.

Conclusión

Construir “empleados” de IA en Python es menos sobre inteligencia de modelos y más sobre diseño organizacional: definir roles, permisos y un responsable humano que supervise las decisiones críticas. Programen las reglas en código, restrinjan herramientas y hagan que el flujo pase por archivos y aprobaciones. Con esto podrán tener un equipo nocturno que realmente entregue trabajo utilizable al amanecer y, sobre todo, que lo haga respetando las barreras de seguridad y responsabilidad necesarias para el contexto empresarial.