Haz la revisión semanal con un agente de IA en 30 minutos: el agente redacta, tú corriges, el equipo lee
Un ciclo de viernes: un agente de IA redacta el estado semanal a partir de incidencias cerradas, elementos estancados y objetivos; una persona lo corrige en 30 minutos.
En esta página
Una revisión semanal con un agente de IA funciona así: el viernes el agente recoge qué se cerró, qué se quedó estancado y cómo avanzó cada objetivo, redacta un estado en una plantilla fija y tú dedicas treinta minutos a corregirlo antes de que lo lea el equipo. El agente hace la recopilación, que es la parte que la gente se salta; tú pones el criterio, que es la parte en la que el agente se equivoca. El resultado es una actualización de estado puntual, concreta y aun así honesta.
Este es el ciclo que hacemos en Atrix cada viernes a las 15:00. Abajo están la plantilla, los pasos, qué lee el agente, en qué se equivoca de forma fiable y cómo hacerlo tanto si tus herramientas tienen agente como si no.
Por qué la pasada de corrección humana es lo esencial
Los informes de estado automáticos existen desde hace años. La mayoría se ignoran porque son exactos y vacíos: "14 incidencias cerradas, 3 abiertas, velocidad estable". Una actualización de estado es útil cuando dice qué significan esos números para el plan, y eso exige a alguien que conozca el plan.
La idea de una pasada de corrección corta y fija, en lugar de una redacción desde cero, lleva tiempo circulando en comunidades de fundadores como Indie Hackers: deja que las herramientas reúnan los hechos y dedica un bloque acotado de tiempo (treinta minutos es la cifra habitual) a convertirlos en un mensaje. Lo tratamos como una práctica comunitaria sensata, no como un método probado; lo que sí podemos decir es que nuestras actualizaciones pasaron de "a veces, tarde, vagas" a "cada viernes, concretas" cuando la recopilación dejó de ser manual.
El borrador es del agente. El criterio es tuyo. No dejes que esa división se difumine.
La plantilla del estado semanal
La plantilla es fija para que el agente la rellene igual cada semana y los lectores sepan dónde mirar:
| Sección | Qué contiene | Quién la aporta |
|---|---|---|
| Titular | Una frase: en plazo, en riesgo o retrasado, y por qué | Persona |
| Entregado | Incidencias cerradas esta semana, agrupadas por producto, con enlaces | Agente |
| Retrasado | Incidencias con vencimiento esta semana que no se cerraron, con la nueva fecha | El agente redacta, la persona confirma la fecha |
| Estancado | Incidencias sin tocar desde hace 14+ días que siguen abiertas | Agente |
| Objetivos | Los resultados clave de cada objetivo, con el registro de esta semana | El agente redacta desde los registros, la persona añade la frase |
| Próxima semana | Las tres cosas que más importan | Persona |
| Peticiones | Decisiones o ayuda que se necesitan de alguien concreto | Persona |
Tres secciones humanas, cuatro del agente. Si el agente acaba escribiendo "Próxima semana" y "Peticiones", la revisión ha dejado de ser una revisión.
Paso a paso: el ciclo del viernes
- Bloquea 30 minutos el viernes por la tarde, cada semana, en el calendario. El bloque es el ritual. Sin él, la revisión ocurre el lunes por la mañana, demasiado tarde para cambiar la semana.
- Dale al agente un brief fijo. Insumos: incidencias cerradas en los últimos 7 días, incidencias con vencimiento en los últimos 7 días aún abiertas, incidencias abiertas sin tocar en 14 días, los objetivos y sus últimos registros. Salida: la plantilla de arriba con las cuatro secciones del agente rellenas y las humanas como marcadores. Restricciones: solo lectura; sin cambios de estado; sin razones inventadas para los retrasos.
- Lee primero la lista de Entregado y corrige la agrupación. El agente agrupa por producto; a veces la agrupación interesante es por cliente o por tema. Arréglalo.
- Confirma cada fecha retrasada. El agente informa de la nueva fecha de vencimiento de la incidencia. Si nadie la fijó, lo dice, y tú la fijas ahora o decides que la incidencia no importa.
- Decide qué hacer con cada elemento estancado. Cerrar, reasignar o dejar con un motivo. Los elementos estancados que sobreviven a tres revisiones no están estancados, no son trabajo; bórralos.
- Escribe el titular al final. Tras leerlo todo, una frase. Si no puedes escribirla, no sabes si la semana fue buena, y ese es el hallazgo.
- Añade Próxima semana y Peticiones a mano. Tres puntos, no siete. Las peticiones nombran a una persona.
- Publícalo donde el equipo lee. Una publicación en el feed o un mensaje fijado, no un documento que nadie abre.
Treinta minutos bastan una vez que el brief es estable. Las dos primeras semanas llevan más tiempo porque estás arreglando el brief, no el informe.
Qué lee el agente y en qué se equivoca
El agente necesita acceso de lectura a incidencias, objetivos y el feed del equipo; nada más. En Atrix, a través del servidor MCP o del chat del agente, eso son los alcances work.read, goals.read y feed.read, y las herramientas que usa son work_list_issues con filtro de fecha, project_status por producto, goals_list y pulse_report_latest, que ya resume la actividad de la semana por producto. Publicar la actualización final usa feed_post_update, que notifica a los teléfonos de la gente, así que mantenemos ese alcance fuera del agente y publicamos a mano tras la pasada de corrección.
Fallos fiables que vemos cada pocas semanas:
- Razones de los retrasos. El agente infiere una razón de los comentarios ("bloqueado por diseño") cuando la razón real era que la persona asignada estaba de permiso. Nunca le dejes escribir el porqué; escribe el qué.
- Progreso de objetivos leído como lineal. Un resultado clave al 40% con dos semanas por delante no está "en plazo" porque 40 sea más que 0. La frase del registro es tuya.
- Contar la misma incidencia dos veces cuando se cerró, se reabrió y se volvió a cerrar. Menor, pero infla "Entregado".
- Exceso de cortesía. Si se le deja solo, el borrador dice "buen progreso en general". Borra esas frases; el titular es donde va el criterio, y a veces debería decir "retrasado".
Hacerlo sin agente
Si tus herramientas no tienen agente, el ciclo funciona igual con filtros guardados. En cualquier gestor, guarda cuatro vistas: cerradas en los últimos 7 días, con vencimiento en los últimos 7 días y abiertas, sin tocar en 14 días, y objetivos. Ábrelas en orden el viernes, pega en la plantilla y haz la misma pasada de corrección. Lleva cuarenta y cinco minutos en vez de treinta, y la recopilación es la parte que tendrás la tentación de saltarte, lo que es el argumento para automatizarla.
Los insights de Linear, los paneles de Jira y las bases de datos de Notion con filtros de fecha sirven como las cuatro vistas. La diferencia que marca un agente es el primer borrador de la prosa de Entregado y Retrasado, que ahorra quizá diez minutos y, sobre todo, elimina la página en blanco.
Un viernes real
La revisión de la semana pasada, ligeramente editada. Entregado: nueve incidencias entre Calendario y Páginas, incluidos los correos de recordatorio de reservas. Retrasado: dos, ambas de Páginas, ambas con nueva fecha el miércoles siguiente tras hablar con la persona asignada. Estancado: cuatro, de las cuales dos se cerraron por dejar de ser relevantes y una se reasignó. Objetivos: el resultado clave "activación autoservicio" pasó del 31% al 38%; la frase del registro fue "avanza, pero la palanca mayor (correos de prueba) sale la semana que viene, júzgalo entonces". Titular: "En plazo para el ciclo; un objetivo se decidirá con los correos de prueba de la próxima semana". Próxima semana: correos de prueba, build de Android a testers, textos de la página de precios. Peticiones: una decisión sobre si la beta de Android sale antes del cambio de precios.
Tiempo total incluida la publicación: 28 minutos. El borrador del agente había agrupado las nueve incidencias entregadas por producto, lo que era correcto, y había escrito "bloqueado por feedback de diseño" en una incidencia retrasada, lo que era incorrecto y se eliminó.
Preguntas frecuentes
¿Qué debe incluir una actualización de estado semanal?
Un titular de una línea (en plazo, en riesgo, retrasado), qué se entregó, qué se retrasó con nuevas fechas, qué está estancado, cómo avanzó cada objetivo, las tres prioridades de la próxima semana y peticiones concretas con una persona nombrada. Que quepa en una pantalla.
¿Puede un agente de IA escribir el estado semanal por su cuenta?
Puede escribir las secciones factuales: entregado, retrasado, estancado y las cifras de los objetivos. No debería escribir el titular, las razones de los retrasos, las prioridades de la próxima semana ni las peticiones. Eso necesita a alguien que conozca el plan, y esa es la pasada de corrección de treinta minutos.
¿Cuánto debería durar una revisión semanal?
Treinta minutos una vez que el brief y la plantilla son estables. Las dos o tres primeras semanas llevan más porque estás arreglando el brief. Si suele pasar de una hora, la plantilla es demasiado larga o el gestor está desactualizado.
¿A qué datos necesita acceso el agente?
Lectura de incidencias (fechas de cierre, vencimiento y último cambio), objetivos y sus registros, y el feed del equipo. No necesita clientes, contratación, nóminas ni capacidad de cambiar nada. Concede solo lecturas; publica tú la actualización final.
¿Debe publicarse la revisión semanal para todo el equipo?
Sí, donde el equipo ya lee: una publicación en el feed o un mensaje fijado en el chat. Un documento que nadie abre es un diario privado. Que quepa en una pantalla para que se lea en el móvil.
¿En qué se diferencia de una retrospectiva de sprint?
Una revisión semanal trata del estado y de las prioridades de la próxima semana; dura treinta minutos y produce un mensaje. Una retrospectiva trata de cómo trabajó el equipo durante un ciclo; dura una hora y produce cambios en el proceso. Haz las dos; no las mezcles.
Siguiente paso
Configura las cuatro vistas (cerradas, retrasadas, estancadas, objetivos) en el gestor que uses y bloquea el viernes a las 15:00. Si tu trabajo vive en Atrix, la gestión de proyectos ya tiene ciclos, etiquetas y registros de objetivos de los que el agente lee, y la página para fundadores muestra cómo un equipo pequeño ejecuta este ciclo de principio a fin.