Jack Dorsey y Roelof Botha acaban de publicar algo llamado From Hierarchy to Intelligence, el modelo operativo interno de Block para organizaciones nativas de IA, contado en público. Se está leyendo como un documento de arquitectura. Es en realidad un documento de estrategia, y la estrategia es la parte que importa.
La tesis, en una línea: en casi todas las empresas de hoy, el roadmap de producto tradicional es el mayor factor que limita lo que la IA puede hacer por el negocio. No el presupuesto, no el stack, no el talento. El roadmap. Porque el roadmap se diseñó para un mundo en el que la unidad de progreso era la funcionalidad, y las organizaciones nativas de IA no progresan funcionalidad a funcionalidad.
Llevo dos semanas dándole vueltas a su marco. Parte transfiere directamente a lo que estamos construyendo en Shakers. Parte no encaja en un contexto de marketplace. Casi todo merece más atención de la que ha recibido, sobre todo entre operadores españoles que siguen con ciclos trimestrales de OKR como si fuera 2019.
La unidad atómica son las capacidades, no las funcionalidades
La primera pieza de la arquitectura son las capacidades. No funcionalidades. No productos. Primitivas atómicas y accionables.
Para Block, el ejemplo que dan es limpio: «casar talento con un puesto a calidad de producción». Eso es una capacidad. Es pequeña, tiene nombre, tiene un contrato claro (entrada, salida, listón de calidad) y se puede reutilizar en muchos productos aguas abajo.
Esto importa porque las capacidades son duraderas. Una funcionalidad tiene seis meses de vida y vive dentro de un producto. Una capacidad vive a nivel de empresa y aparece en una docena de sitios. Cuando listas tus capacidades y encuentras cinco que ningún competidor puede replicar en seis meses, tienes foso. Cuando las listas y todas son commodity, no lo tienes.
La capa de abajo sostiene la estrategia. Todo lo de encima es ejecución.
El orden de operaciones en el que insisten Dorsey y Botha es la parte que casi todo el mundo se salta. Define las capacidades antes de elegir proveedor. No después. El patrón de 2024 era: elige GPT-4 o Claude, y después piensa qué construir con ello. El patrón de 2026 que defienden es: lista las cinco capacidades que necesitas, define sus listones de calidad, y después elige la combinación más barata de modelos, herramientas y acuerdos que los cumpla.
Ese orden importa porque la elección de proveedor es reversible y el inventario de capacidades no. Puedes cambiar de modelo en una semana si tus contratos de capacidad están limpios. No puedes cambiar una capacidad estratégica en un año si la construiste asumiendo que GPT-4 siempre sería más barato que su sustituto.
El modelo del mundo es tu señal honesta
La capa dos es el modelo del mundo: las entidades de negocio sobre las que opera la IA, capturadas con honestidad. Para Block: cuentas de cliente con su stack, su madurez en IA, agentes desplegados, histórico real de relación. La clave está en «honesto»: el modelo del mundo no es el CRM de marketing, es la realidad operativa.
En Shakers, nuestro modelo del mundo es el grafo de talento: cada freelancer, su stack, disponibilidad, rango de tarifa, señal de contrataciones pasadas, actividad reciente. La versión honesta de ese grafo no es la misma que el perfil de cara al usuario. El perfil de cara al usuario es lo que el talento quiere que veas. El modelo del mundo honesto es lo que hemos observado a lo largo de miles de contrataciones.
El argumento de Block es que la calidad de tu IA está acotada por la calidad de tu modelo del mundo. Si a tu modelo del mundo le falta el 30% de la señal de cliente, a tu IA le falta el 30% de la señal de cliente, y no hay actualización de modelo que arregle eso. Basura entra, basura sale, solo que más cara porque ahora puedes generar basura a escala.
La capa de inteligencia compone, no construye
La capa tres es donde vive el modelo, pero Dorsey y Botha son cuidadosos aquí. La capa de inteligencia es una capa de composición. Ensambla capacidades en sistemas. Cuando falta una capacidad (pongamos, necesitas extraer intención de un mensaje de cliente y todavía no tienes una capacidad para eso), no construyes primero la capa de inteligencia. Vuelves a la capa de capacidades, construyes la primitiva que falta, y después la capa de inteligencia compone sola.
Esta es la inversión que casi todo el mundo hace mal. Construyen primero el agente, descubren que necesita una capacidad que no existe, y parchean la pieza que falta dentro del agente. Seis meses después el agente es un prompt de 4.000 líneas con ocho capacidades escondidas dentro, y el equipo que lo construyó es el único que puede mantenerlo.
El modelo de Block dice: cuando un agente necesita una capacidad que no tienes, construye la capacidad primero, con contrato limpio, suite de evals y dueño. Después haz que el agente la llame. Esa capacidad ya es reutilizable. Los tres siguientes agentes que la necesiten también podrán llamarla. La versión del trimestre que viene de ese agente es componible en vez de monolítica.
Las interfaces son entrega, no valor
La capa cuatro son las interfaces. Cuadros de mando, UX, plataformas. Los autores de Block son tajantes: las interfaces son cómo se entrega el valor, no dónde se crea. Un cuadro de mando precioso sin capa de inteligencia debajo es una presentación. Un CLI cutre encima de una pila profunda de capacidades es un producto.
Creo que la empresa española lleva dos décadas equivocándose en esta capa, optimizando interfaces vistosas encima de sistemas delgados. La versión nativa de IA de ese error es peor porque la interfaz puede esconder mucho más. Un chatbot con interfaz pulida encima de un wrapper sobre una API de terceros parece un producto. No lo es.
La prueba que propone el marco es: si quitas la interfaz, ¿qué queda? Si la respuesta es «nada, el valor estaba en la ventana de chat», has construido una marca. Si la respuesta es «las capacidades de debajo siguen sirviendo a otras superficies», has construido infraestructura. La infraestructura compone. Las marcas no.
Tres roles, tres horizontes temporales
Block organiza los equipos alrededor de tres roles, y esta es la parte que más he masticado para Shakers.
El truco son los tres horizontes. Casi todas las empresas tienen las tres responsabilidades colapsadas en un solo rol.
Los ICs construyen y operan primitivas. Son dueños de una capacidad y la mantienen sana. No están en un proyecto. No están «entregando una funcionalidad este trimestre». Son dueños de una pieza de infraestructura de forma indefinida. Suena a rol de investigación; no lo es. Se parece más a un SRE, operador con conocimiento profundo.
Los DRIs son los responsables directos de resultados transversales. Tienen autoridad durante 90 días cada vez. Atraviesan equipos. Pueden pasar por encima de roadmaps dentro de su ventana si necesitan ensamblar capacidades de otra forma. El tope de 90 días es la parte que me parece inteligente: impide que la autoridad de DRI se calcifique en mando intermedio permanente.
Los Player-Coaches construyen y desarrollan personas. Son los únicos con permiso para dedicar la mitad de su tiempo a mentoría. El resto de la organización espera que mentoricen en esa proporción; la estructura lo presupuesta.
La forma que esto le da a un equipo es rara. No hay «engineering manager» en el sentido tradicional. Hay un IC dueño de una capacidad, un DRI rotatorio que compone capacidades en un resultado de producto, y un Player-Coach responsable del crecimiento del siguiente IC y del siguiente DRI. Se parece más a un equipo deportivo que a un organigrama.
Tres cosas a las que vuelvo
No copiaría el marco de Block entero. Un contexto de marketplace introduce restricciones que un negocio de pagos no tiene, y los marcos viajan mal entre formas organizativas. Pero tres piezas me siguen funcionando en la cabeza.
Capacidades antes que proveedores. La disciplina de nombrar, contratar y escribir una eval de referencia antes de aprobar una integración de modelo suena obvia y casi nunca ocurre así. Si un equipo no sabe escribir la eval, no tiene una capacidad: tiene un deseo. Casi todos los roadmaps de IA están hechos de deseos presentados como capacidades.
Modelo del mundo honesto. La versión de la realidad de negocio sobre la que opera la IA rara vez es la misma que enseña el CRM de marketing. El hueco entre las dos es donde casi toda la IA en producción falla en silencio. Nombrar ese hueco explícitamente, y obligar a la IA a consultar la versión honesta, importa más que elegir el modelo correcto.
La rotación de DRI cada 90 días. Un responsable directo con autoridad transversal limitada a 90 días es la parte del marco que me resulta más contraintuitiva y más digna de pensar. El tope es lo que evita que la autoridad se concentre en mando intermedio permanente. El riesgo es que 90 días sea poco para iniciativas complejas. La ventaja son los relevos limpios.
Cierre
El marco de Block es bueno no porque sea novedoso (casi todas estas ideas están en libros de 2010) sino porque fuerza un orden de operaciones concreto. Capacidades, después modelo del mundo, después capa de inteligencia, después interfaces. No al revés. Casi todas las empresas construyen invertido: entregan una interfaz, parchean la inteligencia para que funcione, corren sobre el modelo del mundo que dejó el CRM anterior, y tratan las capacidades como algo secundario.
Ese orden produce software que demostra bien y se pudre rápido. El orden de Block produce software que demostra despacio y compone. En un ciclo de IA donde el apalancamiento lo es todo, tengo claro cuál preferiría estar construyendo.