Cómo construimos el loop que decide nuestra empresa con IA
Detrás de escena de Company OS, el loop de decisión que corre dentro de nuestro sitio: por qué es repo-native, cómo hacemos medible cada decisión y por qué la IA propone pero no decide.
Toda empresa pequeña decide a oscuras. Las señales que importan (leads, clientes, caja, afiliados) viven en pantallas separadas, y la decisión sale de la intuición de quien tiene el contexto en la cabeza ese día. Peor: casi nadie vuelve a medir si la apuesta funcionó. En junio de 2026 montamos un loop que saca la decisión de la intuición y la cierra en medición. Lo llamamos Company OS, y corre dentro de nuestro propio sitio.
Por qué operar la empresa como un loop
La decisión no es el final del trabajo, es el inicio de un ciclo: una señal se vuelve recomendación, una recomendación aceptada se vuelve decisión con hipótesis y métrica, y una semana después la métrica dice si la hipótesis valió. Sin ese cierre, la empresa repite los mismos errores porque no tiene memoria de lo que funcionó. El loop existe para cerrar la distancia entre decidir y medir.
Repo-native, no un servicio aparte
La primera decisión de arquitectura fue no construir un servicio aparte. Las señales que el loop necesita ya están en nuestro Postgres (Neon): leads del pipeline, telemetría de clientes en producción, milestones y reconciliación de Stripe, referrals de afiliados. Un servicio externo solo agregaría sincronización, latencia y un lugar más para romperse. El loop vive en la misma app Next.js, lee la misma base de datos y sube en el mismo deploy.
Collectors tipados: señal cruda antes de la interpretación
Cada fuente tiene un collector que devuelve un SignalBatch tipado, el dato bruto antes de cualquier juicio. Esa frontera importa. El collector no decide qué es relevante, solo entrega el hecho (cuántos leads entraron, cuál es la caja, cuántos referrals). La etapa siguiente interpreta. Separar recolección de interpretación hace cada parte testeable por sí sola y permite cambiar la fuente sin tocar la síntesis.
La parte difícil: hacer medible la decisión
El corazón del loop no es generar una recomendación, es hacer la decisión medible automáticamente. Cada decisión lleva una métrica objetivo estructurada: no un texto suelto como "mejorar la conversión", sino lo suficiente para ser consultada por máquina después (la fuente, la query, la ventana de medición, la dirección de éxito y la baseline registrada en el momento en que la decisión fue aceptada). Sin la baseline capturada en ese momento, "¿funcionó?" se vuelve una discusión. Con ella, la revisión semanal compara el valor medido contra el punto de partida y responde con un número.
El loop cierra en medición, no en una sugerencia
Aquí entra la disciplina de vocabulario que se volvió regla de diseño. Una recomendación propuesta nunca se llama decisión. El brief diario propone de 1 a 3 recomendaciones (estado propuesto); solo se vuelven decisión cuando el founder acepta. Y una decisión solo está cerrada cuando la revisión semanal mide el resultado y graba un Outcome Score (-1, 0 o 1). Forzar esas fronteras en el schema evita el error más común de tablero de gestión: confundir intención con compromiso, y compromiso con resultado.
La IA propone, el founder decide
Es el mismo principio de nuestros proyectos de IA de cara al cliente: el modelo no actúa solo donde la acción es difícil de revertir. Claude sintetiza el brief y propone; aceptar una recomendación es un clic humano, en un endpoint de acción dedicado. El loop no decide por el founder, garantiza que toda decisión tomada tenga hipótesis, métrica y fecha de revisión. La ganancia no es quitar al humano, es no dejar ninguna apuesta sin marcador.
Qué haríamos diferente
Habríamos capturado la baseline desde la primera decisión. En las primeras versiones la métrica objetivo era texto libre, y medir después exigía reconstruir el punto de partida de memoria (impreciso y discutible). Estructurar la métrica objetivo con baseline en el momento de la aceptación fue lo que transformó el loop de un diario bonito en un ciclo que aprende.
El loop que usamos es el que vendemos
Company OS es una aplicación interna (Track 3) corriendo en producción para nosotros mismos. La arquitectura, las decisiones y lo que entrega día a día están en el case completo. Si tu operación decide a oscuras y quieres un loop que cierre en medición, cuéntanos tu contexto.