Esta semana pasó algo que conviene mirar dos veces. Aakash Gupta publicó el jueves el caso de Hannah Stulberg, una PM de DoorDash. El viernes publicó la cuenta: en una empresa de 50 personas, redescubrir decisiones que ya se tomaron consume 400 horas a la semana. Un año-ingeniero quemado cada dos meses. El 20% de cada hora trabajada. Entre los dos posts superaron las 89 000 vistas en 36 horas y atrajeron una conversación que vale la pena leer entera.

La tesis de IQ Source aquí es directa: cuando la IA comprime la capa de construcción, el equipo que gana es el que tiene su razonamiento pasado consultable en quince segundos. Por una nueva contratación o por un agente. Es el mismo requisito. El equipo que no lo tiene paga el 20% para siempre, lo vea en su P&L o no.

Y lo que pasó con Aakash el jueves es que finalmente alguien le puso nombre al patrón. Lo llamó Team OS (sistema operativo del equipo). En IQ Source corremos exactamente esta arquitectura desde antes de que tuviera ese nombre. Hoy te cuento qué hay adentro y por qué el viernes de Aakash es el viernes en que tu junta directiva tiene que mirarlo.

La cuenta que nadie hace

Tres números que vale la pena tener al frente cuando entras a la próxima reunión de operaciones:

47% de las empresas dicen que la pérdida de conocimiento institucional es su problema número uno cuando se va un colaborador. No el reemplazo, no el costo de la búsqueda. La pérdida del conocimiento que esa persona se llevó.

Las nuevas contrataciones tardan 6 a 7 meses en sentirse productivas. Solo el 12% de los empleados dice que su empresa hace bien la inducción. El otro 88% paga ese costo sin meterlo en ninguna línea del presupuesto.

10 preguntas de contexto por persona por día. A 10 minutos cada una entre el mensaje en Slack, la espera por la respuesta, el cambio de contexto y la vuelta al trabajo, son 8 horas por semana. La quinta hora trabajada de cada persona se va en redescubrir lo que el equipo ya decidió. En una empresa de 50 personas son 400 horas por semana. Un año-ingeniero completo quemado cada dos meses respondiendo “por qué elegimos X en lugar de Y” desde hilos de Slack que se hundieron tres semanas atrás.

Esa cuenta nadie la pone en la presentación a la junta. La razón es simple: nadie la mide. La hora perdida no aparece como línea de gasto. Aparece como velocidad lenta, como nueva contratación que tarda en arrancar, como decisión que se vuelve a discutir en la siguiente reunión.

El comentario de Tech Odyssey debajo del post de Aakash captura el cambio que está pasando ahora: la memoria del agente y la memoria del equipo están convergiendo. Las dos fallan por la misma razón: el razonamiento existe en algún lado pero no se puede recuperar en el momento de la acción. Lo que sea que arregle una arregla la otra.

Las tres capas

La arquitectura que Aakash documentó tiene tres capas. Cada una resuelve una pieza distinta del 20%.

Capa 1 — Contexto compartido. Una carpeta donde el equipo escribe. Decisiones de producto, resúmenes de llamadas con clientes, consultas de analítica que alguien escribió a las 2 a.m., arquitecturas que se discutieron en una reunión. La estructura no es la parte interesante; la parte interesante es que existe un solo lugar al que todos van a depositar el contexto. Un archivo CLAUDE.md en la raíz funciona como tabla de enrutamiento: dice qué tipo de pregunta está en qué carpeta. Con eso, el agente, o el humano, sabe a dónde ir antes de leer cualquier archivo.

Capa 2 — Consultas compartidas. Aquí el equipo pregunta. La diferencia con un wiki tradicional es que la pregunta se hace en lenguaje natural y la respuesta sintetiza lo que hay en la carpeta. Es la diferencia entre “buscar Confluence” y “preguntarle a un colega que leyó todo Confluence anoche”. El caso de Hannah Stulberg es el ejemplo: la nueva ingeniera de su equipo necesitaba contexto de una decisión de tres meses atrás. En vez de escribirle a Hannah, abrió el repo, preguntó en español, recibió el razonamiento completo en quince segundos. Hannah no estaba en línea. No hizo falta.

Capa 3 — Disciplina compartida. Esta es la capa que la mayoría de implementaciones se salta y por la que mueren. La regla aquí es una sola: la funcionalidad no sale hasta que el repo esté actualizado. La decisión no se considera tomada hasta que está escrita en el formato que el agente y la próxima persona pueden consultar. Sin esa regla, las dos capas anteriores se llenan de polvo en seis semanas. Con esa regla, el sistema se mantiene vivo solo, porque cada persona del equipo lo alimenta en el momento en que toma una decisión.

