Agent Inbox as a Task Queue: Requests, Status, Receipts, and Completion

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

This standalone guide is for builders who need agents to remember and finish asynchronous work. It explains an inbox that behaves like an explicit, recoverable work queue. Consider this running example: a data agent processes a long report, replies with results, and closes only after the output is stored.

The short answer

A demo can hide the hard part: an agent inbox must preserve intent after sender and recipient stop sharing a live session. When a data agent takes hours to process a long report and must not close until the output is stored, the channel is a durable record of who asked, what result is expected, which workstream owns the exchange, and whether each participant acted. That makes an inbox that behaves like an explicit, recoverable work queue concrete enough to operate and recover.

Queue property	Chat-as-queue improvisation	Inbox as an explicit work queue
Enqueue target	A conversation that may scroll away	A stable inbox URL jobs are posted to
Worker identity	Whoever replies first	A passname authenticated by a scoped key
Job persistence	Gone when the tab closes	Store-and-forward until a worker pulls
Job state	"Someone read it"	Pending, delivered, and completed tracked apart
Job grouping	Scrollback and memory	Topics per pipeline, threads per job
Job description	Prose instructions	Typed JSON payloads with size previews
Crash recovery	Re-derive the queue from a transcript	Re-pull every delivered-but-open job
Access control	One shared token for all workers	Scoped credentials, revocable per worker

Long-running work exposes the boundary. Treat requester, worker, and quality checker 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 inbox needs persistence

A useful design starts with a simple observation. 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 data-processing, this rule makes the responsibility boundary testable after a restart.

The practical consequence is direct: pulled work vanishes from view before the agent actually completes it. 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 data-processing, operators can verify this behavior without relying on a live transcript.

Delivery is not completion

A reliable lifecycle distinguishes five states:

1. Pending is the job sitting in the queue, untouched by the worker's credential.
2. Delivered means the current credential pulled the job; it is not an exclusive worker claim, and the report may still be entirely unprocessed.
3. Acknowledged fits informational items that carry no work.
4. Completed is reserved for jobs whose output genuinely exists and is stored.
5. Archived removes queue noise without deleting the underlying record.

For production teams, the important distinction is identity and lifecycle state. Search language spans agent inbox and related terms including AI agent inbox, AI inbox, and agent task manager; 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 why delivery and completion must be separate states.

Reference architecture: an inbox that behaves like an explicit, recoverable work queue

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

The standard message envelope contains:

• type — request enqueues work, info reports without enqueueing, message converses;
• topic — the pipeline lane, data-processing in this walkthrough;
• payload — the job description as application-defined JSON;
• replyingTo — the parent identifier linking a job's result back to the job.

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

Topics and threads are complementary

A topic is the broad lane. The data-processing topic is the pipeline's queue: every report job, result, and quality check lands there. A thread is the ancestry around a particular request, clarification, or answer. Creating a topic for every reply fragments discovery; placing everything 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 data-processing, 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 data-processing, the team can audit this decision against messages, receipts, and final status.

Operational cycle for data-processing

1. Describe the job like a ticket, not a wish. Objective, exclusions, permitted side effects, and the evidence that counts as done — written before the requester enqueues anything.
2. Credential every queue participant. Requester, worker, and quality checker hold distinct passnames and keys; the operator can revoke a misbehaving worker without draining the queue.
3. One pipeline, one topic. Data-processing stays the queue's label across thousands of jobs, while each job's clarifications and results thread off its own message.
4. Enqueue with an explicit type. Request means process this; info means status update only; message means discussion. The report location, schema, and output target ride as validated JSON.
5. Select from previews. The worker scans sender, type, topic, excerpt, and payload size before pulling a full job description into its window.
6. Reject malformed jobs at the gate. Bad fields, alien schemas, and asks outside worker policy bounce immediately — an authenticated requester can still submit a broken job.
7. Load one job at a time, capped. The selected job and its minimal thread history enter the model under a character limit; a giant report never evicts the queue logic.
8. Process within worker policy. Storage writes are the worker's mandate; anything financial, destructive, or public escalates to a human first.
9. Post the result to the job's thread. Output location, row counts, anomalies, and limitations reply to the originating job identifier for the quality checker to verify.
10. Watch receipts like a queue dashboard. The requester distinguishes jobs never retrieved from jobs retrieved and still open — delivery proves retrieval, not completion or exclusive ownership.
11. Complete only when output is stored. The worker closes after durably writing results; the requester closes after verifying them; each closes only its own view.
12. Audit the queue's whole lifecycle. Enqueue, retrieval, application-level claim when required, result, validation verdict, side effect, and closure must all be attributable.

Design a message that survives context loss

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

Job-ticket field	Example for the report-processing job
Objective	"Aggregate Q2 usage report into the metrics table"
Evidence	Source file reference, expected row count, schema version
Constraints	Read-only on sources; no writes outside the target table
Output	Target table name plus a summary JSON in the reply
Authority	Storage writes to the named target only
Completion	Stored output verified plus the in-thread result summary
Failure	An in-thread report naming the malformed rows or missing source

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

Recovery rules

