Imagina el pedido más simple del mundo: “cambia el color del botón de comprar”. Llega un martes, por mensaje. El jueves, alguien pregunta por qué cambió el botón. El viernes, otra persona quiere el color anterior, porque el cliente había dicho en una reunión que el verde era de la marca.
Nadie se equivocó. El pedido simplemente no vivía en ningún lugar.
Un núcleo, no otra herramienta
Kore es el sistema que construimos para operar Kabran. No es un gestor de tareas con otro nombre: es el lugar donde viven, juntos, el trabajo, el conocimiento, los clientes y el código.
- Trabajo: todo pedido se convierte en una issue, con lo que tiene que ser verdad para que esté lista.
- Conocimiento: toda decisión se convierte en un documento, con el contexto y lo que se descartó.
- Clientes: propuestas, reuniones y respuestas quedan vinculadas al proyecto al que pertenecen.
- Código: cada repositorio sabe de qué producto es y qué issue cierra cada cambio.
El valor no está en cada parte. Está en los vínculos entre ellas.
Por qué la IA lo necesita más que nosotros
Un agente de IA empieza cada tarea sin ningún recuerdo de la anterior. Es una limitación — y, bien aprovechada, una virtud. No arrastra vicios, no “cree que recuerda”, no confunde el proyecto A con el proyecto B.
Pero solo funciona si todo lo que necesita saber está escrito en algún lugar que pueda leer. Cuando un agente toma una issue en Kore, recibe el pedido, los criterios de aceptación, las decisiones vinculadas y el repositorio correcto. No necesita adivinar. No necesita preguntar lo que ya se respondió.
Lo que no está escrito no existe — ni para la persona que llega mañana, ni para el agente que empieza ahora.
El camino de un pedido
En la práctica, un pedido recorre siempre el mismo camino:
- llega por cualquier canal y se registra como issue, con su criterio de listo;
- si implica una elección de negocio, la toma una persona y se registra como decisión;
- la issue se despacha a un agente, que trabaja dentro de los estándares de la casa;
- el resultado pasa por una revisión independiente antes de entrar;
- la issue se cierra cuando el efecto existe, no cuando se escribió el código.
Parece burocracia. Es lo contrario: es lo que permite que pasen muchas cosas al mismo tiempo sin que nadie tenga que sostenerlo todo en la cabeza.
Lo que gana el cliente
Cuando preguntas “¿por qué esto está así?”, la respuesta existe, con fecha y motivo. Cuando quieres saber en qué punto está tu proyecto, no depende de que alguien se acuerde de mandar una actualización. Y cuando el equipo cambia — o cambia el agente, o cambia el modelo —, tu proyecto no pierde la memoria con ellos.
Cambiar el color del botón sigue siendo un pedido simple. Solo que ahora tiene dirección.