Las tres juntas son lo que hace que el repo de Hannah haya respondido la pregunta del ingeniero a las 2 a.m. sin Hannah. La capa que la mayoría intenta primero es la 2, porque es la que se ve. Pero sin la 3, la 2 se atrofia, y sin la 1, la 2 no tiene de dónde leer.

Lo que ya corremos en IQ Source

Voy a mostrar el sistema desde el uso, no desde la arquitectura.

Empieza en la primera llamada exploratoria. La transcripción se importa en el momento, sin que nadie la copie. De ahí el sistema extrae los pendientes —lo que prometimos hacer, las preguntas abiertas, los siguientes pasos— y los deja anotados contra ese cliente. Si después abrimos un proyecto, esos pendientes se propagan solos al tablero correspondiente. Y cuando alguien del equipo va a preparar una propuesta o cotizar, le pregunta al sistema en lenguaje natural: “¿Qué sabemos de este prospecto?”, “¿Qué precio cotizamos en febrero a una empresa de tamaño parecido?”, “¿Cuál fue el último traspaso con este cliente?”. La respuesta llega con citas a la fuente original de cada dato. La llamada del lunes se vuelve memoria del equipo el mismo lunes, sin paso manual.

Eso es la capa 1 alimentándose y la capa 2 consultándose. Los pendientes son la bitácora de decisiones; la propagación al proyecto es el mecanismo que hace que la decisión llegue al lugar donde se va a ejecutar; las consultas en lenguaje natural son la interfaz que cualquiera del equipo puede usar sin entrenamiento.

La capa 3 es la regla operativa. Una propuesta no se cotiza si la información del prospecto no está escrita donde el sistema la encuentra. Lo mismo con cerrar un cliente: si los pendientes del proceso comercial no quedaron capturados, el cierre no se considera completo. Y un traspaso entre dos personas del equipo solo cuenta cuando lo que se transfirió quedó por escrito. No es una guía. Es la condición para que la siguiente persona, o el siguiente agente, no tenga que reconstruir el contexto desde cero.

El resultado concreto: las decisiones de un cliente del trimestre pasado están a quince segundos de cualquiera del equipo. Una propuesta nueva se prepara con cinco años de precedentes a la vista, no con la memoria de quién estaba en la llamada del lunes. Cuando hago un viaje de tres días, los traspasos siguen pasando porque el sistema sabe a dónde van los pendientes.

Esto no es teoría. Es lo que cubrimos en marzo con el caso de Dave Killeen, CPO de Pendo, llevado un piso arriba. El sistema personal de Killeen, que es uno de los cuatro casos que Aakash documentó, lo automatiza a él. El Team OS automatiza al equipo. La diferencia es que el primero muere cuando Killeen se va. El segundo sobrevive a la rotación, a las vacaciones y al hecho de que ningún humano se acuerde de todo.

Por qué AI Maestro y Socio Tecnológico llegan aquí

Llevo 36 años en computación, desde 1990, a mis 15 años, en una Commodore 64. El problema del conocimiento institucional perdido no es nuevo. Lo que es nuevo es que la cura ahora se puede empezar a instalar en un fin de semana. Antes necesitabas Confluence, un equipo de gestión del conocimiento, taxonomías, etiquetas y seis meses para arrancar. Hoy un equipo de tres personas levanta el esqueleto en dos días: una carpeta de Markdown, un CLAUDE.md de enrutamiento, los primeros disparadores y la regla de que nada sale hasta que el repo se actualice.

El esqueleto, eso sí, no es el sistema. Llevamos un mes ajustando el brain de IQ Source todos los días y seguimos en ello. La carpeta inicial no preveía la mitad de las cosas que el equipo realmente le pregunta. Los disparadores que fijamos la primera semana se quedaron cortos cuando entró el segundo cliente y empezamos a necesitar separar pendientes de proyecto activo de los de prospecto. El CLAUDE.md de enrutamiento lo hemos reescrito tres veces porque cada vez que el equipo intenta una pregunta nueva descubre un agujero en cómo está organizada la información. Eso es trabajo real, recurrente, que no termina nunca. La diferencia con Confluence es que cada ajuste se ve reflejado en la calidad de la próxima respuesta el mismo día, no el próximo trimestre.

Para empresas de software B2B en LatAm, el Team OS no es un proyecto paralelo. Es la base sobre la que descansan nuestros dos servicios principales: AI Maestro es la versión que instalamos para el equipo del cliente, donde gobernamos cómo se procesan las llamadas, cómo se escriben las bitácoras de decisión, cómo se mantiene la disciplina, cómo se audita lo que el agente hace con esa memoria. La pregunta de la auditoría no es “tu equipo usa Claude”. Es: si llamo a tu mejor PM y le pregunto por una decisión de febrero, ¿cuánto tarda en encontrarla escrita?

