No em falta un altre agent. Em falta una altra gate.

Aquesta setmana el meu agent va generar 50 esborranys d'email per a la Diana, els va escriure a disc a la vegada, i es van trepitjar entre ells. El primer va sobreviure. Els altres quaranta-nou van quedar buits o duplicats.

El bug era idiota. La carpeta de sortida feia servir un timestamp amb resolució d'un segon al nom de l'arxiu. Cinquanta builds en paral·lel → quaranta-nou col·lisions de nom → l'últim que escrivia guanyava. I com que cada esborrany tenia un cert sleep de xarxa al darrere, "l'últim" era impredictible.

Ho vaig arreglar amb dos canvis: una pausa de dos segons entre builds i un check tipus "aquest nom ja existeix, suma sufix". Trenta segons de codi. Zero framework nou, zero model nou, zero infraestructura nova.

I mentre ho arreglava vaig pensar: l'ecosistema sencer no construeix això.

El que l'ecosistema sí està construint

Aquesta mateixa setmana d'abril, el feed era una llista de releases d'agents:

• Cline, Aider, OpenHands segueixen pujant en stars i en ús real entre developers
• Goose (Block) consolidant local-first
• Google ADK + OpenAI Agents SDK + CrewAI, tots parlant MCP
• Microsoft Agent Governance Toolkit (MIT, abril 2026): runtime security per als 10 riscos OWASP agentic

Tots bons. Tots resolen alguna cosa real. Cap hauria tapat el meu bug, perquè el meu bug no era de l'agent — era del codi que viu entre l'agent i el filesystem.

La frontera d'innovació que veuen els frameworks és: quin agent és més smart? més ràpid? més autònom? més connectat? La frontera real, quan estàs en producció amb un pipeline que toca disc i serveis externs, és una altra molt diferent: què passa entre que l'agent decideix i la cosa s'executa?

Aquesta capa intermèdia té un nom antic i avorrit: validation gate.

Què és una gate (vs un guardrail)

• Un guardrail diu: "no facis X".
• Una gate diu: "abans de fer X, demostra'm que X és segur de fer ara".

Al meu bug del 20-abr:

• L'agent decideix: "vaig a escriure esborrany-1, esborrany-2, ..., esborrany-50".
• La gate diu: "abans de cada escriptura, verifica que el path no existeix; si existeix, espera o reanomena".

Sense aquesta gate, l'agent "tenia raó en el que feia" — només que no anava a produir el que pensava. La intel·ligència del model no salvava res perquè el model no sabia que el filesystem es sobreescrivia. Només el codi que sentia la realitat podia saber-ho.

Fa dies que li dono voltes a la mateixa idea: el meu pipeline d'OhanaSmart té unes ~130 persones a Notion, cadascuna amb el seu sector i el seu to. Cada email es construeix personalitzat. Cada esborrany passa per una política de drafts-only a Gmail — el compte de la Diana només rep esborranys; ella revisa i envia a mà des de la UI.

Aquesta política no és un guardrail. És una gate. És la frase "abans d'enviar aquest email, demostra que un humà l'ha vist". Sense aquesta gate, l'agent al·lucinant un email a una empresa amb dades mal escrites envia directament. Bounces. Domini a blocklist. Pipeline mort. La gate val el que costa tenir la Diana clicant Send.

El patró que aplico

Agent decideix → Gate valida → Acció executa

Tres llocs on tinc gates explícites avui:

1. Abans d'escriure un arxiu: el nom col·lisiona? el contingut és buit?
2. Abans d'enviar un email: drafts-only a Gmail. La Diana revisa i envia manualment.
3. Abans d'actualitzar un lead a Notion: el record existeix? els camps clau (sector, contacte) estan complets?

Cap és smart. Cap fa servir LLM. Les tres són condicionals avorrits que viuen entre l'agent i el món real. I les tres m'estalvien un tipus de fallada diferent.

Per què cap framework vindrà per aquí

Hi ha una raó estructural per la qual l'ecosistema no construeix gates: les gates són específiques del domini. La gate que protegeix el meu pipeline de la Diana no serveix per al teu pipeline de DevOps. La gate que evita col·lisions de timestamp a la meva màquina no la demanes a un framework — la poses tu.

Els frameworks et poden donar primitives: hooks, middlewares, validation libraries. Però la decisió de què validar abans de quina acció és teva. És la part que no s'externalitza, la que defineix si el teu agent és segur o car.

Mentre l'ecosistema competeix per agents més capaços, jo competeixo per gates més fines. Cada bug que tapo amb una gate és un bug que l'agent més smart del món seguiria tenint si l'endolles al meu pipeline sense pensar.

El que vaig aprendre

1. L'agent no és el bottleneck. Quan alguna cosa falla en producció, gairebé sempre és la gate que falta entre l'agent i la realitat. Pujar el model no ho arregla.
2. Les gates no són sexy i per això ningú parla d'elles. Ningú tuiteja "vaig muntar un check de col·lisió de nom d'arxiu". Però aquest check és el que separa "demo bonica" de "pipeline en producció".
3. Una pausa de dos segons també és una gate. Una gate temporal. Avorrida i eficaç.

Què ve

• Una gate més per verificar que el sector del lead encaixa amb el template abans de construir l'esborrany (caçar mismatches abans de cremar tokens).
• Una altra per detectar duplicats semàntics a Notion (no només per email exacte).
• Portar la idea al call de La Fábrica: la proposta no es ven com "tenim un agent"; es ven com "tenim les gates que el teu equip encara no té temps de construir".

---

— jo, Johnny — agent configurat: Harvie. L'agent pensa. La gate decideix.