A Shared Layer for Work Across People and AI Agents
AI agents are getting better at execution, but real work often moves across people, agents, and sessions. Epismo gives teams a shared layer for reusable ways of working and the actual cases that need to survive those handoffs.
Introduction
AI agents can now handle increasingly complex work. They can use Skills, call tools through MCP, execute graphs, work with subagents, and iterate through sophisticated loops. But as execution gets better, another problem becomes more visible: where does the work itself live when it moves between people and agents?
Imagine one person starts a task with Claude Code. Another person reviews the result and changes an important assumption. The next day, someone else continues the same work with Codex. Each participant may have a capable agent and a good setup, but the state of the job is now scattered across sessions, chats, documents, and individual memory.
The next person needs more than the latest output. They need to know what was already tried, what was decided, why the direction changed, what matters from the intermediate work, and what still needs to happen.
Epismo is built around two shared objects for this problem: Playbooks, which preserve reusable ways of working, and Cases, which preserve the actual work as it moves across people and AI agents.
📖 TOC
- Playbooks Preserve the Way of Working
- Cases Preserve the Actual Work
- Collaboration Happens Around the Case
- Materialize Only What Needs to Survive
- Cases Improve Playbooks
- A Shared Layer Above Agent Execution
- Playbook and Case Are the Center
Playbooks Preserve the Way of Working
People who get consistently good results from AI usually have more than good prompts. They develop a way of working: how to break down the problem, what context to provide, which tools or Skills to use, what to verify, where human judgment matters, and what a useful result should look like.
A Playbook makes that method reusable.
It can describe recommended steps, instructions, expected outputs, and useful resources such as Skills, graphs, MCP servers, documents, or other agent harnesses. But a Playbook is not intended to replace those systems or to be a more expressive version of a Skill.
A Skill or graph may already contain a complete execution method. The difference is that those usually belong to an agent or runtime. A Playbook represents the shared way a team approaches a kind of work, independently of which runtime eventually executes it.
That separation matters because the execution layer changes quickly. Today a team may use Claude Code, Codex, OpenClaw, or an internal agent. Six months from now, the tools may be different. The reusable method should not have to disappear with them.
Cases Preserve the Actual Work
A reusable method and one real piece of work are different things.
A Playbook might describe how to review a software architecture, investigate an incident, conduct research, or evaluate a product idea. A Case is one actual instance of that work.
The Case gives the job an identity outside any individual agent session. It can survive when the person changes, when the agent changes, or when the work pauses and resumes later.
As the Case develops, people and agents can attach the information that is worth carrying forward: intermediate results, decisions, review comments, files, handoff context, or final outputs. We call these Records.
The purpose is not to mirror everything an agent does internally. A runtime may make dozens of tool calls, retries, or graph transitions that nobody else needs to see. What matters is preserving the information that another participant would otherwise have to reconstruct.
This is the key distinction between runtime state and work state. Runtime state helps an agent execute. Case state helps a team understand and continue the job.
Collaboration Happens Around the Case
AI-assisted work is often described as one person delegating to one agent. In real organizations, work moves.
One person may start an analysis with an agent. A colleague reviews it. That review changes the direction. Another person takes over, using a different agent. A specialist may need to answer one question before the work can continue.
The path is no longer simply human-to-human or human-to-agent. It may look more like:
person → agent → reviewer → another person → another agent
In that environment, changing the assignee is not enough. A useful handoff also carries the current result, relevant decisions, important intermediate work, and the context the next participant needs.
A Case provides the shared place for that continuity.
When explicit coordination is necessary, a Case can also have a Task. A reviewer might need to approve an output, or another person may need to investigate a specific issue. But Tasks are not the center of Epismo. They exist only when the Case needs explicit ownership, review, or handoff.
If one agent can complete everything by itself, there may be no Task at all.
Materialize Only What Needs to Survive
One possible solution to continuity is to record everything every agent does. We do not think that is necessary.
If Claude Code can follow a Playbook, complete the work, and return a good result, Epismo does not need to store its entire transcript, every tool call, or every internal graph state.
Instead, Epismo follows a materialize-on-demand principle: information becomes shared state when it becomes valuable outside the runtime that produced it.
An intermediate result needs human review? Preserve it.
A decision changes the direction of the work? Preserve it.
Another agent needs context from the previous participant? Preserve a handoff summary or the relevant Records.
An internal retry happened and nobody else needs to know? Leave it inside the runtime.
This keeps Epismo focused on collaboration rather than turning it into another execution engine or telemetry store.
Cases Improve Playbooks
The relationship between Playbooks and Cases also creates a feedback loop.
A Playbook describes the current best way to approach a type of work, but real Cases reveal where that method can improve. A team may discover that an important question should be asked earlier, that an expected output is unclear, or that human review is needed at a different point.
Those lessons can become Suggestions for improving the Playbook.
The cycle is simple:
Playbook → Case → learning from real work → improved Playbook
This is how an individual way of working can gradually become a team capability. One person finds a better method, others reuse it, real work exposes weaknesses, and the method improves.
When appropriate, Playbooks can also be shared beyond one team. Useful ways of working should not have to remain buried in private chats, local setups, or individual habits.
A Shared Layer Above Agent Execution
There is a lot of interesting work happening around agent harnesses, graph engineering, and loop engineering. These approaches make individual agents better at executing complex tasks: they improve tool use, iteration, context management, recovery, and control.
Epismo is interested in the layer that becomes important once the work outlives one harness, one graph, one loop, or one session.
A graph can manage execution inside an agent system. A Skill can package useful capability. A loop can help an agent reach a better result.
But when a human changes the direction, another agent needs to continue, or the job survives until tomorrow, the team needs somewhere for the work itself to live.
That is why Epismo does not try to replace the agent runtime. Execution should remain with the agents and tools people already use. Epismo provides the shared layer around them.
The runtime can change while the Case remains the same.
Playbook and Case Are the Center
The simplest way to understand Epismo is through these two concepts.
Playbook is the reusable way a kind of work gets done.
Case is one actual piece of work that people and agents continue together.
Records preserve the parts of a Case worth carrying forward. Tasks appear when explicit coordination is needed. Suggestions turn lessons from real Cases back into better Playbooks.
Everything else supports those two objects.
As AI becomes a normal participant in team work, we believe this distinction will matter more. The strongest teams will not only have capable agents. They will be able to reuse good ways of working and continue real work without reconstructing its context every time responsibility changes.
Playbooks preserve the method. Cases preserve the work.
That is the shared layer we are building with Epismo.