La orquesta de agentes: por qué 3 especialistas vencen a 1 generalista en producción
El modelo de 'un agente hace todo' tocó techo. La próxima generación coordina equipos de agentes especializados — con contextos aislados, worktrees, lista de tareas compartida y puertas de calidad. Inspirado en Addy Osmani, adaptado al stack de Gemini Enterprise Agent Platform que operamos en Autenticare.
Fabiano Brito
CEO & Founder
El techo del agente único
Quien lleva más de seis meses trabajando con agentes ya lo sintió: hay una meseta en la que añadir más prompts deja de acelerar. Tres restricciones explican el techo:
📚 Sobrecarga de contexto
Bases reales de cliente exceden cualquier ventana. Cuando el agente intenta "recordar" todo a la vez, olvida lo esencial.
🎯 Sin especialización
Un agente que hace base de datos, API, UI y tests se vuelve "todólogo" — maestro de nada. El agente que solo conoce la capa de datos escribe mejor SQL.
🚦 Sin coordinación
Varios agentes sin primitivos de coordinación (locks de archivo, dependencias de tarea) se vuelven caos. Los conflictos de merge se comen las ganancias de paralelismo.
Director vs orquestador
La metáfora que mejor captura el cambio (se la debemos a Addy Osmani): pasas de director — guiando a un único músico en tiempo real — a orquestador — coordinando una orquesta entera de forma asíncrona. El hilo de chat deja de ser tu entorno; el repositorio (y el tablero de tareas) ocupa su lugar.
| Dimensión | Director (1 agente) | Orquestador (equipo) |
|---|---|---|
| Modo | Síncrono — esperas cada respuesta | Asíncrono — planeas y revisas |
| Contexto | Tu ventana es el techo | N ventanas independientes, una por especialista |
| Throughput | 1× — secuencial | ~3× con 3 agentes en paralelo |
| Workspace | Hilo de chat | Repo + worktrees + lista de tareas |
| Tu rol | Tipeador de prompts | Ingeniero de proceso: spec, gates, retro |
Tres patrones de orquestación
En producción usamos tres patrones — elegidos por alcance de la tarea, no por moda:
🌿 Subagents
El padre descompone, delega a hijos enfocados, gestiona el grafo de dependencias manualmente. Sin setup — empieza hoy. Coste neutro en tokens.
- Setup
- Ninguno
- Sweet spot
- 2–4 hijos
👥 Agent Teams
Team Lead + lista de tareas compartida con lock de archivo + mensajería peer-to-peer. Auto-desbloqueo cuando caen las dependencias.
- Sweet spot
- 3–5 agentes
- Coordinación
- Task list + locks
☁️ Cloud Async
Asignas la tarea, cierras el laptop, vuelves al PR. Corre en VMs gestionadas — en nuestro caso, sobre Agent Runtime de Gemini Enterprise Agent Platform.
- Modo
- Fire-and-forget
- Sesión
- Días continuos
El cuello de botella ya no es generación. Es verificación. La revisión humana no es overhead opcional — es el sistema de seguridad.
Los números que importan
3 agentes en paralelo
por encima, dispersión
+20% de coste (ETH Zurich)
El número de la derecha es importante: una investigación de Gloaguen et al. (ETH Zurich) muestra que dejar a los agentes escribir su propio AGENTS.md degrada el desempeño en ~3% y aumenta el coste en más de 20%. El AGENTS.md debe ser curado por humano — es lo que codifica el conocimiento institucional del equipo.
AGENTS.md: el cerebro compartido
Cuatro secciones bastan:
## STYLE
- Componentes funcionales con hooks; named exports
- Errores siempre tipados; nunca `throw "string"`
## GOTCHAS
- SQLite requiere WAL para lecturas concurrentes
- El orden de los middlewares Express importa para auth
## ARCH_DECISIONS
- Estado en SQLite, sin caché en memoria
- Un Express router por feature module
## TEST_STRATEGY
- Integration > unit para rutas HTTP
- supertest para aserciones de requestCada sesión lee. Ningún agente escribe directamente — el lead aprueba cada línea que entra.
5 prácticas para empezar mañana
Descompón la tarea en 2–3 hijos con alcance quirúrgico. Sin setup. Es la forma más barata de probar la tesis internamente.
Cada agente en su propio worktree git. Cero conflictos de merge — y un diff por feature trivial de revisar.
Teammate escribe el plan; lead aprueba o rechaza. Corregir arquitectura en fase de plan cuesta 1/10 de corregirla en código.
En TaskCompleted, valida automáticamente. Si falla, el agente sigue trabajando. El lead solo ve código en verde — funciona como CI integrado.
Cada sesión lee, el lead actualiza. Patrones y gotchas se vuelven memoria de largo plazo del equipo — no se redescubren cada sprint.
Qué cambia en Autenticare
Este modelo solo cierra en producción cuando hay infraestructura para sostenerlo. Es exactamente lo que el Gemini Enterprise Agent Platform (anunciado el 22/04 — análisis completo aquí) entregó:
- Agent Runtime da las “VMs gestionadas” del patrón Cloud Async — cold start <1s, sesiones de días.
- Memory Bank + Memory Profiles es
AGENTS.mdelevado a primitivo de plataforma — memoria de largo plazo entre sesiones. - Agent Sandbox es el worktree aislado en producción — el código generado corre sin riesgo para el sistema real.
No es coincidencia. El camino de la industria es el mismo: del prompt aislado a la fábrica de agentes.
Ya no estás escribiendo software. Estás construyendo la fábrica que escribe el software.
¿Quieres pasar del agente único a una orquesta?
Estructuramos equipos de 3 a 5 agentes sobre Gemini Enterprise Agent Platform — con worktrees, AGENTS.md curado, hooks de calidad y plan approval. Auditable, repetible y medible.
Inspirado en "The Code Agent Orchestra" de Addy Osmani (Google Chrome). Adaptado al stack que operamos en Autenticare sobre Gemini Enterprise Agent Platform.