The Agent Is Not the Work

Part one of The Ghost, the Shell, and Earned Autonomy. Next: Capability Is Not Authority, then I Don't Turn Autonomy On. I Earn It..

I kept watching good AI sessions reach a boundary.

Not crash. Not hallucinate. Just reach the ordinary boundary of an execution: the context window filled up, a permission wasn't available, the task needed a browser, or I closed the lid of my MacBook and went to bed.

Codex and Claude can both resume sessions, and I use that constantly. Reopen the conversation, recover the context, keep going. For an interruption, that is often enough.

The problem appears when continuing the conversation is not the same as continuing the commitment. The context may have been compacted. The repository may have moved. Another agent may need to take over. The work may need to cross from a coding environment into a browser or review environment. A session can be perfectly resumable while the work is still trapped inside it.

The work was usually fine. The agent in that session had read the codebase, formed a plan, changed the right files, run half the checks, and found the awkward edge case. If I resumed that exact session, it could often continue. But when I couldn't—or when the work needed a different kind of worker—the next execution began with the most expensive sentence in agentic development:

“Let me inspect the repository and understand the current state.”

Again.

My first instinct was to make session continuity carry more of the load: resume whenever possible, preserve bigger summaries, write longer handoffs, keep entire transcripts if necessary. All of that is useful. It extends the life of the worker. It does not give the work an identity outside that worker.

I was still treating the session as the work.

The session is only where one worker runs. The commitment is the work.

The worker changes. The commitment does not.

Step through the relay from one finite execution to the next.

Finite runtime

Session A

→

Structured boundary

Stop + evidence

↓

Durable responsibility

Ghost holds the commitment

Outcome · constraints · authority · evidence refs

↓

Next execution

Session B resumes

A temporary agent works through one finite session. The Task may survive this execution; neither the agent nor the session owns the outcome forever.

execution: active
task: still open
commitment: still open

One conversation was hiding four different objects

In a normal chat interface, the conversation quietly becomes everything at once: the worker, the task, the memory, and the owner. That is convenient for a ten-minute request. It is a terrible foundation for a commitment that might cross three sessions, two tools, and a human decision.

I ended up separating four things that I had previously allowed to blur together:

Concept	What it is	How long it should live
Session	One conversational or runtime session with finite context and capacity	Minutes or hours
Task	One bounded unit of work with scope and acceptance criteria; it may survive multiple execution attempts	Until accepted, returned, cancelled, or superseded
Commitment	The outcome that remains open until evidence says it is done	Days or weeks
Ghost	Durable responsibility for carrying the commitment across tasks and executions	As long as the responsibility exists

This sounds like naming, but it changes the product.

If a session owns the work, a dead session creates an orphan. A Task can and should survive several executions, but it is still a bounded unit of work; the larger outcome may require more than one Task. If the commitment owns that outcome, Tasks and sessions can come and go without changing what “done” means.

The Ghost answers who remains responsible and keeps that ownership legible.

A Ghost is not a personality

“Ghost” risks sounding more mystical than it is. Mine is not a digital clone, a role-play prompt, a long-term memory database, or one model pretending to be immortal.

It is durable delegated responsibility.

A Ghost says: this outcome is still mine; these constraints still apply; this is the authority I have; this is the evidence already collected; this is the smallest unresolved decision. The model running the next execution can change. The harness can change. Even the kind of environment can change. The responsibility does not silently evaporate with them.

That distinction stopped me trying to make an AI remember everything. It does not need everything. It needs the state that carries consequence:

The outcome and its acceptance criteria.
The current execution claim and latest checkpoint.
Verified evidence, referenced canonically.
Unresolved assumptions and decisions.
The authority boundary for the next action.
The reason the previous execution stopped.

Everything else is useful context at best and narrative sediment at worst.

The return is more important than the prompt

Most agent tooling invests heavily in the start of a task: the perfect prompt, the right files, a role, a plan. I now spend at least as much design energy on how an execution ends.

A useful return is not “I made progress.” It is a typed boundary between executions:

outcome       what changed, in plain language
evidence      commits, checks, artifacts, observed results
checkpoint    the exact stable state reached
stop_reason   complete, blocked, missing capability, or human decision
unknowns      assumptions the next execution must not treat as settled
next_step     the smallest bounded continuation

That return closes one execution cleanly without pretending the Task or commitment is complete. It also prevents a stopped agent from laundering confidence through prose. “Tests pass” is an agent-reported finding. A reference to the check that passed is evidence. Both can be useful, but they are not the same thing.

The Ghost carries the distinction forward.

Continuity is not transcript replay

I tried the transcript-shaped version of handoff. It was comforting because nothing appeared lost. It was also noisy, expensive, and subtly unsafe.

The next worker inherited stale guesses beside verified facts. It had to rediscover which parts of the conversation still mattered. Sensitive output travelled farther than it needed to. The handoff was a story, not state.

The better pattern was a continuation packet made mostly of references:

Fetch the Task from its canonical record.
Fetch the commitment and current acceptance criteria.
Fetch evidence from the source that can verify it.
Carry unresolved assumptions explicitly.
Leave the full transcript behind.

This is less like giving the next agent memories and more like giving a new engineer a clean issue, a current branch, the relevant decisions, and the test results. Continuity comes from the quality of the operating system around the agent, not the illusion that the same mind woke up again.

The product-development lesson

This changed how I approach AI features more broadly.

The tempting demo is the intelligent session: watch it reason, call tools, and produce something impressive. The durable product is the system that still knows what matters after that session disappears.

So I now ask different questions early:

What is the business outcome, separate from the current execution?
Where does responsibility live when the model is not running?
What evidence survives a restart?
Which unknowns must remain visibly unknown?
Can another worker resume without reconstructing my intent from chat?

Those questions are not glamorous. They are the difference between an agent demo and an operating model.

Then the worker reached a wall

Once I had continuity, another boundary became obvious.

Continuity answers who still owns the work. It does not answer where the next action may safely occur.

An agent in a coding session could implement a change and run local checks, but it could not safely complete an authenticated browser workflow. Giving that agent every credential and every tool would have made it more capable. It would also have collapsed several authority boundaries into one enormous blast radius.

The commitment needed to continue, but the next action needed another kind of execution environment.

The Ghost needed a Shell.

Next: Capability Is Not Authority — why I stopped building giant tool-equipped agents and started treating execution environments as bounded Shells.

Related: A Month of Agentic Delivery is the earlier account of the harness and team practices around this work. The Messaging-Native Agent Moment explores why the control interface cannot stay trapped in the terminal.