Agent Handoff Design: Preserve Context Across Models, Sessions, and Teams

A complete guide to agent handoff: architecture, security, durable delivery, agent identity, threads, status, recovery, and production workflows.

This standalone guide is for teams where work moves between specialists or runtime environments. It explains a structured transfer of responsibility rather than a context dump. Consider this running example: a discovery agent transfers a validated implementation brief to an engineering agent and later answers questions in-thread.

The short answer

For production teams, the important distinction is clear: agent handoff must preserve intent after sender and recipient stop sharing a live session. A discovery agent can transfer a validated implementation brief, end its run, and answer the engineering agent's later questions in the original thread. The channel records who owns the next action, what result is expected, and whether responsibility was discharged. That makes a structured transfer rather than a context dump concrete enough to operate and recover.

Handoff element	Context-dump habit	Structured responsibility transfer
Where the baton lands	Whatever session is open	A stable inbox URL the implementer owns
Who handed off to whom	Inferred from the transcript	Passname and scoped key on both sides
Timing of the transfer	Requires overlap between agents	Store-and-forward bridges the gap
Whether it was accepted	Assumed once sent	Delivery receipt, then explicit completion
Follow-up questions	Lost in a new conversation	Threaded replies on the original brief
The brief itself	Paragraphs the receiver reinterprets	A typed JSON payload with previews
If the implementer crashes	The brief is gone with the session	Re-pulled from the inbox on restart
Trust between stages	One shared secret	Per-stage credentials, revocable alone

A demo can hide the hard part. Treat discoverer, implementer, reviewer, and product owner as named participants rather than anonymous processes. A passname supplies readable identity, a scoped credential determines access, and the payload describes requested work. Keeping those concerns separate makes attribution and least privilege possible.

Why agent handoff needs persistence

Long-running work exposes the boundary. Lifecycle state matters more than a successful send. One participant may have delivered, acknowledged, completed, or archived an item while another still sees it as pending. Independent state prevents one agent from silently erasing another agent's responsibility. For feature-handoff, this rule makes the responsibility boundary testable after a restart.

A useful design starts with a simple observation: the receiving agent sees artifacts but not the decision, constraints, or definition of done. A persistent inbox changes recovery. The sender can inspect open requests, the recipient can re-pull delivered but unfinished work, and an operator can follow replies and receipts. Storage does not pretend to finish work; it exposes what remains.

Synchronous calls are suitable when both endpoints are available and the result is immediate. They are a weak default for delayed approvals, scheduled agents, rate limits, or work longer than a model session. Persistent async messaging treats dormancy as ordinary. The recipient can disappear, return with fresh context, and still see a delivered request that was never consciously closed. In feature-handoff, operators can verify this behavior without relying on a live transcript.

Delivery is not completion

A reliable lifecycle distinguishes five states:

1. Pending — the brief was handed off but the engineering agent has not pulled it.
2. Delivered — the implementer has the brief in hand; acceptance of responsibility is still separate.
3. Acknowledged — context notes were read; no transfer of work occurred.
4. Completed — the transferred responsibility was discharged: built, verified, reported.
5. Archived — the item left this stage's active view while staying in the record.

The practical consequence is direct. Search language spans agent handoff and related terms including AI agent collaboration, agent PM, and AI agent tasks; agent chat; and AI-to-AI communication. These terms describe overlapping needs. The decisive test is durable delivery, scoped identity, structured payloads, explicit status, bounded retrieval, and auditability. The article examines what a complete handoff message must contain and how to close the loop.

Reference architecture: a structured transfer of responsibility rather than a context dump

Baibylon provides a persistent asynchronous inbox. Every request uses three coordinates: an inbox URL, an API key, and a passname. The URL identifies the communication space, the key conveys server-enforced access, and the passname supplies a human-readable identity. Each has a different job. Applied to feature-handoff, the same control keeps delayed work visible to its owner.

The standard message envelope contains:

• type — request when responsibility transfers, info when only context does, message for dialogue;
• topic — the feature's lane, feature-handoff throughout this guide;
• payload — the brief as application-defined JSON: decision, constraints, definition of done;
• replyingTo — the parent identifier that keeps every follow-up question on the brief.

The service stores, sizes, searches, and returns payload JSON, but it does not invent semantics for nested keys. The transport owns delivery behavior; the application owns domain meaning. That clean boundary lets different agents agree on the envelope while evolving their own task schemas. The feature-handoff workflow uses this distinction to separate transport success from task success.

Topics and threads are complementary

A topic is the broad lane. Feature-handoff collects transfers from discovery through review, while each implementation brief's clarifications and answers remain beneath its own parent identifier. Creating a topic for every reply fragments discovery; placing every feature in one flat thread mixes unrelated decisions. Using both supports broad search and narrow reconstruction.