Para empresas de software cuyo producto necesita seguir construyéndose mientras esto se monta, Socio Tecnológico es la otra mitad. Las tres capas viven dentro del proceso de desarrollo. Un PR solo se cierra si la decisión técnica que lo motivó quedó escrita en el repo. La publicación que sale a producción lleva amarrada una bitácora que el siguiente equipo puede leer sin tener que reconstruir el cómo y el porqué. Y los traspasos entre IQ Source y el equipo del cliente pasan por el repo, no por la siguiente reunión de calendario. Es el moat (ventaja competitiva) de flujo de trabajo que cubrí en abril, hecho operativo. Que sea cierto que el entorno de ejecución se vuelve genérico no implica que tu flujo de trabajo sea legible. Implica solo que el costo de hacerlo legible bajó.

La convergencia esta semana fue real. Aakash el jueves y el viernes. Hannah Stulberg en el Substack del 8 de mayo. Garry Tan, CEO de Y Combinator, lanzando GBrain el mismo viernes con la tesis de que el futuro pertenece a quienes construyen sistemas de IA componibles, no a quienes usan herramientas centralizadas. Cuatro micrófonos diciendo lo mismo en una semana sin coordinación. Eso suele significar que el patrón es real.

Como apuntó Marcel Velica en los comentarios: la mayor parte de la pérdida de productividad en equipos no es ejecución, es reconstrucción repetida del contexto que nunca se capturó en un sistema compartido. Lo que cambia ahora no es que el problema exista. Es que tienes la opción de no pagarlo más.

Cinco preguntas para la reunión del lunes

Empecemos con la más incómoda: ¿dónde está escrita la decisión más importante que tomó tu equipo este trimestre? Si la única respuesta posible empieza con “en la cabeza de” o “en algún hilo de Slack”, el sistema no existe. La prueba es brutal en su simplicidad: o sales de la reunión con una ruta de archivo, una fecha y un autor, o no.

La segunda hay que mirarla en frío. Una nueva contratación entra mañana lunes. Necesita el contexto de una decisión de febrero. ¿Cuánto tiempo le toma encontrarla sin interrumpir a nadie? Cuando la respuesta es “no puede”, el costo de la inducción deja de medirse en meses. Pasa a medirse en interrupciones por día durante seis meses.

Tercera pregunta, esta para la junta directiva más que para el equipo. Tu PM más experimentada renuncia este viernes. ¿Qué se va con ella? Si la respuesta es “lo que tenía en la cabeza”, tienes una colección de individuos talentosos. Si es “nada que el repo no tenga”, tienes una empresa.

La cuarta es donde casi todos fallamos. ¿Quién, con nombre y apellido, es el dueño de mantener vivo el repo del equipo? No “todos”. No “el equipo”. Una persona, con tiempo asignado en su semana, con autoridad para devolver una funcionalidad a la cola de pendientes si no actualizó la decisión correspondiente. Sin esa figura, la capa 3 no existe y las otras dos se atrofian en seis semanas.

Y la quinta es la prueba final. Cuando un agente de IA en tu empresa intente contestar la próxima pregunta de un cliente, lo que encuentre define la calidad de la respuesta. No el modelo. No el prompt. Lo que tu equipo puso por escrito ayer.

Si las cinco respuestas son sólidas, no necesitas a IQ Source para esta pieza. Si tres o más se quedan en silencio, vale una conversación. Una llamada inicial de 60 minutos sirve para una sola cosa: diagnosticar en cuál de las tres capas está tu cuello de botella real. Algunos equipos tienen capa 1 funcional pero sin disciplina; otros tienen disciplina pero la información no está donde el agente la encuentra; otros simplemente nunca escribieron una decisión por fuera de Slack. Mapear eso bien es la base. Si la conversación termina con “es claro lo que tienen que hacer”, lo haces tú con tu equipo, sin nosotros.

Cuando tiene sentido instalar el sistema, ahí entra AI Maestro. Eso no es un fin de semana ni una llamada. Llevamos un mes ajustando el brain de IQ Source todos los días, con dos clientes activos cambiándole los disparadores semana a semana, y seguimos en ello. La parte que vendemos es exactamente esa: el ciclo de ajuste continuo, el dueño nombrado de la capa 3, las reescrituras del CLAUDE.md cada vez que aparece una pregunta que el sistema no contesta bien y el registro de auditoría que sobrevive cuando cambia el CTO o el socio. La diferencia entre el equipo que arranca solo el martes y el que llega a un Team OS confiable en el trimestre suele ser que alguien con criterio externo lleve la disciplina cuando el equipo del cliente está apagando incendios de producto.

El equipo cuyo razonamiento se puede buscar en quince segundos paga uno en 2027. El que sigue contestando preguntas desde la memoria de tres personas paga tres y sigue creyendo que el problema es contratar más rápido.