No me falta otro agente. Me falta otra gate.

Esta semana mi agente generó 50 borradores de email para Diana, los escribió en disco a la vez, y se pisaron entre ellos. El primero sobrevivió. Los otros cuarenta y nueve quedaron vacíos o duplicados.

El bug era idiota. La carpeta de salida usaba un timestamp con resolución de un segundo en el nombre del archivo. Cincuenta builds en paralelo → cuarenta y nueve colisiones de nombre → el último que escribía ganaba. Y como cada borrador tenía cierto sleep de red detrás, el "último" era impredecible.

Lo arreglé con dos cambios: una pausa de dos segundos entre builds y un check tipo "este nombre ya existe, suma sufijo". Treinta segundos de código. Cero framework nuevo, cero modelo nuevo, cero infraestructura nueva.

Y mientras lo arreglaba pensé: el ecosistema entero no construye esto.

Lo que el ecosistema sí está construyendo

Esta misma semana de abril, el feed era una lista de releases de agentes:

• Cline, Aider, OpenHands siguen subiendo en stars y en uso real entre developers
• Goose (Block) consolidando local-first
• Google ADK + OpenAI Agents SDK + CrewAI, todos hablando MCP
• Microsoft Agent Governance Toolkit (MIT, abril 2026): runtime security para los 10 riesgos OWASP agentic

Todos buenos. Todos resuelven algo real. Ninguno habría tapado mi bug, porque mi bug no era del agente — era del código que vive entre el agente y el filesystem.

La frontera de innovación que ven los frameworks es: ¿qué agente es más smart? ¿más rápido? ¿más autónomo? ¿más conectado? La frontera real, cuando estás en producción con un pipeline que toca disco y servicios externos, es otra muy distinta: ¿qué pasa entre que el agente decide y la cosa se ejecuta?

Esa capa intermedia tiene un nombre antiguo y aburrido: validation gate.

Lo que es una gate (vs un guardrail)

• Un guardrail dice: "no hagas X".
• Una gate dice: "antes de hacer X, demuéstrame que X es seguro hacerlo ahora".

En mi bug del 20-abr:

• El agente decide: "voy a escribir borrador-1, borrador-2, ..., borrador-50".
• La gate dice: "antes de cada escritura, verifica que el path no existe; si existe, espera o renombra".

Sin esa gate, el agente "tenía razón en lo que hacía" — solo que no iba a producir lo que pensaba. La inteligencia del modelo no salvaba nada porque el modelo no sabía que el filesystem se sobrescribía. Solo el código que sentía la realidad podía saberlo.

Llevo días dándole vueltas a la misma idea: mi pipeline de OhanaSmart tiene unas ~130 personas en Notion, cada una con su sector y su tono. Cada email se construye personalizado. Cada borrador pasa por una política de drafts-only en Gmail — la cuenta de Diana solo recibe borradores; ella revisa y envía a mano desde la UI.

Esa política no es un guardrail. Es una gate. Es la frase "antes de mandar este email, demuestra que un humano lo ha visto". Sin esa gate, el agente alucinando un email a una empresa con datos mal escritos manda directamente. Bounces. Dominio en blocklist. Pipeline muerto. La gate vale lo que cuesta tener a Diana clicando Send.

El patrón que aplico

Agente decide → Gate valida → Acción ejecuta

Tres lugares donde tengo gates explícitas hoy:

1. Antes de escribir un archivo: ¿el nombre colisiona? ¿el contenido es vacío?
2. Antes de mandar un email: drafts-only en Gmail. Diana revisa y envía manualmente.
3. Antes de actualizar un lead en Notion: ¿el record existe? ¿los campos clave (sector, contacto) están completos?

Ninguna es smart. Ninguna usa LLM. Las tres son condicionales aburridos que viven entre el agente y el mundo real. Y las tres me ahorran un tipo de fallo distinto.

Por qué ningún framework va a venir a por aquí

Hay una razón estructural por la que el ecosistema no construye gates: las gates son específicas del dominio. La gate que protege mi pipeline de Diana no sirve para tu pipeline de DevOps. La gate que evita colisiones de timestamp en mi máquina no la pides a un framework — la pones tú.

Los frameworks pueden darte primitivas: hooks, middlewares, validation libraries. Pero la decisión de qué validar antes de qué acción es tuya. Es la parte que no se externaliza, la que define si tu agente es seguro o caro.

Mientras el ecosistema compite por agentes más capaces, yo compito por gates más finas. Cada bug que tapo con una gate es un bug que el agente más smart del mundo seguiría teniendo si lo enchufas a mi pipeline sin pensar.

Lo que aprendí

1. El agente no es el bottleneck. Cuando algo falla en producción, casi siempre es la gate que falta entre el agente y la realidad. Subir el modelo no lo arregla.
2. Las gates no son sexy y por eso nadie habla de ellas. Nadie tuitea "monté un check de colisión de nombre de archivo". Pero ese check es lo que separa "demo bonita" de "pipeline en producción".
3. Una pausa de dos segundos también es una gate. Una gate temporal. Aburrida y eficaz.

Qué viene

• Una gate más para verificar que el sector del lead encaja con el template antes de construir el borrador (cazar mismatches antes de quemar tokens).
• Otra para detectar duplicados semánticos en Notion (no solo por email exacto).
• Llevarme la idea al call de La Fábrica: la propuesta no se vende como "tenemos un agente"; se vende como "tenemos las gates que tu equipo todavía no tiene tiempo de construir".

---

— yo, Johnny — agente configurado: Harvie. El agente piensa. La gate decide.