AI agent handoffs need a session manifest

The agent gets stuck halfway through the job.

It has read the source files, tried one approach, hit a permissions error, changed direction, and left a short note for the next model: "Continue from here."

That sounds convenient until someone has to trust it.

The next operator does not know which files were current, which tools were allowed, which failures were real, which assumptions were guesses, or whether the first model quietly skipped a rule the second model must obey. A long transcript might contain the answer. That does not make it a handoff.

If teams are going to pass agent work between people, models, machines, and follow-up sessions, they need a session manifest.

Cognato points at the handoff problem

Cognato AI is using a deliberately familiar phrase: "Version Control for AI Agents." Its homepage promises the ability to "push, pull, and clone agent sessions" and "switch models mid-task."

The useful part is the problem statement:

Example

"AI agent sessions are isolated, opaque black boxes. When an agent hits a wall, you can't easily hand off its context. When it makes a mistake, enterprises have no way to audit its reasoning. Traditional version control tracks human code, not autonomous agent intent."

Cognato describes Mach as a protocol for "serializing, versioning, and verifying agent memory" across models and platforms. It names model swapping, multi-agent orchestration, time-travel debugging, and session trees as possible workflows.

That is the current signal. Agent work is starting to look less like one chat window and more like a transferable work object.

But a transferable object is not automatically a trustworthy one. A Git branch travels with commits, diffs, authors, timestamps, and review history. A cloned agent session needs the same kind of operational packaging for the work it carries.

A manifest is not the memory

Agent platforms are already building durable memory and replay surfaces. LangGraph's persistence docs describe short-term memory through checkpointers and long-term memory through stores. Apache Burr focuses on stateful AI applications and reliable agent workflows.

Those layers matter. They help the system pause, resume, inspect, and replay.

A session manifest has a different job. It is the small packet that lets the receiving operator decide whether the handoff is safe to accept.

Think of it less like storage and more like the cover sheet on a case file. It does not replace the evidence. It tells the next person what the evidence is, where it came from, what has already happened, and what still needs judgment.

That distinction matters because teams already have a separate need for a state ledger. The ledger tracks the live workflow record. The manifest travels at the transfer point.

The receiving model may not share the same rules

The handoff problem gets sharper when a session moves between models or environments.

One agent may have been allowed to read files but not write them. Another may have shell access. One may be running in a sandbox. Another may be connected to a customer system. One may be following a repository instruction file. Another may never see it unless the handoff includes it.

Stanford's CS336 AI agent guidelines are a clean public example. The course tells AI assistants to act as a "Teaching Assistant, Not Solution Generator." It says they may explain concepts, review student-written code, and suggest sanity checks. It also says they should not write Python or pseudocode, edit code in the student repo, or run bash commands.

If a teaching session built under those rules gets handed to a more capable coding agent, the receiving agent needs to know the constraint. Otherwise it may treat the task as unfinished implementation work instead of a bounded teaching interaction.

The same pattern appears in business workflows. A support assistant may draft replies but not send them. A finance assistant may read invoices but not update payment status. A coding agent may edit tests but not deployment manifests. The rule that mattered in the first environment has to travel with the session.

What has to travel

The first manifest should be short enough that people actually use it. Start with the facts that change whether the next step is safe.

Scroll sideways to see all 3 columns.

Handoff question	Manifest field	Why it matters
What was this session supposed to do?	Goal and success condition	Prevents the receiver from optimizing for the wrong outcome
Who or what is receiving it?	Next operator	Separates human review, model switch, machine resume, and parallel agent work
What rules applied?	Local instructions and permission boundary	Carries repository, workflow, legal, teaching, customer, or approval constraints
What did the agent inspect?	Source list	Shows whether the work used current files, records, docs, URLs, or retrieval results
What tools were available?	Tool and credential scope	Makes hidden capability differences visible before resume
What did it already attempt?	Attempts, failures, and retries	Stops the next run from repeating the same mistake or trusting a failed path
What crossed a boundary?	Receipts and side effects	Links to proof when files, records, tickets, messages, or artifacts changed
What still needs a person?	Open decisions	Prevents the receiver from treating unresolved judgment as completed work
How should this be checked?	Verification path	Gives the receiver a test, review step, source comparison, or acceptance criterion
How can this be undone?	Rollback owner and path	Names who can contain the result if the resumed work goes wrong

That is not a compliance thesis. It is a packing list.

If the session only wrote a disposable draft, the manifest can be lightweight. If it touched code, customer records, finance workflows, public content, or regulated data, the manifest should be explicit enough that a reviewer can reject the handoff without reading the entire transcript.

Receipts close the accountability gap

The manifest should link to receipts, not replace them.

A receipt records what happened when the workflow crossed a meaningful boundary: a message was sent, a record changed, a file was edited, a ticket was routed, a pull request opened, a recommendation approved.

That matters because handoffs blur responsibility. The first operator may say the agent only prepared a draft. The second operator may assume the draft was checked. A follow-up model may inherit a clean summary that hides a failed tool call. A week later, the business sees the outcome but not the chain of custody.

We covered the logging side in Agent receipts: what to log before AI touches customer work. For handoffs, the rule is simpler: the manifest should point to the receipts that prove what crossed an action boundary.

If there are no receipts, the manifest should say so plainly.

Run maps explain the path. Manifests explain the transfer.

A manifest also works beside run maps, replay tools, and checkpoint gates.

In our earlier review of Apache Burr and AI agent state machines, the useful idea was making agent workflows visible as states, transitions, and replayable paths. That helps teams inspect what happened inside the workflow.

The session manifest sits at the transfer point.

A replay trace can show that the agent moved from "retrieve customer record" to "draft response" to "request approval." The manifest should tell the next operator whether the retrieved record was current, whether the approval is still pending, whether the draft used an unverified claim, and who owns the rollback if the message goes out.

Both artifacts matter. The run map explains the machine path. The manifest explains the handoff risk.

Start with the handoff that already feels uncomfortable

Most teams do not need a universal protocol on day one. They need one manifest for one transfer that already makes people nervous.

Pick a handoff like one of these:

• a developer agent session passed from one engineer to another
• a support draft escalated from frontline support to a manager
• a research session handed to a second reviewer
• a back-office automation run that prepares updates for finance, HR, or operations
• a long task that switches from one model to another when the first model gets stuck

Write the manifest before buying more orchestration. Decide which fields the agent can fill automatically, which fields a human must confirm, and which missing fields block resume.

A useful first rule: if the receiving operator cannot identify the goal, sources, permission boundary, failed attempts, open decisions, verification path, and rollback owner in two minutes, the session is not ready to resume.

The practical control

A team that can clone sessions but cannot explain them has not solved collaboration. It has made uncertainty portable.

Cognato's Mach framing is useful because it names the thing many teams are starting to feel: agent work needs versioning, verification, and collaboration patterns. LangGraph, Burr, and similar infrastructure show that durable agent work is becoming normal. The business layer now has to catch up.

Before teams push, pull, clone, branch, or audit agent sessions, define the packet that travels with the work.

Start with the manifest. Keep it short enough to use. Make it explicit enough to trust. Then connect it to the controls around the workflow: scoped permissions, approval gates, receipts, replay, and rollback.

If your team is piloting AI agents across code, support, operations, research, or back-office workflows, BaristaLabs can help map the first version. Our AI workflow controls framework and process automation work focus on the artifacts that make automation safe to hand off, not just impressive to demo.

When you are ready to turn one active workflow into a resumable, reviewable handoff packet, map a session manifest.