La IA puede cambiar. El trabajo no debería empezar de cero.
Cambiar de IA es fácil. Reconstruir el trabajo no lo es. Epismo mantiene juntos el resultado, el contexto y la revisión para que la siguiente persona o modelo pueda continuar. Cuando los equipos encuentran un patrón repetible, pueden convertirlo en un Playbook y usarlo para iniciar el siguiente Caso.
Introducción
Copiaste el borrador, pero no la decisión que había detrás.
Este es un traspaso habitual en el trabajo asistido por IA. Un modelo redacta el primer borrador de un anuncio de lanzamiento. El equipo ya ha acordado no decir que el producto funciona con todas las IA. Esa afirmación es más amplia que las integraciones que el equipo admite actualmente. Alguien pega el borrador en un segundo modelo para mejorar la redacción. El segundo modelo hace exactamente lo que se le pide y devuelve una frase más contundente:
«Funciona con todas las IA que usa tu equipo».
El segundo modelo no fue descuidado. No recibió la restricción. Recibió un párrafo y una instrucción para mejorarlo. El borrador se movió. El trabajo alrededor del borrador se quedó en el primer chat, en un hilo o en la cabeza de alguien.
Ya sabes qué ocurre durante los siguientes diez minutos. Se abre un nuevo chat. Alguien explica un trabajo que ya existe. Alguien busca una frase en un hilo antiguo. Alguien pregunta cuál es la versión actual. El modelo es rápido. El briefing no.
Llamamos a esa reconstrucción repetida el impuesto de re-briefing. Se convierte en el resultado habitual cuando el trabajo no tiene un lugar compartido donde vivir mientras cambia la persona, el modelo o la sesión.
La IA puede cambiar. El trabajo no debería tener que empezar de cero.
📖 TOC
- Ser portable no es lo mismo que ser continuable
- La revisión también debe viajar con el trabajo
- El siguiente modelo no necesita un prompt más largo
- Caso primero. Playbook después.
- El trabajo debe sobrevivir al cambio
Ser portable no es lo mismo que ser continuable
La solución evidente es guardar el borrador en un lugar que ambas herramientas puedan ver. Eso ayuda, pero no es suficiente.
Este problema suele tratarse como un problema de prompts: pegar una transcripción más larga, exportar el hilo o escribir un mejor briefing para el siguiente modelo. Pero un texto más largo no responde de forma fiable a las preguntas importantes. ¿Cuál es la versión actual? ¿Qué decisión sigue vigente? ¿Qué se ha revisado ya? ¿Qué debe suceder después?
Portable significa que un borrador puede abrirse en otra herramienta. Continuable significa que el siguiente participante puede entender qué es el trabajo, por qué tiene este aspecto, qué se ha cuestionado ya y qué debe suceder después.
Un resultado guardado sin la decisión que lo sustenta puede “mejorarse” hasta convertirse en una afirmación exagerada. Una revisión que vive en otro chat se convierte en un segundo artefacto que hay que perseguir. Un siguiente paso que vive en la memoria de una sola persona desaparece cuando otra persona u otro modelo retoma el trabajo.
Esta necesidad suele formularse como memoria: conservar la última conversación. Pero eso todavía deja el rechazo en un lugar distinto al borrador. El siguiente modelo puede pulir una afirmación que un revisor ya detectó, porque esa observación no viajó con el trabajo.
La revisión también debe viajar con el trabajo
El trabajo asistido por IA necesita un ciclo, no solo un archivo:
resultado → revisión → corrección → decisión → siguiente paso
Los equipos de software ya dependen de este patrón. Un cambio se puede revisar porque el diff, el historial y los comentarios de revisión permanecen en el mismo lugar. Nadie envía un parche por correo y espera encontrar los comentarios después. El revisor ve el trabajo. El autor vuelve al trabajo y a los comentarios juntos.
En un flujo de trabajo asistido por IA, el siguiente participante puede ser otra persona u otro modelo. Una IA puede crear un resultado. Una revisión nueva puede señalar una afirmación sin respaldo, una suposición débil o una pregunta abierta. Otra IA o una persona puede corregirlo. Una persona puede tomar la decisión final.
Si la revisión se separa del resultado, el ciclo se rompe y el equipo vuelve a pagar el impuesto.
Ese es el problema adicional. El trabajo debe poder moverse entre herramientas, pero también debe seguir siendo revisable y continuable. El resultado guardado, el contexto que lo sustenta y la revisión deben permanecer juntos para que el siguiente participante pueda actuar a partir de los tres.
El siguiente modelo no necesita un prompt más largo
En Epismo, un Caso es el lugar compartido para un trabajo real. No es otro chatbot ni un contenedor de todas las sesiones. El Caso conserva lo que el siguiente participante tendría que reconstruir de otro modo: el resultado actual, las decisiones y el contexto que lo sustentan, las preguntas abiertas, la revisión y el siguiente paso. Las conversaciones sin procesar, las llamadas a herramientas, los reintentos y los archivos locales pueden quedarse en el entorno de ejecución que los produjo.
Volvamos al anuncio de lanzamiento.
El Caso ya contiene el borrador y la decisión de describir solo las integraciones compatibles. Cuando Auto Review está activado, Epismo revisa el resultado guardado y escribe una observación en el mismo Caso: esta afirmación es más amplia que las integraciones registradas aquí. No reescribe el original en silencio. El borrador permanece. La revisión queda a su lado.
Una persona o una IA conectada que tenga acceso al Caso puede continuar desde los tres elementos: el borrador, la restricción y la observación. Corrige la afirmación y guarda el resultado mejorado para quien continúe después.
El modelo no se volvió más inteligente de repente. Recibió el trabajo y la revisión que lo rodea.
Una transcripción es una conversación. Un Caso es el trabajo. Pegar no es retomar.
Caso primero. Playbook después.
Cuando este ciclo se repite, aparecen patrones. Es posible que el texto de lanzamiento siempre necesite una revisión de afirmaciones antes de publicarse. Un informe de investigación puede necesitar fuentes antes de que alguien escriba una recomendación. Puede que sea necesario registrar una decisión antes de empezar a redactar.
Esas lecciones pueden convertirse en un Playbook: una forma reutilizable de abordar un tipo de trabajo. El Caso permite continuar el trabajo de hoy. El Playbook ayuda al equipo a hacer mejor el próximo trabajo similar.
El ciclo no termina cuando el equipo crea un Playbook. Cuando comienza un trabajo parecido, el equipo puede iniciar un nuevo Caso a partir de ese Playbook. El Playbook da al nuevo Caso un método compartido con el que empezar, mientras que el nuevo Caso conserva los resultados, decisiones, revisiones y siguientes pasos específicos que surgen en esa ejecución.
El ciclo práctico es el siguiente:
Caso → aprendizaje del trabajo real → Playbook → nuevo Caso
El objetivo no es definir un método antes de que comience cada trabajo. El método útil suele quedar claro después de que el equipo ha visto dónde se ralentizó el trabajo real, qué detectó una revisión y qué decisión fue importante de forma repetida.
No empieces por el método. Empieza por el trabajo.
Caso primero. Playbook después.
El trabajo debe sobrevivir al cambio
Los modelos seguirán cambiando. Los equipos seguirán combinándolos. Ese es el sentido de tener más de uno.
Cambiar de herramienta no debería obligar a un equipo a elegir entre trasladar el contexto a mano o perderlo. La pregunta importante no es qué herramienta posee la conversación. Es si el trabajo sigue siendo comprensible, revisable y continuable cuando cambia la persona o la IA.
Cuando el resultado, el contexto y la revisión permanecen juntos, un equipo puede elegir la siguiente herramienta por sus fortalezas, en lugar de quedarse en una sola porque mover el trabajo resulta demasiado costoso.
La IA puede cambiar. El Caso permanece.
Cambia de IA. Conserva el trabajo.