Agents Are Ephemeral. Work Is Durable
AI coding agents are getting better quickly.
But making an agent smarter is only part of the problem.
The harder problem starts when you want agents to work for longer than a single session.
An agent can inspect a repository, write code, run tests, and make decisions. Eventually, though, that session ends. Its context fills up. The model changes. The process crashes. Or you want another agent to take over.
What happens to the work then?
Context is not state
The usual response is to keep feeding the agent more context.
Conversation history. Summaries. Previous instructions. More files. More tokens.
That works for a while. It also makes the agent’s context window responsible for something it was never designed to be: the system of record for ongoing work.
There is a simpler model.
Persist the work, not the agent.
The durable state is everything required to continue: what we are trying to achieve, which step is in progress, what has already been completed, repository and branch state, commits and changed files, decisions and feedback, artifacts produced along the way, verification results, and failures with their causes.
The agent becomes an executor operating against that state. It is no longer the owner of the process.
That distinction matters because context and state solve different problems.
Context helps an agent understand the work it needs to perform now.
State tells the system what the work is.
Fresh agents should be able to continue
Imagine an agent is asked to implement a feature.
It receives the intended outcome, relevant context, and repository. It writes the implementation, commits its changes, and finishes.
Now throw the agent away.
A second agent starts with a fresh context window. It inspects the workflow, repository, and outputs from the previous step. Its job is to review the implementation.
It finds a problem and records feedback.
The review agent disappears.
Another fresh agent starts, sees the implementation and review feedback, fixes the problem, and exits.
Finally, a verifier checks the result.
None of these agents needs to remember the conversation that came before it.
The work itself carries the state forward.
That is already becoming the shape of real agent tooling. GitHub describes Copilot cloud agent as an autonomous, background environment that can research a repository, create a plan, make code changes, run tests, and open a pull request. GitHub also makes the environment explicitly ephemeral. The important artifacts are the branch, commits, logs, and pull request, not the session that produced them.1
The session is temporary.
The work is not.
This is starting to look like distributed systems
Once the state lives outside the agent, replacing an agent becomes unremarkable.
A coding agent does not need to personally hand a conversation to a reviewing agent.
It leaves the environment in a known state.
The next worker picks it up.
This is much closer to a distributed system than a chat session.
Workers are temporary. State is durable. Work can fail and retry. Different workers can perform different roles. Execution can move between machines or runtimes without losing the underlying process.
That is the same basic idea behind durable execution systems. Temporal, for example, persists workflow state so a process can recover after failure, resume in another process, and continue with its previous state intact.2
Agent workflows need a similar separation.
The model is one execution resource.
The workflow is the durable process around it.
This also changes how we should think about model choice. One step might run with Claude Code. Another might use Codex. A third might use a specialist reviewer or a deterministic verification tool.
The workflow should not care which model performed the previous step, as long as the required state and artifacts are present.
Bigger context windows do not remove the problem
Models will continue getting larger context windows and better memory.
That is useful.
It does not change the architectural question.
If an important software delivery process can only continue because one agent remembers everything that happened, the agent has become your database.
That is a fragile foundation.
Longer context can help an agent reason through a difficult task. It cannot guarantee that the reasoning is available after a crash, a timeout, a model change, or a handoff.
It also cannot tell the next agent which parts of the previous session were decisions, which were guesses, which were completed actions, and which were abandoned ideas.
A transcript is not a workflow state model.
The system needs to record those things explicitly.
The task becomes the handoff boundary
A durable workflow needs a stable object at its center.
For software work, that object might be a task, bug, initiative, pull request, or implementation plan.
It needs to carry more than a title.
It should explain why the work exists, what outcome matters, what constraints apply, what has happened already, and what decision is needed next.
OpenAI’s description of harness engineering points in the same direction. The team describes the agent-first repository as an environment where humans specify intent, agents execute, and feedback loops make the system increasingly legible and enforceable.3
That is not a case for giant prompts.
It is a case for structured work.
A weak task forces every new agent to rediscover the problem.
A strong task lets the next agent begin where the previous one stopped.
This is also why task trackers are becoming more important in agentic development. They are no longer just places to record work after the fact. They are becoming dispatch surfaces for work before execution begins.
The task is where intent enters the system.
The branch, commits, tests, review comments, and release are the evidence that intent moved through it.
People can step into the same process
Durable state also makes human involvement much cleaner.
A person does not need to receive a conversational handoff from the agent. They can inspect the same state the next worker would inspect.
They can review the result, leave feedback, reject an approach, approve a step, or change the intended outcome.
Then an agent continues from that updated state.
There does not need to be a separate “AI workflow” and “human workflow.”
There is just the workflow.
This matters because human judgment will remain part of software delivery even as agents handle more execution. GitHub’s own documentation still describes human review and approval as part of the path for agent-generated changes, while providing logs and artifacts so people can understand what happened.1
The right goal is not to remove people from the process.
It is to stop making people reconstruct the process from memory.
The agent should be disposable
This leads to a useful design test for agentic systems:
Could you kill the current agent and continue the work with a fresh one?
If the answer is no, important state probably still lives inside the session.
If the answer is yes, the architecture becomes more flexible.
You can choose the best agent for each job. Retry with another model when one fails. Separate implementation from review. Add verification steps. Require approval for sensitive actions. Move execution between local and remote workers.
The workflow survives all of it.
At One Horizon, this is the part of agentic development we care about. Tasks, initiatives, commits, pull requests, reviews, and verification should form a durable record of the work, independent of whichever agent happened to execute the latest step.
The agent can be replaced.
The model can change.
The process can pause.
The work should still be there.
Agents are ephemeral.
The work is durable.
