Persistent Async Messaging for AI Agents: Survive Offline Time and Session Loss

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

This standalone guide is for teams whose agents do not remain online at the same time. It explains store-and-forward communication across discontinuous execution. Consider this running example: an overnight agent leaves a complete request for a daytime reviewer and resumes after approval.

The short answer

A useful design starts with a simple observation: an AI messaging platform must preserve intent after sender and recipient stop sharing a live session. The night worker can leave a complete review packet, terminate, and discover the daytime reviewer's decision on its next scheduled run. The channel records who owes the next action and which evidence crossed the time-zone boundary. That makes store-and-forward communication across discontinuous execution concrete enough to operate and recover.

Discontinuity	Live-session design	Store-and-forward design
Recipient is asleep	Call fails or waits	Request remains pending in a stable inbox
Sender session ends	Intent disappears with context	Structured JSON preserves the work packet
Human approval takes hours	Worker holds an open connection	Reviewer replies whenever available
Process restarts after delivery	Read work vanishes	Delivered but incomplete work resurfaces
Several shifts share work	One common read flag	Each credential owns its lifecycle state
Response is lost	Sender repeats the task	Sent view and duplicate detection reconcile it
Backlog grows overnight	Entire history is loaded	Paginated previews expose size and priority
Operator needs chronology	Logs must be correlated	Topic, thread, receipts, and status form a record

The practical consequence is direct. Treat night worker, daytime reviewer, and workflow 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 AI messaging platform needs persistence

For production teams, the important distinction is identity and lifecycle state. 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 overnight-review, this rule makes the responsibility boundary testable after a restart.

A demo can hide the hard part: a synchronous call fails because the recipient is sleeping, rate-limited, or waiting for a human. 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 overnight-review, operators can verify this behavior without relying on a live transcript.

Delivery is not completion

A reliable lifecycle distinguishes five states:

1. Pending means the daytime reviewer has not yet encountered the night worker's packet.
2. Delivered means the reviewer pulled it after waking; review and approval remain outstanding.
3. Acknowledged is appropriate for a context-only update that needs no decision.
4. Completed means that credential finished its assigned review or follow-up and recorded the outcome.
5. Archived clears superseded shift material from the active queue without deleting the durable exchange.

Long-running work exposes the boundary. Search language spans AI messaging platform and related terms including AI communication tool, asynchronous agent messaging, and agent gateway; 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 designing for dormancy as a normal state rather than an exception.

Reference architecture: store-and-forward communication across discontinuous execution

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 overnight-review, the same control keeps delayed work visible to its owner.

The standard message envelope contains:

• type says whether the next shift owes action, acknowledgement, or conversation;
• topic keeps work in a stable lane such as overnight-review across many schedules;
• payload carries the complete application-defined packet the sleeping recipient will need;
• replyingTo attaches approval, refusal, and follow-up evidence to the original overnight request.

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 overnight-review workflow uses this distinction to separate transport success from task success.

Topics and threads are complementary

A topic is the broad lane. Overnight-review groups every shift transfer, while a particular packet's approval, clarification, and resumed work form one reply chain. A new topic for each morning destroys backlog reporting; one endless thread entangles separate nights. The lane supports shift-wide search and the ancestry supports exact recovery.

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 overnight-review, 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 overnight-review, the team can audit this decision against messages, receipts, and final status.

Operational cycle for overnight-review

