El 15 de abril, Adam Miller — Distinguished Engineer en Red Hat — publicó en LinkedIn un ensayo titulado “Stop building agents, start harnessing Goose”. Jack Dorsey lo reposteó el 16 en X. La tesis de Miller, en una línea:

Para más del 90% de los casos de uso, si estás implementando un agente desde cero, ya perdiste la carrera. Goose es el bloque común. Tu ventaja competitiva está en el harness.

Miller tiene razón en casi todo. Casi.

Qué dice Miller y por qué suena bien

Miller describe a Goose — el runtime de agente open source que Block donó a la Linux Foundation — como un motor minúsculo con una arquitectura de extensiones MCP. El núcleo es un loop interactivo más gestión de contexto. Todo lo demás entra por plugins.

El argumento: el 90% de las empresas están reimplementando lo mismo. Parsers de tool-calling, gestión de ventana de contexto, librerías cliente de MCP, orquestación de sub-agentes. Trabajo ya resuelto, firmado por una fundación neutral. Miller cita a Ralph Bean y a Birgitta Böckeler: el harness es la capa de habilitación — AGENTS.md, skills, tools custom, linters hechos a mano, system prompts. Ahí es donde debe ir tu ingeniería.

Comparto la mitad del diagnóstico. Reescribir el loop de un agente cuando Goose o Claude Code ya lo resolvieron es desperdiciar equipo senior en plomería.

Lo que me detiene es la conclusión: “elige tu harness, no tu agente”. Esa frase trata al runtime como commodity intercambiable. Y cuando miras el harness más avanzado que existe público hoy, te das cuenta de que el runtime no es commodity. Nunca lo fue.

Exhibit A: el Team OS de Hannah Stulberg

Aakash Gupta publicó ayer un hilo con diez cosas que aprendió de Hannah Stulberg, PM en DoorDash y ex Google APM, con más de 1.500 horas en Claude Code. El hilo es la documentación pública más completa que existe de un harness maduro. Vale la pena leer los diez puntos enteros, pero estos son los que importan para esta conversación:

Punto 4: los CLAUDE.md anidados actúan como tablas de ruteo. Una consulta de cliente en la demo consumió solo 3% de la ventana de contexto. Claude no entró a analytics, no entró a data engineering, no leyó un solo archivo innecesario. Eso deja 97% de espacio para razonamiento.

Lee esa frase dos veces. El harness de Hannah no está “encima” de Claude Code. Está entretejido con el comportamiento específico de cómo Claude Code carga contexto. Si Claude Code cargara todo el repo de golpe, los CLAUDE.md anidados no servirían para nada. El 3% vs 97% es una consecuencia directa del runtime.

Sigue el hilo:

• Punto 3: el CLAUDE.md raíz es extremadamente delgado. Indexa docs, lista el equipo con handles de Slack para que puedas escribir “Slack Alex about the bug” y Claude use el Slack MCP. Eso también depende del runtime — Goose usa extensiones MCP distintas y no consume el mismo índice de handles del mismo modo.
• Punto 7: modo plan (Shift+Tab twice). Hannah lo describe como “quitarle las llaves a un empleado junior impaciente”. Modo plan es una feature específica de Claude Code. Goose no lo tiene. Para replicarlo necesitas un recipe con subrecipes de “planificar” seguidos de “ejecutar”, y ni siquiera así se comporta igual porque la sesión principal no pierde su sesgo a la acción del mismo modo.
• Punto 8: para documentos largos, Hannah divide la escritura entre varios sub-agentes. Cada sub-agente recibe archivos de contexto específicos y escribe a un archivo temporal. Sin temp files, diez sub-agentes regresando simultáneamente crashean la sesión y pierdes todo. Esa restricción — “diez agentes simultáneos crashean” — es una característica específica del runtime de Claude Code. Goose corre subrecipes en sesiones aisladas con semántica distinta.
• Punto 8 cont.: los skills se auto-invocan solo el 70% de las veces. Por eso hay que listarlos explícitamente en el plan. Ese 70% es un número específico de Claude Code. La invocación de extensiones en Goose tiene otro perfil.
• Punto 9: los archivos de plan nativos se borran cada 24 a 72 horas. Por eso Hannah guarda el plan en el repo. Esa ventana de retención también es específica del runtime.

Suma todo. El Team OS de Hannah no es una capa portable que casualmente corre sobre Claude Code. Es un sistema operativo construido para Claude Code, optimizado contra su semántica de contexto, su modelo de sub-agentes, su aislamiento de skills y su ciclo de vida de planes. Cambia el runtime y rompes el sistema.

Qué pasa cuando intentas portar

Hagamos el experimento mental. Mañana tu CTO dice: “Leí a Miller, movamos el Team OS de nuestro equipo de producto de Claude Code a Goose para reducir vendor lock-in.”

Primera rotura: los CLAUDE.md anidados. Goose no tiene ese mecanismo de ruteo. El equivalente es un recipe YAML con subrecipes por dominio. Pero los subrecipes corren en sesiones aisladas — sin historial compartido, sin memoria, sin estado. El patrón de “consulta entra, Claude rutea a la subcarpeta correcta, contexto se mantiene” se pierde. Tienes que rediseñar cómo se comparte contexto entre etapas.

Segunda rotura: modo plan. Goose no lo tiene. Replicarlo requiere una coreografía de subrecipes — planificador primero, ejecutor después — con un protocolo explícito de handoff. No es imposible; es otro sistema.

