AI Agent Handoff Failure: The Reviewed Task Never Arrived

An AI agent handoff failed while every visible startup signal looked healthy. Hermes Desktop created the session and opened it. The new session still showed a blank prompt because the task never crossed the submission boundary.

That distinction changes how teams test agent systems. Session creation proves that a destination exists. Task transmission proves that the reviewed instruction reached that destination. Task execution proves that the agent accepted the work and produced activity or a terminal result. Each stage needs its own state and evidence.

This case comes from Nocturnal's internal product development. It describes an engineering failure and repair inside an Eclipse Control Room workflow. No client incident or customer outcome is involved.

Proof scope: Internal Hermes Desktop handoff evidence checked July 28, 2026. The payload values are sanitized, while the field names and state transitions reproduce the observed failure and repair.

The failure looked like an idle agent#

The internal dispatch flow made two calls. The first created a recoverable Hermes Desktop session. The second was supposed to submit the task to that session.

The first call succeeded. The second call used a message field. The live prompt.submit contract required text.

{
  "session_id": "<created-session>",
  "message": "<reviewed-task-packet>"
}

Hermes retained the created session while the task submission was rejected or dropped at the contract boundary. Opening the session showed a blank prompt. The interface made the agent look idle even though the agent had never received work.

The accepted shape used the required field:

{
  "session_id": "<created-session>",
  "text": "<reviewed-task-packet>"
}

The repair changed the parameter, submitted the complete reviewed packet, and added a regression guard that rejects an empty or incorrectly shaped submission before dispatch.

Evidence receipt: Field names and harness assertions come from the current local Control Room and Eclipse Suite tests. The harness throws when params.text is missing or empty. The source test hash is embedded in the SVG.

The three states buyers need to see#

A useful AI agent handoff exposes these states separately:

A single green label such as "Agent started" compresses too much. It hides whether the system created a container, delivered a prompt, queued work, called tools, or completed the requested outcome.

The following eight mechanisms keep those claims separate.

Mechanism 1: session creation gets one narrow meaning#

Session creation should answer one question: did the runtime create a recoverable destination for future messages and work?

The creation receipt can record the runtime, session reference, creation time, requested workspace or profile, and initial state. It should stop there. It should never imply that the reviewed task is present.

This narrow definition prevents a common dashboard error. The system receives a valid session reference, marks the entire handoff successful, and opens the session route. Every visible check passes while the prompt remains empty.

A good state machine moves from requested to session_created. It waits for independent transmission evidence before moving to task_submitted.

Mechanism 2: task transmission follows the live contract#

Task transmission begins with contract validation. For this Hermes Desktop case, prompt.submit required { session_id, text }. The text value also had to contain the task.

The client should validate those conditions before the request leaves the control surface. The receiver should validate them again. Unknown aliases such as message should fail with a visible error because permissive fallback behavior turns schema mistakes into silent work loss.

The submission result should identify the target session, packet revision, acceptance state, and time. A network request that returned without throwing is weak evidence. The receiver needs to acknowledge the task it accepted.

This is the first place to test an AI agent handoff with a deliberate failure. Replace text with an unsupported field. The workflow should preserve the created session, mark transmission failed, and offer a repair path. It should never claim that the agent is working.

Mechanism 3: task execution earns separate proof#

An accepted submission still has distance to travel. The task can wait in a queue, fail during runtime setup, hit a permission gate, or stop on invalid input.

Execution proof begins when the agent or worker acknowledges the submitted task and enters an active state. Completion proof arrives later through a terminal status, an output reference, and any required verification result.

For consequential work, a transcript line saying "done" is too weak. The receipt should point to the actual artifact, state change, or system response that satisfies the acceptance criteria. Failed work needs the error class, last valid state, next owner, and recovery action.

The sequence should read plainly:

session_created -> task_submitted -> execution_started -> completed|failed|cancelled

Each transition has a different actor and proof source. That separation makes a blank session easy to diagnose because the chain stops at transmission instead of pretending execution stalled.

Mechanism 4: the full reviewed packet crosses the boundary#

Correct transport can still deliver the wrong task. A thin instruction such as "continue the work" forces the receiving agent to reconstruct authority and context from whatever happens to be available.

The repaired workflow submits the complete packet the reviewer saw. The packet covers:

• the objective and requested state change;
• the authority, actor, and side-effect boundary;
• the exact input and evidence references;
• constraints and prohibited actions;
• deliverables and acceptance criteria;
• verification requirements, recovery instructions, and next state.

That packet gives the receiving agent enough context to execute without guessing. It also gives the reviewer a stable object to approve.

Completeness has a cost. Packets become larger and require schema discipline. That cost is cheaper than recovering a partial instruction after the receiving session has already started making assumptions.

Mechanism 5: Preview -> Authorize -> Submit stays ordered#

The repaired control flow uses three visible transitions.

