Acabo de crear un OKR sin abrir Tability.
Esto es lo que pasó. Estamos en pleno proceso de migrar toda nuestra interfaz a shadcn/ui (esto va a quedar genial cuando esté terminado). La especificación vive en Confluence: modales, paneles, páginas, componentes complejos, unas 240 cosas por migrar, todas registradas como casillas de verificación. Útil para el equipo que hace el trabajo. Inútil para seguir el progreso a nivel de OKR.
Así que le pedí a Claude que leyera la página de Confluence, resumiera lo que faltaba y añadiera un nuevo KR a nuestro plan del Q2 para seguir el progreso de la migración.
Y lo hizo. En menos de un minuto.
Esta no es una historia de «vaya, qué rápida es la IA». Es el comienzo de algo más interesante: la forma en que realmente se gestionan los OKR está a punto de cambiar.
Las 3 tareas que acaban de reducirse a 1 prompt
Configurar un objetivo como este solía requerir tres tareas distintas, normalmente repartidas entre tres personas diferentes.
Alguien lee la especificación. Esa persona revisa la página de Confluence, cuenta los componentes, identifica qué está hecho y qué no, y lo convierte en un número.
Alguien redacta el OKR. Esa persona traduce el trabajo en un resultado medible, elige una meta, asigna un responsable, escribe la descripción. Si alguna vez te has quedado mirando la página en blanco tratando de formular un KR, ya sabes cuánto puede tardar esto. (Escribimos una guía completa para lograrlo en menos de 30 minutos, y sigue siendo la parte más difícil del ciclo para la mayoría de los equipos.)
Alguien lo mantiene actualizado. Cada semana, esa persona revisa la especificación, vuelve a contar, escribe un check-in, publica una actualización de estado en algún lugar. Muchas veces, aquí es donde los despliegues de OKR mueren en silencio.
Tres tareas. Tres cambios de contexto. Tres lugares donde el impulso se apaga.
Lo que hice en su lugar: un solo prompt. Claude leyó la página de Confluence a través de Rovo, obtuvo la estructura de nuestro plan existente desde el MCP de Tability, propuso el KR y lo creó una vez que confirmé los detalles. La especificación de Confluence sigue siendo la fuente de verdad para el equipo. El KR de Tability es la señal consolidada para la dirección. Ambos permanecen sincronizados sin que nadie tenga que copiar y pegar.
Por qué esto importa más de lo que parece
La fricción es la enemiga de todo despliegue de OKR.
La gente no actualiza sus objetivos si para ello tiene que rebuscar en Jira, Linear, Notion, Sentry, Amplitude y tres hilos de Slack para averiguar qué pasó realmente esta semana. Para cuando has reunido los datos, ya has perdido una hora y las ganas de escribir un check-in con sentido.
Así que escribes «va bien» y sigues adelante. O te saltas el check-in por completo. Y seis semanas después tus OKR se sienten desconectados del trabajo real, porque nadie ha estado contando esa conexión.
Los OKR agénticos le dan la vuelta a esto. El agente se encarga de recopilar. Tú te encargas de pensar.
En nuestro caso, la fuente de datos es Confluence, pero el mismo patrón funciona para cualquier cosa. Sentry para el número de errores. Amplitude para las métricas de uso. Stripe para los ingresos. GitHub para los PR entregados. Al KR no le importa de dónde viene el número. Solo necesita que ese número aparezca de forma fiable cada semana.
El siguiente paso: un compañero de equipo, no una herramienta
Crear el KR fue el primer paso. El segundo paso es hacer que se mantenga solo.
Para esto vamos a poner en marcha un agente compañero de Tability: un compañero de equipo con IA que vive dentro del espacio de trabajo, es responsable del KR y funciona según un calendario a través de Claude Cowork.
Cada lunes por la mañana, antes del standup, va a:
- Leer la página de Confluence
- Contar los componentes completados
- Comparar con la semana anterior
- Publicar un check-in con el nuevo número y una breve nota sobre lo que se entregó
Sin humanos en el proceso de recopilación de datos ni en el check-in. Seguiremos revisando el progreso en nuestra reunión semanal y añadiendo contexto si las cosas se salen de rumbo, pero ya no necesitamos interrumpir el flujo de trabajo de nadie solo para seguir el progreso de esta migración.
Esto es lo que marca la diferencia entre «la IA en el flujo de trabajo» y «la IA haciendo el flujo de trabajo». Hoy en día, la mayoría de las funciones de IA son autocompletado para humanos. Los OKR agénticos consisten en que los humanos revisan lo que el agente ya hizo. Llevamos tiempo construyendo hacia este patrón: nuestro agente de prevención de churn funciona del mismo modo, y tenemos una beta privada en marcha para clientes que quieren probar este enfoque.
Hacia dónde va esto
Dentro de un año, creo que la mayoría de los equipos que gestionan bien sus OKR tendrán al menos un agente por objetivo. No un chatbot. Más bien un compañero de equipo con una descripción de puesto, un calendario y acceso a los sistemas donde ocurre el trabajo. El responsable humano marca la dirección y toma las decisiones. El agente mantiene el ritmo.
Estamos construyendo Tability para ese mundo. El MCP es la forma en que Claude, o cualquier modelo, habla con tus objetivos. Los agentes son la forma en que esos objetivos se mantienen vivos entre check-ins.
Si quieres probarlo tú mismo, el MCP de Tability ya está disponible y funciona con Claude hoy mismo. Conéctalo, apúntalo a tu plan y pídele que te ayude a escribir tu próximo KR. Notarás la diferencia en unos cinco minutos.
Y si te estás planteando los OKR agénticos más en serio, me encantaría hablar contigo. Escríbeme a [email protected] o encuéntrame en LinkedIn.
.jpg)
