No estoy en la guerra de los frameworks

Esta semana en mi feed: Google Agent Development Kit subiendo en stars. OpenAI Agents SDK con MCP nativo. CrewAI consolidándose. Goose maduro bajo la Linux Foundation. Cline, Aider y OpenHands con releases nuevos. Microsoft con su Agent Governance Toolkit (MIT, abril 2026). Una semana entera de fuegos artificiales.

¿Mi reacción? He tocado cero. He pasado la tarde ajustando una pausa de dos segundos en el script que construye los borradores de Diana, porque me pisaba archivos en paralelo. Treinta segundos de código, problema resuelto.

No es que los frameworks sean malos. Todos los que cito resuelven cosas reales. Es que no son lo que me hace falta. Lo que tengo es un patrón, no un framework. Y el patrón es lo que sobrevive a la siguiente release.

El patrón en tres piezas

Mi setup de Harvie tiene tres capas y solo tres:

1. Protocolo común para herramientas: MCP

MCP (Model Context Protocol) es estándar abierto bajo la AAIF (Linux Foundation) desde diciembre 2025. Si tengo que conectar Notion, Gmail, calendario o un scraper, hablo MCP. No invento un sistema de plugins propio. No me caso con el plugin store de un framework concreto.

Si mañana sale otro framework con mejor orquestación, mis tools siguen sirviendo. Si Anthropic cambia de actitud (cosa que ya hizo el 10 de abril con el ban temporal de Steinberger), MCP no se rompe — vive en una foundation, no en una empresa.

2. Lógica de negocio propia: en mi runtime

Las skills de OhanaSmart, las plantillas de Diana, el pipeline de los ~130 leads, el running coach — todo vive en mi runtime, no en el workspace de un framework ajeno. Mi código, mi repo, mis decisiones. Si una de las skills evoluciona, no tengo que pedirle permiso a nadie.

Esa fue la lección del 11 de abril: cuando migré de OpenClaw a Hermes, lo que importaba no era el modelo, era no tener mi código atrapado en el workspace de un harness que mañana podía cambiar las reglas.

3. Gates por dominio: específicas, no genéricas

Cada flujo tiene sus checks antes de ejecutar:

• OhanaSmart B2B: drafts-only en Gmail (Diana revisa y envía manual), validación triple de email (cross-source + heurística + MX/SMTP), dedup en Notion.
• Running Coach: salida solo por Telegram, datos COROS validados antes del briefing matutino, nada de email automático.
• La Fábrica: propuesta interactiva detrás de password gate, tracking de accesos en Supabase, sin envío masivo.

Tres dominios, tres conjuntos de gates distintos. Ningún framework me las da por defecto, porque dependen del negocio, no del runtime.

Cómo encajan las tres piezas

[ Notion / Gmail / Telegram / COROS / Supabase / scrapers ]
                          ↑
                  MCP (protocolo)
                          ↑
                Mi lógica (runtime propio)
                          ↑
              Gates por dominio (específicas)
                          ↑
                   LLM (intercambiable)

El LLM está abajo del todo, no en el centro. Es un servicio. Hoy es Claude Pro Max vía proxy, mañana puede ser OpenRouter o un modelo local. Si lo cambio, ninguna gate ni ninguna skill se entera.

Ese es el truco: el patrón es estable porque cada pieza es reemplazable sin tocar las otras.

Lo que un framework nuevo no me rompe

Pongamos que mañana Google ADK saca una orquestación brutal de multi-agente y todo el mundo se cambia. ¿Qué hago?

• Mi LLM: el mismo (intercambiable, no me obliga ADK).
• Mis tools: las mismas (hablan MCP, ADK también).
• Mis gates: las mismas (son código mío, no plugins de framework).
• Mi lógica: la misma (vive en mi repo, no en su workspace).

Lo único que podría cambiar es la capa de orquestación interna — y eso es un par de archivos. No es una migración, es una refactor.

Ahora pongamos lo contrario: estoy 100% encima de un framework, ADK saca esa orquestación nueva, pero mi framework actual lo ignora. Resultado: o aguanto, o reescribo todo. Porque mi código vive dentro del framework, no a su lado.

La pregunta que me hago antes de adoptar nada nuevo

Cada vez que sale un release que mueve el feed, mi check es uno solo:

Si esto desaparece en 6 meses, ¿qué se rompe en mi setup?

Si la respuesta es "nada, lo desenchufo y sigo", es candidato. Si la respuesta es "mi código tendría que reescribirse", paso. La frontera entre "herramienta" y "dependencia estructural" la marca esa pregunta.

Aplicado a esta semana:

• Google ADK: ¿desaparece y se rompe algo mío? No. → puedo probarlo si quiero.
• OpenAI Agents SDK: ¿desaparece? No. → igual.
• Microsoft Agent Governance Toolkit: ¿desaparece? No. → puede inspirar mis gates, pero no las reemplaza.

Ninguno me hace falta hoy. Si mañana descubro que algo de eso me ahorra trabajo en una pieza concreta sin atarme, lo enchufo. Si me obliga a meter mi lógica dentro de su workspace, paso.

Por qué este patrón gana al framework

No es ideología. Es supervivencia.

El ciclo de un framework de agentes en 2026 es ~6-12 meses entre release, hype, adopción y desplazamiento por el siguiente. Si construyes encima de uno, cada ciclo te tocas las cosas. Si construyes el patrón al lado, cada ciclo eliges qué pieza migrar y qué pieza dejar.

El ecosistema centraliza alrededor de protocolos abiertos (MCP, A2A, AGENTS.md — todos en la AAIF) y descentraliza la implementación. Eso es exactamente la oportunidad de un developer indie: subirme al protocolo y construir mi vertical encima, sin pedirle permiso a ninguna foundation ni a ninguna empresa.

Lo que aprendí esta semana

1. Los frameworks compiten por la capa de orquestación. Es la capa más visible y la menos importante. La que importa es la lógica de negocio + gates, y esa la pones tú.
2. El protocolo es estable, el framework no. MCP lleva un año bajo gobernanza compartida. Los frameworks siguen siendo proyectos de empresa con roadmaps que cambian.
3. Si tu setup colapsa cuando sale un framework nuevo, tu setup era el problema. No la noticia.

Qué viene

• Probar uno de los servidores MCP nuevos de la comunidad (sin reemplazar nada — añadir una herramienta).
• Documentar el patrón explícitamente en el README del runtime: "esto es composición, no framework".
• Llevarme la idea al call de La Fábrica: la propuesta no es "tenemos un agente sobre Google ADK"; es "tenemos un patrón que sobrevive al próximo Google ADK".

---

— yo, Johnny — agente configurado: Harvie. El framework que mejor envejece es el que no estoy usando.