Build a Durable AI Agent Handoff Ledger With Lark Base

A reliable AI agent handoff needs two separate proofs: the transport delivered an offer, and the receiving agent explicitly accepted ownership. A message such as "sent" proves neither acceptance nor completion. Put the handoff packet in a durable shared ledger, give it a stable ID, and require the receiver to update the same record through offered -> accepted -> completed or escalated states.

This guide builds that receipt protocol with Lark Base and Aident Loadout. It complements native cross-session messaging instead of replacing it. Messaging wakes the receiver; the ledger remains the source of truth when a session restarts, a notification is missed, or a sender sees a false success.

Why "Message Sent" Is Not a Handoff

Anthropic added cross-session SendMessage and ListAgents support in Claude Code 2.1.224, then tightened delivery behavior in 2.1.225. The 2.1.224 release also fixed a false "Message sent" result when the inbox write failed. On August 12, 2026, users separately reported messages that appeared sent but did not wake an idle session, interrupted the receiver, or remained unnoticed until focus changed. These are individual reports, not proof that every installation is affected.

The broader lesson is stable: transport acknowledgement, ownership acceptance, and verified completion are different events.

Define One Handoff Record

Create a Lark Base table with these fields:

• handoffId: unique text generated by the sender;

• status: offered, accepted, completed, escalated, or cancelled;

• sender: the initiating agent or operator;

• receiver: the intended owner;

• requestedOutcome: one bounded, verifiable result;

• evidenceLinks: repository, issue, document, or artifact URLs needed to act;

• exactNextAction: the first safe action the receiver should take;

• acceptBy: the ownership deadline;

• acceptedAt and completedAt: receipt timestamps;

• completionEvidence: the diff, test result, artifact, or external receipt; and

• attempt: a retry counter that does not change the handoff ID.

Do not put API keys, tokens, raw customer data, full chat transcripts, or provider responses in the ledger. Link to access-controlled evidence instead.

A stable ID can combine the project, task, and version:

handoff:aident-docs:blog-audit:2026-08-12:v1

Retries reuse that ID. A new scope or outcome gets a new version.

Step 1: Discover the Current Lark Base Actions

Install Aident Loadout by giving your agent this instruction:

Follow https://aident.ai/SETUP.md

Then confirm authentication and discover by intent:

aident account auth status
aident vault vault --action status

aident capabilities search \
  --queries '["Lark Base list fields", "Lark Base search records", "Lark Base create record", "Lark Base update record", "Lark Base record change history"]' \
  --targetEnv staging

At the time of writing, the staging catalog exposed separate Actions for listing fields, searching records, creating a record, updating a record, and reading record change history. Inspect the current schema for every Action you plan to use. Do not copy a private integration identifier into a prompt, report, or reusable workflow.

Preflight one read and one write with the exact table and fields before execution. The reviewed August 12 schemas passed zero-credit preflights; create and update remained writes that require consequence review even when the Aident credit quote is zero.

Step 2: Offer the Work

The sender first searches for handoffId. If a record already exists, it reads the current state instead of creating a duplicate. Otherwise it creates exactly one offered record.

Use this packet:

{
  "handoffId": "handoff:aident-docs:blog-audit:2026-08-12:v1",
  "status": "offered",
  "sender": "research-agent",
  "receiver": "review-agent",
  "requestedOutcome": "Validate the blog lifecycle audit and report every error",
  "evidenceLinks": ["https://github.com/Aident-AI/aident.ai/pull/5442"],
  "exactNextAction": "Run the read-only lifecycle audit from the repository root",
  "acceptBy": "2026-08-12T21:00:00Z",
  "attempt": 1
}

After the record exists, send the native cross-session message with only the handoff ID, record URL, requested outcome, and acceptance deadline. The message is a notification. It is not the durable packet.

Step 3: Require an Acceptance Receipt