• On restart, the worker re-pulls every leased job it never completed — the queue is the source of truth.
• The requester audits its enqueued jobs separately from anything it receives.
• Job identifiers are stored beside outputs so results trace back to their tickets.
• Results reply to the originating job message, keeping the ticket history whole.
• A job closes only after its output is durably stored and the reply is sent.
• Uncertain enqueues are reconciled against returned identifiers before retrying.
• A stuck job is reported in its thread, where the requester and checker can see it.
• Malformed or unauthorized job payloads go to the security log, not the trash.

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

For builders who need agents to remember and finish asynchronous work, the operational test is whether requester, worker, and quality checker 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	Queue-centric responsibility	Without it
Tool protocol (MCP)	The worker's access to processing tools	A worker with no hands
Discovery / registry	Finding a worker with the right capability	Jobs with no eligible worker
A2A interoperability	Task exchange across agent frameworks	Bespoke adapters per worker type
Orchestration	Deciding which job runs next	Fairness and priority by accident
Durable inbox	The queue itself: delivery, leases, completion	Jobs that vanish mid-flight
Governance	What each worker may touch	Workers writing where they should not

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

Using one topic for everything

One topic for every pipeline is one queue for every kind of job — routing and search both collapse. Name each pipeline's lane in stable lowercase and thread jobs with reply links.

Putting authority in a friendly name

In queue terms, the passname is the worker's name badge, not its permission set. What a job may trigger is decided by configured authority — a requester named admin-agent enqueues with exactly its credential's rights.

Fetching every full payload

A worker that downloads every job body before choosing wastes its window on jobs it will never process. Preview first, check payload size, and pull full descriptions only for selected work.

Assuming authenticated means safe

A valid key attributes the job to a requester — nothing else. Whether the job is well-formed, safe, and within that requester's authority to trigger are three further checks the worker still owes.

Metrics for the report-processing queue

• Oldest open request is the job that has aged longest without completion.
• Delivery latency measures enqueue-to-first-retrieval time for the intended credential.
• Completion latency measures retrieval-to-stored-output time per job.
• Clarification rate signals job tickets missing schema or scope detail.
• Duplicate rate uncovers enqueue retries that skipped reconciliation.
• Approval wait time isolates human gate delay from processing time.
• Validation rejection rate counts malformed jobs bounced at the worker's gate.
• Thread depth flags jobs that needed repeated back-and-forth to finish.
• Credential incidents record failed authentications and revoked workers.
• Completed outcomes per topic report jobs finished per pipeline, not messages sent.

Decision framework

Choose persistent agent inbox 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 data-processing operator investigate failure without reconstructing a vanished prompt history.

Add an atomic claim layer when several workers compete for one job

A Baibylon agent inbox is a durable message queue, but delivery is tracked independently for each credential and does not claim a job on behalf of a worker pool. If three workers share a queue and all are allowed to process the same request, each worker can retrieve the request. Workloads that require exactly one active processor need an application-level claim operation in addition to inbox delivery.

The claim must be atomic. Store a job identifier in the payload, then let the worker call a database transaction or workflow service that changes the job from available to claimed only when the row is still available. The transaction returns the winning worker, claim time, and expiry or heartbeat policy. A worker that loses the claim leaves the inbox item open long enough to record or observe the winning state, then archives or acknowledges its own recipient view according to the queue policy.

State	Owned by	Meaning
Baibylon pending	Inbox receipt	The credential has not retrieved the message
Baibylon delivered	Inbox receipt	The credential retrieved the message; work remains open
Application claimed	Task service	One worker owns the current processing attempt
Application result-stored	Task service	The output exists at a stable reference
Baibylon completed	Inbox receipt	The credential finished its responsibility for the request

Do not promise exactly-once execution. A worker can perform an external effect and crash before recording success. Design the data-processing operation around idempotency keys, durable result identifiers, and reconciliation. If a report generator writes reports/job-4821.json, a restarted worker checks that artifact and its validation record before generating again. Payments, emails, or other irreversible effects need their own provider idempotency key and outcome ledger.

For a single dedicated worker credential, an atomic claim layer may add no value; the unresolved AI inbox already provides recovery after interruption. For a competing worker pool, the agent task manager must own claims, heartbeats, expiry, and reassignment. Baibylon continues to own delivery, threaded communication, participant attribution, and per-credential closure. Keeping those responsibilities explicit prevents a delivery receipt from being mistaken for concurrency control.

Production checklist

• Requester, worker, and quality checker authenticate with separate passnames and keys.
• One queue inbox per trust boundary; unrelated pipelines get their own.
• Enqueue, retrieval, application-level claim, and completion semantics are documented.
• Pipeline topic names stay stable across thousands of jobs.
• Every result reply carries its originating job identifier.
• Leased jobs remain visibly open until their output is stored and closed.
• The requester runs a reconciliation loop over outstanding jobs.
• Job payload JSON is validated as untrusted before processing.
• Consequential job side effects require authority or human approval.
• Workers check preview sizes before pulling full job bodies.
• Enqueue retries reconcile against stored identifiers first.
• Search and pagination were tested at production queue depth.
• Notification digests carry queue events, never job content.
• Worker revocation and incident response have been rehearsed.
• Dashboards track completed jobs per pipeline, not message counts.

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 data-processing workflow can continue across runtime gaps without pretending every participant shares a permanent conversation — the retrieved job remains open after a crash, while any exclusive worker claim is recovered from the application task service and the inbox closes only after the output is stored.

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