Una capa compartida para el trabajo entre personas y agentes de IA
Los agentes de IA son cada vez mejores en la ejecución, pero el trabajo real suele pasar entre personas, agentes y sesiones. Epismo ofrece a los equipos una capa compartida para reutilizar formas de trabajar y preservar los casos reales que necesitan sobrevivir a esos traspasos.
Introducción
Los agentes de IA ya pueden gestionar trabajos cada vez más complejos. Pueden usar Skills, llamar a herramientas mediante MCP, ejecutar grafos, trabajar con subagentes e iterar a través de bucles sofisticados. Pero a medida que mejora la ejecución, otro problema se vuelve más evidente: ¿dónde vive el trabajo en sí cuando pasa entre personas y agentes?
Imagina que una persona inicia una tarea con Claude Code. Otra revisa el resultado y cambia una suposición importante. Al día siguiente, alguien más continúa el mismo trabajo con Codex. Cada participante puede tener un agente capaz y una buena configuración, pero el estado del trabajo ahora está disperso entre sesiones, chats, documentos y la memoria individual.
La siguiente persona necesita algo más que el último resultado. Necesita saber qué se intentó ya, qué se decidió, por qué cambió la dirección, qué elementos del trabajo intermedio son importantes y qué queda por hacer.
Epismo está construido alrededor de dos objetos compartidos para resolver este problema: Playbooks, que preservan formas de trabajar reutilizables, y Casos, que preservan el trabajo real a medida que pasa entre personas y agentes de IA.
📖 TOC
- Los Playbooks preservan la forma de trabajar
- Los Casos preservan el trabajo real
- La colaboración ocurre alrededor del Caso
- Materializa solo lo que necesita perdurar
- Los Casos mejoran los Playbooks
- Una capa compartida por encima de la ejecución de agentes
- Playbook y Caso son el centro
Los Playbooks preservan la forma de trabajar
Las personas que obtienen buenos resultados de forma consistente con la IA suelen tener algo más que buenos prompts. Desarrollan una forma de trabajar: cómo descomponer el problema, qué contexto proporcionar, qué herramientas o Skills utilizar, qué verificar, dónde importa el criterio humano y cómo debería ser un resultado útil.
Un Playbook hace que ese método sea reutilizable.
Puede describir pasos recomendados, instrucciones, resultados esperados y recursos útiles como Skills, grafos, servidores MCP, documentos u otros entornos para agentes. Pero un Playbook no pretende sustituir esos sistemas ni ser una versión más expresiva de una Skill.
Una Skill o un grafo puede contener ya un método de ejecución completo. La diferencia es que estos suelen pertenecer a un agente o entorno de ejecución. Un Playbook representa la forma compartida en que un equipo aborda un tipo de trabajo, independientemente del entorno que termine ejecutándolo.
Esta separación es importante porque la capa de ejecución cambia rápidamente. Hoy un equipo puede usar Claude Code, Codex, OpenClaw o un agente interno. Dentro de seis meses, las herramientas pueden ser diferentes. El método reutilizable no debería desaparecer con ellas.
Los Casos preservan el trabajo real
Un método reutilizable y un trabajo real concreto son cosas diferentes.
Un Playbook puede describir cómo revisar una arquitectura de software, investigar un incidente, realizar una investigación o evaluar una idea de producto. Un Caso es una instancia real de ese trabajo.
El Caso proporciona al trabajo una identidad fuera de cualquier sesión individual de un agente. Puede sobrevivir cuando cambia la persona, cuando cambia el agente o cuando el trabajo se pausa y se retoma más adelante.
A medida que el Caso evoluciona, las personas y los agentes pueden adjuntar la información que merece la pena conservar: resultados intermedios, decisiones, comentarios de revisión, archivos, contexto para el traspaso o resultados finales. A esto lo llamamos Registros.
El objetivo no es reflejar todo lo que hace internamente un agente. Un entorno de ejecución puede realizar decenas de llamadas a herramientas, reintentos o transiciones entre grafos que nadie más necesita ver. Lo importante es preservar la información que, de otro modo, otro participante tendría que reconstruir.
Esta es la distinción clave entre el estado de ejecución y el estado del trabajo. El estado de ejecución ayuda a un agente a ejecutar. El estado del Caso ayuda a un equipo a comprender y continuar el trabajo.
La colaboración ocurre alrededor del Caso
El trabajo asistido por IA suele describirse como una persona delegando en un agente. En las organizaciones reales, el trabajo se mueve.
Una persona puede iniciar un análisis con un agente. Un compañero lo revisa. Esa revisión cambia la dirección. Otra persona se hace cargo utilizando un agente diferente. Puede que un especialista tenga que responder a una pregunta antes de que el trabajo pueda continuar.
El recorrido ya no es simplemente de persona a persona o de persona a agente. Puede parecerse más a esto:
persona → agente → revisor → otra persona → otro agente
En ese entorno, cambiar la persona asignada no es suficiente. Un traspaso útil también incluye el resultado actual, las decisiones relevantes, el trabajo intermedio importante y el contexto que necesita el siguiente participante.
Un Caso proporciona el espacio compartido para mantener esa continuidad.
Cuando es necesaria una coordinación explícita, un Caso también puede tener una Tarea. Un revisor puede tener que aprobar un resultado, o quizá otra persona deba investigar un problema específico. Pero las Tareas no son el centro de Epismo. Solo existen cuando el Caso necesita una responsabilidad, revisión o traspaso explícitos.
Si un solo agente puede completar todo por sí mismo, puede que no haya ninguna Tarea.
Materializa solo lo que necesita perdurar
Una posible solución para mantener la continuidad sería registrar todo lo que hace cada agente. No creemos que sea necesario.
Si Claude Code puede seguir un Playbook, completar el trabajo y devolver un buen resultado, Epismo no necesita almacenar toda su transcripción, cada llamada a herramientas ni cada estado interno del grafo.
En su lugar, Epismo sigue un principio de materialización bajo demanda: la información se convierte en estado compartido cuando adquiere valor fuera del entorno de ejecución que la produjo.
¿Un resultado intermedio necesita revisión humana? Presérvalo.
¿Una decisión cambia la dirección del trabajo? Presérvala.
¿Otro agente necesita contexto del participante anterior? Preserva un resumen del traspaso o los Registros relevantes.
¿Se produjo un reintento interno que nadie más necesita conocer? Déjalo dentro del entorno de ejecución.
Esto mantiene a Epismo centrado en la colaboración, en lugar de convertirlo en otro motor de ejecución o almacén de telemetría.
Los Casos mejoran los Playbooks
La relación entre Playbooks y Casos también crea un ciclo de retroalimentación.
Un Playbook describe la mejor forma conocida en ese momento de abordar un tipo de trabajo, pero los Casos reales muestran dónde puede mejorar ese método. Un equipo puede descubrir que una pregunta importante debería hacerse antes, que un resultado esperado no está claro o que la revisión humana es necesaria en un punto diferente.
Esos aprendizajes pueden convertirse en Sugerencias para mejorar el Playbook.
El ciclo es sencillo:
Playbook → Caso → aprendizaje del trabajo real → Playbook mejorado
Así es como una forma individual de trabajar puede convertirse gradualmente en una capacidad de equipo. Una persona encuentra un método mejor, otras lo reutilizan, el trabajo real revela sus puntos débiles y el método mejora.
Cuando sea apropiado, los Playbooks también pueden compartirse más allá de un solo equipo. Las formas útiles de trabajar no deberían quedar enterradas en chats privados, configuraciones locales o hábitos individuales.
Una capa compartida por encima de la ejecución de agentes
Se está haciendo mucho trabajo interesante en torno a los entornos para agentes, la ingeniería de grafos y la ingeniería de bucles. Estos enfoques hacen que los agentes individuales sean mejores ejecutando tareas complejas: mejoran el uso de herramientas, la iteración, la gestión del contexto, la recuperación y el control.
Epismo se centra en la capa que adquiere importancia cuando el trabajo sobrevive a un único entorno, un único grafo, un único bucle o una única sesión.
Un grafo puede gestionar la ejecución dentro de un sistema de agentes. Una Skill puede encapsular una capacidad útil. Un bucle puede ayudar a un agente a alcanzar un mejor resultado.
Pero cuando una persona cambia la dirección, otro agente necesita continuar o el trabajo sigue existiendo hasta el día siguiente, el equipo necesita un lugar donde pueda vivir el trabajo en sí.
Por eso Epismo no intenta sustituir el entorno de ejecución del agente. La ejecución debe permanecer en manos de los agentes y herramientas que las personas ya utilizan. Epismo proporciona la capa compartida a su alrededor.
El entorno de ejecución puede cambiar mientras el Caso sigue siendo el mismo.
Playbook y Caso son el centro
La forma más sencilla de entender Epismo es a través de estos dos conceptos.
Playbook es la forma reutilizable en que se realiza un tipo de trabajo.
Caso es un trabajo real concreto que personas y agentes continúan juntos.
Los Registros preservan las partes de un Caso que merece la pena conservar. Las Tareas aparecen cuando se necesita coordinación explícita. Las Sugerencias convierten las lecciones de Casos reales en mejores Playbooks.
Todo lo demás existe para apoyar esos dos objetos.
A medida que la IA se convierta en un participante habitual del trabajo en equipo, creemos que esta distinción será cada vez más importante. Los equipos más sólidos no solo tendrán agentes capaces. También podrán reutilizar buenas formas de trabajar y continuar el trabajo real sin tener que reconstruir su contexto cada vez que cambie la responsabilidad.
Los Playbooks preservan el método. Los Casos preservan el trabajo.
Esa es la capa compartida que estamos construyendo con Epismo.