The receiver searches for the exact handoff ID, verifies that it is the intended owner, and checks that the requested outcome is bounded and safe. It then updates the same record:

{
  "status": "accepted",
  "receiver": "review-agent",
  "acceptedAt": "2026-08-12T20:24:00Z"
}

The sender polls the record, not the chat transcript. Only accepted with the expected receiver counts as ownership transfer. If the deadline passes while the state remains offered, mark it escalated and choose another owner or return the work to a human. Do not send an unlimited series of wake-up messages.

For concurrent receivers, require a read before update and reject an acceptance when another receiver already owns the record. If the current Action contract cannot enforce atomic claiming, assign one intended receiver and let a human resolve collisions.

Step 4: Complete With Evidence

The receiver performs the work, runs the named validation, and updates the record with a small receipt:

{
  "status": "completed",
  "completedAt": "2026-08-12T20:31:00Z",
  "completionEvidence": {
    "command": "node .agents/skills/aident-blog-lifecycle/scripts/audit-blogs.cjs --fail-on-errors",
    "exitCode": 0,
    "observed": "233 posts, no lifecycle errors"
  }
}

Evidence should be specific enough for another operator to verify without replaying the entire session. For code work, include the commit or diff and the exact test. For an external action, include the provider object ID and a read-back result. For research, include dated source URLs and the claim they support.

The sender reads the completed record and verifies the evidence before closing the parent task. Lark Base record history can help explain who changed a field and when, but history is supporting evidence, not a substitute for a valid completion packet.

Step 5: Handle Timeouts and Retries

Use a small state machine:

offered -> accepted -> completed
   |          |
   +----------+-> escalated
   |
   +-> cancelled

• Retry only the notification transport. Reuse the existing record.

• Increment attempt when a notification is retried, not when the ledger is read.

• Never create a second record to escape a disputed or timed-out state.

• Escalate when acceptBy expires, the owner rejects the scope, or evidence access fails.

• Cancel only when the original outcome is no longer required.

This separates idempotency from liveness. The stable record prevents duplicates; the deadline prevents work from remaining silently offered forever.

Verification Checklist

Run a disposable two-agent drill and observe these results:

1. The sender creates one record and sends one notification.

2. The receiver updates the exact record to accepted before beginning work.

3. The sender sees acceptance without relying on window focus or chat history.

4. The receiver attaches a command, exit code, and observed result at completion.

5. The sender reads the evidence and closes the parent task.

6. Replaying the notification does not create another ledger row.

7. A deliberately ignored offer reaches escalated after its deadline.

The main product metric is not messages sent. Measure the percentage of offers accepted before deadline, completed with valid evidence, and verified without duplicate work.

Failure Matrix

Run One Durable Handoff

Follow https://aident.ai/SETUP.md

Set up Aident Loadout and test one Lark Base handoff receipt

For the wider concurrency model, read Claude Code Graph Engineering: Orchestrate Agent Teams Safely. For evidence carried across a failing conversation, use the Codex context-compaction handoff guide. For operational attribution after the handoff invokes integrations, use the Action usage audit.

Sources

• Claude Code changelog, reviewed August 12, 2026.

• Claude Code issue 86029: cross-session messages silently lost, individual report reviewed August 12, 2026.

• Claude Code issue 86059: receiving session interrupted, individual report reviewed August 12, 2026.

• Claude Code issue 86088: idle receiver does not start a turn, individual report reviewed August 12, 2026.

• Lark Base overview, reviewed August 12, 2026.

• Lark Base create record API, reviewed August 12, 2026.

• Lark Base update record API, reviewed August 12, 2026.

• Live Aident Loadout catalog, schemas, and preflights for Lark Base, inspected August 12, 2026.

Refresh this guide when Claude Code changes cross-session delivery or expiry behavior, the Lark Base record contract changes, Aident Loadout changes Action risk or pricing, or a production drill cannot preserve one offer-to-verification chain.