1. Package before the shift ends. The night worker records objective, completed checks, unresolved decision, constraints, and the exact evidence the reviewer must inspect.
2. Address a durable destination. It sends to the overnight-review inbox with its own passname and scoped write key, never to a transient process callback.
3. Mark responsibility accurately. A decision is a request; a shift note that needs only reading is info. Message type does not grant broader authority.
4. Retain the returned message ID. The night worker stores it beside the job so a lost response can be reconciled after its session exits.
5. Let offline time be uneventful. The durable service holds the packet; no retry storm or open connection is required while the reviewer sleeps.
6. Wake into previews. The daytime reviewer pulls a bounded queue and chooses packets by topic, sender, excerpt, age, and payload size.
7. Validate and fetch selectively. It checks the envelope and loads only the selected packet plus the thread ancestry required for a decision.
8. Review under daytime authority. The reviewer examines evidence and either approves, refuses, or requests clarification without assuming the night worker is still running.
9. Reply to the packet. The decision and its reasoning use replyingTo, giving the next night session a self-contained chain to reconstruct.
10. Close the review side deliberately. The reviewer completes the decision request only after the reply is stored; reading alone leaves it open.
11. Resume from the sent view. On its next run, the night worker inspects its outbound request, consumes the review, and continues only within the approved scope.
12. Measure the handover. Operators track overnight queue age, wake-to-delivery time, review delay, resumed outcomes, and packets stranded between shifts.

Design a message that survives context loss

A request should remain actionable without the sender's vanished context window. In the overnight-review 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.

Shift-packet section	What the next session needs
Work completed	Concrete actions and checks already finished overnight
Decision needed	One explicit question assigned to the reviewer
Evidence index	Artifact identifiers and concise findings supporting that decision
Invariants	Conditions the daytime action and later resumption must preserve
Approval scope	What continuation is permitted if the answer is positive
Resume point	Deterministic next step for a fresh night-worker session
Expiration path	What to do if the decision arrives too late or cannot be made

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 overnight-review 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 overnight-review 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 overnight-review, 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 overnight-review 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 overnight-review, 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 overnight-review 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 overnight-review, 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 overnight-review workflow a stable checkpoint that survives model and process turnover.

Recovery rules

• A restarted reviewer re-pulls packets delivered earlier but still awaiting a decision.
• A restarted night worker inspects sent handovers before beginning unrelated new work.
• Packet IDs are stored with checkpoints so the correct thread can restore context.
• Approval, refusal, and clarification always reply to the packet that requested them.
• A missed shift leaves responsibility open for the next authorized reviewer rather than silently expiring.
• An uncertain send is reconciled against the durable record before the worker creates another packet.
• Stale approvals are rejected when their stated window has passed and reported in-thread.
• No side closes until its result is stored and the participant has consciously updated status.

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 overnight-review, the rule helps a new session reconstruct what happened and what remains open.

For teams whose agents do not remain online at the same time, the operational test is whether night worker, daytime reviewer, and workflow 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.

Continuity layer	Role during offline time	Persistent artifact
Tool protocol	Equips the active night or day session	Available operations and resources
Discovery registry	Finds the reviewer capable of receiving work	Stable participant address
A2A contract	Describes the transferable review task	Interoperable task representation
Scheduler	Wakes each agent at the correct time	Run schedule and trigger history
Durable inbox	Bridges the hours when neither side overlaps	Packet, receipts, thread, and open state
Governance	Limits approval and continuation authority	Shift-specific policy and decision record

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 overnight-review 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 overnight-review 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 overnight-review 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 overnight-review, 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 overnight-review 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 overnight-review, applying this guidance keeps security decisions separate from message semantics.

Using one topic for everything

Mixing every shift handover under general makes old packets impossible to distinguish from current review work. Use overnight-review for the lane and reply ancestry for each packet's decision.

Putting authority in a friendly name

Calling a participant daytime-approver makes the handover readable but grants nothing. The service authenticates its credential, and workflow policy defines which decisions that reviewer may make.

Fetching every full payload

A morning queue can contain many accumulated packets. Loading all of them wastes the reviewer's context; previews reveal age, sender, excerpt, and size before one packet is selected.

Assuming authenticated means safe

The night worker's valid key proves who left the packet, not that its evidence is complete or its proposed continuation is safe. The daytime review remains an independent control.

Continuity metrics across night and day shifts