Preview builds the complete packet and shows the human what will cross the boundary. The reviewer can inspect the objective, authority, inputs, constraints, deliverables, and verification rules.

Authorize records permission for that reviewed packet. Authorization should bind to the packet's meaning, the target action, and the reviewer. It should carry no hidden submission or execution side effect.

Submit sends the authorized packet through the live transport contract. The sender must use the reviewed revision. A submit action cannot rebuild the packet from current UI state because a field may have changed after authorization.

This pattern complements the AI agent approval workflow failure case, where recommendation, decision, and rationale could contradict one another. Both failures come from treating approval as a button press instead of a state transition bound to authoritative evidence.

Mechanism 6: semantic hashing binds the reviewed meaning#

The workflow uses semantic hashing to recognize the packet that earned authorization. It first converts the meaning-bearing fields into a canonical representation, then fingerprints that representation.

Canonicalization should include a schema version, stable field ordering, normalized state values, and every field that can change the action or its risk. It should avoid volatile presentation details that do not change meaning.

The trade-off matters. A raw byte hash can reject harmless formatting changes. A loose projection can miss a changed permission, destination, input, or stop condition. A versioned semantic projection sits between those extremes, but it needs tests for every field that carries authority.

The fingerprint supports comparison. It does not explain the packet by itself, replace human review, or grant permission. The durable record still needs the readable packet, approval state, and provenance.

Mechanism 7: stale packets fail closed#

Authorization becomes stale when a meaning-bearing field changes after Preview. The submit action should compare the current packet with the authorized semantic fingerprint before transmission.

Changes to the objective, target session, inputs, permissions, external side effects, deliverables, acceptance criteria, or recovery rules should invalidate the old authorization. The workflow returns to Preview and explains which field class changed.

Silent refresh creates a dangerous shortcut. The interface can show current content while the backend relies on an earlier approval. Stale-packet rejection forces both layers to agree on the reviewed revision.

The same rule applies across creative and operational systems. The AI agent governance architecture case shows why a selected or repaired candidate needs a fresh operational authorization before deterministic execution or release.

Mechanism 8: handoff receipts prove each transition#

A handoff receipt is a compact, replayable account of one transition. It should bind the transition to the packet revision, actor, time, result, and next state.

A portable receipt model can separate the evidence this way:

Receipts should avoid secrets and unnecessary private data. Their job is to let an operator reconstruct the handoff without opening a private transcript or trusting a green badge.

Idempotency belongs here too. A retry after timeout should return the existing submission or execution receipt when the same authorized packet already crossed the boundary. That keeps a network retry from creating duplicate work.

The five-check buyer diagnostic#

Use five controlled checks during a vendor demo, pilot review, or architecture audit. A production AI agent handoff should pass every one.

A vendor that shows session creation as proof of execution fails the first check. A vendor that cannot demonstrate stale-packet rejection has an approval gap. A vendor that relies on chat history for recovery has an evidence gap.

The broader five-record AI agent handoff test covers owners, fallbacks, logs, reject cases, and stop conditions across messy business records. Run both diagnostics before granting production writes.

Where workflow repair fits#

This failure sat between a working interface and a working agent. The missing layer was the dispatch contract that connected them.

Nocturnal's AI Agent Workflow Repair service traces that middle layer. We map the session lifecycle, submission schema, packet authority, preview and approval states, stale-data behavior, execution evidence, retries, receipts, and recovery path. The engagement ends with denied-path tests and a handoff your operator can replay.

Three related reviews help locate the defect:

• Use the AI agent handoff test when owners, fallbacks, logs, and reject paths remain unclear.
• Use the AI agent approval workflow failure case when recommendation, decision, override, and provenance can disagree.
• Use the AI agent governance architecture case when selection, execution authorization, and release authority share one surface or state.

The service bridge is practical: bring one broken flow and the smallest reproducible failure. We will identify the last proven state, repair the contract, and test the path that used to disappear.

What to measure after the handoff repair#

BrandLab evaluation belongs after the intended artifact arrives. It cannot compensate for a missing task. Transport proof, execution proof, artifact review, and release authority stay separate.

Methodology and disclosure#

We derived this article from an internal Eclipse Control Room repair against Hermes Desktop. We reproduced the blank-session behavior, separated session creation from prompt submission, compared the submitted payload with the live prompt.submit contract, corrected the task field, and reran the dispatch with the complete reviewed packet.

The repair also added preflight validation, Preview -> Authorize -> Submit, semantic packet binding, stale-packet rejection, handoff receipts, and a regression guard for empty or incorrectly shaped submissions. Review focused on the failure path as well as the working path.

This is first-party engineering evidence from an internal product. It is neither a client case study nor an external security certification. Identifiers, environment details, and fingerprint values are omitted. Other agent runtimes can use different method names and schemas, while the three-state distinction and evidence requirements still apply.