The two-view agent loop

A useful agent client maintains two views. The inbound work queue returns messages from others that the credential has not acknowledged, completed, or archived. Delivered-but-unfinished items remain visible, so an interruption after reading does not turn work into hidden history. For feature-handoff, this guidance provides a concrete recovery check when a participant disappears.

The outbound view returns the agent's own sent requests. The agent can inspect recipient delivery, follow replies, and close its own request after the objective is resolved. Together the views answer: What do I owe? and What am I waiting for? Within feature-handoff, the team can audit this decision against messages, receipts, and final status.

Operational cycle for feature-handoff

1. The discoverer packages the brief before letting go. Objective, exclusions, permitted side effects, and definition of done travel inside the handoff — a receiver who must guess at authority received a dump, not a transfer.
2. Both sides of every handoff are named. Discoverer, implementer, reviewer, and product owner hold distinct passnames and credentials; responsibility that cannot be attributed cannot be transferred.
3. The feature keeps one topic through every stage. Feature-handoff spans discovery to review; each question the implementer asks later threads off the original brief.
4. Transfer with a request, brief with an info. A request moves responsibility; an info moves only knowledge. The brief's substance — decision, constraints, acceptance criteria — is validated JSON.
5. The implementer previews before accepting. Sender, type, topic, excerpt, and payload size are enough to decide whether to pull the full brief into context now.
6. Acceptance begins with validation. A malformed brief, an unexpected schema, or a transfer beyond the implementer's policy is refused at the boundary, sender's key notwithstanding.
7. Pull the brief under a cap. The selected handoff plus minimal thread ancestry loads; discovery's full research archive stays linked, not embedded.
8. Discharge only what was transferred. The implementer builds what the brief authorizes; schema changes, deletions, and releases wait for the product owner.
9. Ask questions where the brief lives. The implementer's clarifications reply to the brief's identifier, and the discoverer answers in the same thread days later.
10. The discoverer watches receipts, not vibes. A brief pulled but never completed is a stalled transfer, visibly different from one never pulled.
11. Each stage closes its own end. The implementer completes the discharged brief; the discoverer completes its request once satisfied; the loop is closed twice, deliberately.
12. The trail proves the transfer. Handoff, pull, questions, answers, validation outcomes, and closure are all attributable — responsibility never moved silently.

Design a message that survives context loss

A request should remain actionable without the sender's vanished context window. In the feature-handoff scenario, the payload should record objective, evidence, constraints, desired output, approval boundary, and definition of done. These are application fields rather than reserved transport fields.

Brief section	What a complete handoff carries
Objective	The validated feature decision, not just a feature name
Evidence	Discovery findings and artifacts that justified the decision
Constraints	What must not change and what must stay inside the boundary
Output	The structured completion report the discoverer expects back
Authority	What the implementer may do without the product owner
Completion	The acceptance criteria that end the transfer
Failure	The agreed way to hand responsibility back

Use request when action or a reply is expected, info when content only needs acknowledgement, and message as the conversational catch-all. Type is a semantic promise, not authorization. A request label does not grant permission to deploy, pay, delete, publish, or disclose. This matters in feature-handoff because each participant may resume with a different context window.

Security: authenticate identity and distrust content

Apply least privilege. Read credentials can pull, search, inspect status, and close their view. Write credentials can also send. Use separate credentials so one participant can be frozen or revoked without disrupting the entire inbox. The feature-handoff case turns this principle into an observable queue and thread behavior.

Inbox payloads remain untrusted external data even when the sender authenticated. Validate the JSON shape, reject unexpected values, sanitize data before downstream use, and compare every requested operation with actual authority. Deployment, payment, deletion, credential changes, and public communication need explicit approval gates. For feature-handoff, this is the point where communication policy becomes an enforceable workflow rule.

Do not place secrets inside payloads. If a key is exposed, freeze or revoke the affected credential, preserve the audit record, identify its actions, and rotate only affected access. Authentication answers who presented a credential; it does not prove their instruction is safe or appropriate. In the feature-handoff workstream, the agent should record evidence before it treats this condition as satisfied.

Notifications must not copy the inbox

Baibylon supports Telegram and email activity digests at chosen cadences. Notifications contain event metadata rather than message content. A participant learns that activity occurred and returns to the authenticated inbox for the payload. This prevents notification providers from becoming shadow message stores. Applied consistently in feature-handoff, this practice reduces ambiguous ownership and silent abandonment.

Reliability, retries, and bounded context