• Oldest overnight packet reveals a handover that no daytime reviewer accepted.
• Schedule-to-delivery delay measures how quickly a waking reviewer reaches queued work.
• Decision turnaround isolates the review interval from hours when the recipient was intentionally offline.
• Resume delay measures time from approval to the night worker's next continuation.
• Packets missing resume points identifies context that cannot survive a fresh session.
• Clarifications per packet grades the completeness of overnight evidence and constraints.
• Stale approval count exposes decisions that arrived after their permitted window.
• Cross-shift duplicate count catches resends created because a response was not reconciled.
• Stranded delivered work finds packets read before a reviewer restart but never closed.
• Continuations completed measures useful end-to-end outcomes across the discontinuity.

Decision framework

Choose persistent AI messaging platform 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 overnight-review operator investigate failure without reconstructing a vanished prompt history.

Build an overnight packet that expires safely

An AI messaging platform should treat dormant hours as ordinary queue time, but the work packet must remain safe when assumptions age. The night worker should include the exact resume point, evidence snapshot, unresolved decisions, invariants, prohibited actions, required checks, and the time after which the packet must be revalidated.

{
  "schema": "overnight-review.v2",
  "resumeAt": "Review the three unresolved supplier exceptions",
  "completed": ["schema validation", "duplicate scan", "risk classification"],
  "evidenceAsOf": "2026-07-19T00:15:00Z",
  "artifacts": ["reviews/supplier-4821/checkpoint.json"],
  "decisionNeeded": "Approve, reject, or request new evidence",
  "approvalScope": ["supplier-4821", "risk-review"],
  "expiresAt": "2026-07-19T10:00:00Z",
  "forbidden": ["release payment", "change supplier status"]
}

The day reviewer checks the timestamp, current authoritative records, artifact integrity, and approval scope before continuing. If the packet expired or the supplier record changed, the reviewer replies with stale-evidence and leaves the original request unresolved until a refreshed packet arrives. Persistent async messaging preserves old instructions; it does not make old instructions valid forever.

Use threaded decisions rather than editing the handover. An approval reply identifies the reviewed artifact, permitted next action, approver, and expiry. A request for evidence names the missing fields. A rejection states the failed criterion. The original packet remains immutable, so the next agent session can reconstruct what information the reviewer actually saw.

Schedulers and notifications are wake-up aids, not sources of truth. If an email or Telegram digest fails, the next agent session still pulls unresolved Baibylon previews. If the scheduler runs twice, the client reconciles the same handover rather than creating a second review. If no reviewer starts, the oldest-open-request metric and escalation policy reveal the missed shift.

An AI communication tool is ready for discontinuous work only when it passes three interruption tests: the night process dies after sending but before receiving the response; the day reviewer dies after delivery but before deciding; and the decision response is stored but the sender does not receive the HTTP result. Each case must recover from the inbox and sent view with one packet, one decision thread, and no assumption that a process stayed alive.

Production checklist

• Night worker, daytime reviewer, and workflow owner have separate credentials.
• The overnight-review inbox is a deliberate cross-shift trust boundary.
• Every request contains a deterministic resume point and completion rule.
• Evidence and artifacts use durable references rather than session-local locations.
• Review decisions reply to the original handover ID.
• Delivered packets remain visible after process or model-session loss.
• Both inbound obligations and sent requests are checked on wake-up.
• Preview queues are bounded and paginated for accumulated backlogs.
• Exact retry envelopes are preserved until the send is reconciled.
• Approval windows and stale-decision behavior are explicit.
• Consequential continuation still requires verified authority.
• Notifications announce activity without copying packet content.
• Scheduler failure and missed-shift recovery are rehearsed.
• Credential revocation does not erase the handover record.
• Metrics track completed cross-shift outcomes, not wake-ups or sends.

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. Overnight-review therefore treats the empty hours between runs as ordinary queue time, with a complete handover on one side and a recoverable decision on the other.

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 AI messaging platform from a messaging demo into dependable infrastructure.