Tercera rotura: skills. Los skills de Claude Code son markdown con auto-invocación basada en coincidencia de descripción. Las extensiones MCP de Goose son servicios externos que el agente descubre via protocolo. Semántica distinta, perfil de latencia distinto, modelo de seguridad distinto. No es traducir; es reescribir.

Cuarta rotura: el número mágico. “Diez sub-agentes simultáneos crashean sin temp files” es una restricción de Claude Code. Goose tiene sus propios límites — distintos, calibrados contra su propia arquitectura. Las 1.500 horas que Hannah pasó descubriendo esos límites en Claude Code no se heredan. Empiezas de cero.

Quinta rotura: el modelo mental completo del equipo. La gente que sabe usar el Team OS sabe usar Claude Code. Mudarlos a Goose implica volver a entrenar el músculo.

Ninguna de estas roturas es catastrófica. Sumadas, son un rediseño.

El lock-in de framework volvió

Durante quince años el discurso de la industria fue: elige frameworks portables, abstrae al proveedor, evita lock-in. React sobre Angular, Kubernetes sobre ECS, SQL ANSI sobre dialectos. La buena práctica era maximizar la opcionalidad.

Con agentes de IA esa lógica se rompe.

El runtime de agente no es un framework de UI. No es un orquestador de contenedores. Es un sistema operativo con un modelo de memoria, un modelo de concurrencia, un ciclo de vida y una capa de aislamiento que tu harness tiene que explotar para ser rápido. Las abstracciones útiles — ACP de Zed, MCP — son estándares a nivel de protocolo. No te dan paridad de comportamiento. Te dan interoperabilidad en un subconjunto de operaciones.

Armin Ronacher lo escribió así en noviembre: “el beneficio de las abstracciones no supera todavía el costo”. Su recomendación es trabajar directo contra los SDK de los proveedores porque los pares modelo-runtime tienen diferencias semánticas que las abstracciones esconden mal.

Miller y Ronacher están mirando el mismo problema desde lados opuestos. Miller ve un loop interactivo común y concluye que todo lo de encima es sustituible. Ronacher ve diferencias de cache, de formato de tool call, de manejo de fallos, y concluye que las abstracciones actuales son prematuras.

La evidencia del Team OS da la razón a Ronacher, no a Miller.

La decisión real

Elegir runtime de agente en 2026 es una decisión arquitectónica de primer nivel. El mismo peso que elegir base de datos, proveedor de cloud o lenguaje de backend. Los criterios que importan son los mismos:

• Modelo de memoria. ¿Cómo carga contexto? ¿Carga perezosa jerárquica, carga eager, híbrido?
• Modelo de concurrencia. ¿Cuántos sub-agentes puedes correr? ¿Con qué aislamiento? ¿Qué pasa cuando regresan todos a la vez?
• Ciclo de vida de artefactos. ¿Los planes, las memorias, los skills — viven cuánto tiempo? ¿Dónde se persisten?
• Superficie de extensión. ¿Markdown con auto-invoke, MCP remoto, recipes YAML, plugins nativos? Cada opción tiene trade-offs de latencia, seguridad, portabilidad.
• Gobernanza. ¿Quién controla el roadmap? Anthropic, OpenAI, Block + Linux Foundation, comunidad. Cada gobierno implica un contrato implícito de estabilidad distinto.

Esto no es elegir un tema de editor. Es una decisión que moldea los siguientes dos años de tu equipo.

El moat (ventaja competitiva) tampoco está donde Miller lo pone. No está “en el harness” — porque el harness es inseparable del runtime que lo hospeda. Está en el par. En las 1.500 horas que tu equipo invierte descubriendo cómo este runtime específico se comporta bajo tu carga real. Ese aprendizaje no es portable. Por eso es defendible.

Qué hacemos en IQ Source

Cuando un cliente nos contrata para acelerar su adopción de agentes, la primera conversación no es sobre qué skills escribir. Es sobre qué runtime correr. Si ya hay un runtime instalado sin decisión explícita — alguien probó Claude Code porque salió una demo viral, alguien más instaló Goose porque leyó a Miller — ese es el primer tema.

Revisamos cinco cosas antes de autorizar el siguiente mes de inversión en harness:

1. Qué carga de trabajo real tiene que soportar el runtime. No hipotética. La de los próximos seis meses.
2. Qué comportamientos del runtime explotará el harness. Con nombres específicos — aislamiento de sub-agentes, carga perezosa, persistencia de planes.
3. Qué parte del harness quedará atada a ese runtime y qué parte será genuinamente portable. Casi siempre mucho menos de lo que el equipo cree.
4. Cuál es el plan de salida si cambia la gobernanza del runtime. No para ejecutarlo. Para saber qué tan caro sería si llegara el día.
5. Cómo se mide la velocidad del par runtime-harness versus las alternativas. Sin esa medición, la decisión se vuelve religión.

Ese ejercicio es parte del AI Agent Maestro. Y se conecta directamente con el modelo de revisión a escala que describimos ayer: el harness no solo tiene que ser rápido, tiene que producir trabajo revisable. Esa propiedad también depende del runtime.

Si estás por invertir tres meses de ingeniería en construir tu harness, dibújate primero a qué runtime lo estás atornillando y qué pasa el día que quieras cambiarlo. Si el dibujo te sale en blanco, la conversación que tenemos que tener no es sobre skills. Es sobre arquitectura.