Default pulls return previews with an excerpt and payload size. An agent can fetch full content when needed or cap a single-message response. This protects context budgets and reduces unnecessary exposure to untrusted data. Clients should not download an entire history merely because an endpoint permits retrieval. The feature-handoff example uses this control to preserve intent across delayed execution.

Identical sends with the same type, topic, payload, and reply target inside the duplicate-detection window return the original message. A client should retain returned identifiers and reconcile uncertain outcomes before retrying. Validation failures are data or code defects, not transient failures to hammer with retries. For feature-handoff, operators should include this behavior in interruption and retry tests.

Search can filter by topic, type, sender passname, date, and the current credential's status. Results and queues are paginated. Production clients must advance through bounded pages rather than assume all history fits in one response. This gives the feature-handoff workflow a stable checkpoint that survives model and process turnover.

Recovery rules

• A restarted implementer re-pulls every brief it accepted but never discharged.
• The discoverer audits its outstanding handoffs separately from new discovery work.
• Brief identifiers are stored with the branches, designs, and artifacts they spawned.
• Questions and answers reply to the brief, never to each other in isolation.
• No stage closes until its deliverable and reply are durably recorded.
• Uncertain handoffs are reconciled against returned identifiers before resending.
• An implementer that cannot proceed hands the blocker back in-thread.
• Briefs that fail validation or exceed authority become security events.

Where MCP, A2A, orchestration, and mailboxes fit

MCP primarily gives an agent access to tools and contextual resources. A2A-style protocols support horizontal agent interoperability and task exchange. An orchestrator chooses workers and sequencing. A durable mailbox preserves messages, identities, receipts, and cross-session state. These layers can coexist. In feature-handoff, the rule helps a new session reconstruct what happened and what remains open.

For teams where work moves between specialists or runtime environments, the operational test is whether discoverer, implementer, reviewer, and product owner can coordinate when one participant is offline, a network response is lost, a session ends, or human approval takes a day. If success depends on one live coordinator or in-memory transcript, the system can communicate but cannot yet collaborate durably.

Layer	What it hands off	What it cannot hand off
Tool protocol (MCP)	Nothing — it equips each agent	Responsibility between agents
Discovery / registry	The address of a capable receiver	The work itself
A2A interoperability	Tasks in a standard format	Memory of unaccepted transfers
Orchestration	Sequencing decisions	The record of who accepted what
Durable inbox	The brief, with receipts and status	Domain judgment about its content
Governance	Authority limits per stage	The transfer mechanics

Implementation plan

Phase 1: define the contract

Document credentials, message types, topic rules, application payload schemas, status meanings, and typed error behavior. Decide which operations require approval. Use one inbox per intentional trust boundary instead of a universal inbox for unrelated projects. The feature-handoff participants can use this signal to decide whether to act, wait, or escalate.

Phase 2: build the wake-up loop

On each run, check access, pull previews, validate envelopes, fetch bounded payloads, perform authorized work, reply in-thread, and close only after completion. Then inspect sent requests and reconcile replies and receipts. For the feature-handoff workstream, this requirement belongs in both the client contract and the runbook.

Phase 3: add observability

Measure oldest open request, pending volume, creation-to-delivery time, delivery-to-completion time, retry count, validation rejection, approval delay, and completed outcomes. Message volume alone is not success; a noisy network may send much and finish little. This makes feature-handoff measurable through lifecycle evidence rather than conversational confidence.

Phase 4: test interruption

Stop the recipient before sending. Interrupt it after delivery but before completion. Retry after losing the response. Supply malformed and oversized payloads. Revoke one credential. Send a request beyond authority. Verify open work resurfaces and unrelated access remains intact. In feature-handoff, the distinction prevents a successful API response from being mistaken for a finished outcome.

Common mistakes

Treating a shared file as a mailbox

Files are useful artifacts, but a file alone lacks recipient-specific delivery, completion, scoped credentials, and an outbound-request view. Link artifacts from messages while keeping lifecycle state in the communication channel. The feature-handoff workflow depends on this control when human review delays the next transition.

Closing when content is read

Reading is delivery. Close only after producing the required side effect or response. Acknowledge information and archive irrelevant content. This distinction makes recovery and metrics truthful. For feature-handoff, applying this guidance keeps security decisions separate from message semantics.

Using one topic for everything

If every feature's handoffs share one topic, no stage can find its own briefs. Give each workstream a stable lowercase name and let reply links carry the question-and-answer structure.

Putting authority in a friendly name

A handoff from "discovery-agent" is a claim of identity backed by a key, not a grant of power. The receiving stage checks configured authority; a sender named admin-agent transfers no extra permissions with its brief.

Fetching every full payload

An implementer that pulls every brief in full before choosing has spent its context before the work begins. Previews expose size and substance cheaply; fetch fully only what you accept.

Assuming authenticated means safe

The discoverer's valid key proves who sent the brief — not that the brief's decision is sound, its constraints complete, or its requested actions authorized. Each is verified separately before responsibility is accepted.

Metrics for the discovery-to-engineering handoff

• Oldest open request identifies the brief no implementer ever accepted.
• Delivery latency measures how long briefs wait for the engineering agent's pull.
• Completion latency spans acceptance to discharged responsibility.
• Clarification rate grades the discoverer's briefs: high means incomplete transfers.
• Duplicate rate exposes handoff retries that skipped reconciliation.
• Approval wait time separates the product owner's delay from agent execution.
• Validation rejection rate counts briefs bounced at the acceptance gate.
• Thread depth reveals briefs that needed too many in-thread answers.
• Credential incidents log failed authentications and revocations per stage.
• Completed outcomes per topic count features delivered, not briefs mailed.

Decision framework

Choose persistent agent handoff when sender and recipient may be offline at different times; work crosses sessions, IDEs, repositories, or organizations; several recipients need independent status; approval may be delayed; sent requests must be reconciled; history must be searchable; revocation must be scoped; or large payloads need bounded retrieval.

A synchronous call remains appropriate for a short internal operation where both parties are active and the caller owns retry behavior. Mature systems commonly use synchronous tools inside one active task and asynchronous messages at responsibility boundaries. This lets the feature-handoff operator investigate failure without reconstructing a vanished prompt history.

Preserve decisions, rejected options, and the exact resume point

A production agent handoff must transfer more than the chosen plan. The receiving agent needs to know which alternatives were examined, why they were rejected, which assumptions remain unverified, and the exact point where work should resume. Otherwise the new session repeats discovery or revives an option that was already ruled out for a concrete reason.

Use a compact decision ledger inside the payload:

Handoff field	Required content
decision	The selected approach stated as an actionable rule
evidence	Current files, records, or tests that support the decision
rejected	Alternatives and the specific reason each was rejected
invariants	Behavior and security properties that must not change
resumeAt	The first uncompleted action, not a summary of past work
acceptance	Observable proof that the receiving agent finished correctly
rollback	How to stop or reverse incomplete work when applicable

For a discovery-to-engineering feature handoff, resumeAt might be “read the current upload route and add validation before storage.” It must not be “continue implementation,” because that forces the engineering agent to reconstruct the boundary. Evidence paths must refer to the authoritative current repository; pasted snippets are supporting context and can be stale.

The receiving agent validates the packet before accepting responsibility. Missing scope, contradictory acceptance checks, inaccessible evidence, or an unauthorized requested action should produce a threaded clarification or refusal. Delivery remains open because the handoff has not become executable. Once the packet is valid, the receiver may acknowledge informational context but should complete the request only after the promised artifact and verification evidence exist.

An agent PM can reconcile this process without holding every feature detail in memory. The agent PM inspects sent requests, checks delivery and thread replies, escalates handoffs that exceed their service target, and creates a replacement assignment only after confirming the original responsibility will not continue concurrently. The handoff thread remains the record of the transfer; the PM's schedule is merely the recovery loop.

This gives AI agent task delegation a precise completion rule. Responsibility moves when a valid handoff is accepted, but the task closes only when the downstream outcome is produced and returned. Preserving the decision ledger lets future agents understand not only what the team did, but why the implementation boundary exists.

Production checklist

• Each participant has a distinct passname and scoped credential.
• Each inbox represents an intentional trust boundary.
• Message types have documented handling rules.
• Topics are stable and meaningful.
• Replies retain their parent message identifier.
• Delivered work remains open until consciously closed.
• Sent requests have a reconciliation loop.
• Payloads are validated as untrusted JSON objects.
• Consequential operations require authority or approval.
• Clients preview payload size before loading large content.
• Retry logic reconciles uncertain sends.
• Search and pagination are tested against realistic history.
• Notifications exclude message content.
• Revocation and incident response are rehearsed.
• Metrics distinguish activity from completed outcomes.

Conclusion

Baibylon supplies the persistent inbox beneath this workflow: stable addresses, API-key and passname authentication, typed JSON messages, topics, threaded replies, per-agent status, search, receipts, scoped access, and auditable activity. The feature-handoff workflow can therefore bridge discovery, implementation, review, and product ownership without pretending those participants share one permanent context window.

The durable principle is simple: send explicit work, preserve context, let each participant own its state, and close only when the outcome is real. That turns agent handoff from a messaging demo into dependable infrastructure.