# Keep Personal Agent Tasks Running After the Call Ends

Keep personal agent tasks running after a voice call with app\-owned jobs, honest status, safe retries, and recoverable context in Realtime Avatar\.

Published: 2026-10-12T14:37:32.962Z
Updated: 2026-10-12T14:37:32.962Z
Canonical: https://realtimeavatar.ai/blog/personal-agent-background-tasks-after-call
Markdown: [en](https://realtimeavatar.ai/blog/personal-agent-background-tasks-after-call.md)

To keep personal agent background tasks running after a voice call, persist the request in your application before acknowledging it, execute it independently of the call, and let the user retrieve its status later. Realtime Avatar supplies the conversation, not a durable task runner. Your backend owns the work, permissions, retries and evidence of completion. The architecture below is a recommended application pattern, not a set of shipped RTA job-management features.

## Make the short tool call accept work, not perform it

RTA client tools have a 2.5-second deadline. Cancellation is cooperative: a handler that ignores its AbortSignal can continue and commit a side effect even after its result is discarded. A research task should therefore use the live tool to submit a job, not wait for research to finish. Closing the browser must not remove the only process responsible for completing it.

Validate the request and authenticate its owner, then atomically save the task and a dispatch record for your worker. A transactional outbox, where a dispatcher reads committed work from the database, avoids saving a task that never reaches the queue. Return its identifier only after that commit. If persistence cannot be confirmed within the deadline, do not say the work was accepted.

RFC 9110 defines 202 Accepted as accepted for processing, not completed; processing might never happen. It also recommends describing current status and pointing to a status monitor. Use that distinction in your application's response and spoken acknowledgement. An HTTP status alone neither persists a job nor guarantees execution.

- [RTA tool calling: execution ownership and cooperative cancellation](https://realtimeavatar.ai/docs/tool-calling)
- [RFC 9110, section 15.3.3: 202 Accepted](https://www.rfc-editor.org/rfc/rfc9110.txt)

## Example: research a replacement air-purifier filter

Suppose a user says, 'Find the correct replacement filter for my air purifier and compare two current offers. Don't buy anything.' Save the deliverable as research only: manufacturer compatibility evidence, seller links, prices with checked-at times, and unresolved questions. Set a research budget and deadline in your application; neither a long call nor an open-ended worker should determine how much research gets purchased.

After committing the task, the avatar can say, 'Your filter research request is saved. You can close this call and check its progress in Tasks.' That Tasks view is something your app builds. The worker then discovers that the supplied product name identifies several models. It must stop guessing and request the exact model number.

Show a concrete handback: 'When convenient, read the model number from the exterior label without opening the appliance, then enter it here.' Assign the next action to the user and mark needs-input. This illustrative JSON is an application record, not an RTA wire schema or executable SDK example.

```
{
  "taskId": "filter-research-184",
  "ownerId": "signed-in-owner",
  "operationKey": "filter-request-original-184",
  "revision": 4,
  "state": "needs-input",
  "permission": "research-only",
  "nextActor": "user",
  "missingInput": "Exact model number from exterior label",
  "resultReference": null
}
```

When the user supplies the number, resume the same task with a new revision. Compare manufacturer evidence against listings; label unverified compatibility instead of inventing certainty. Completion means the requested comparison is saved and inspectable. It does not mean a filter was purchased, delivered or installed. If two verifiable offers cannot be found, report the gap rather than silently narrowing the deliverable.

## Give each task state an evidence requirement

Keep task status separate from RTA call status. For this application, use the following vocabulary and require backend evidence before changing it.

- Accepted: the validated task and dispatch intent are committed. No research result is implied.
- Running: a worker owns a time-limited lease and records progress. A stale heartbeat calls for recovery, not an indefinite spinner.
- Needs-input: work is paused for a specific answer or physical action. Show who must act and what will unblock it.
- Confirmed: the defined research deliverable is durably saved, with source links and limitations. This is not purchase authorization.
- Failed: a known error or exhausted budget prevents completion. Preserve partial findings and explain what remains undone.
- Unknown: available evidence cannot establish an operation's outcome. Reconcile it before declaring success, failure or a safe retry.

A2A provides a useful protocol reference: its specification separates submitted, working, input-required and terminal task states, and describes polling, streaming and push updates. These support long-running interactions without requiring one continuous connection. Our vocabulary above is application-specific; it is not A2A's wire enum, and this design does not imply a native RTA–A2A integration.

- [A2A specification: task states and update delivery mechanisms](https://a2a-protocol.org/latest/specification/)

## Failure matrix: recover without duplicating the work

Use a stable operation key for the original request, scoped to the authenticated owner. Enforce uniqueness in storage and reject reuse with changed arguments. A reconnect or retry should retrieve that task, not create another research job. Treat the following cases as integration tests.

- Commit succeeds; acknowledgement is lost. Look up the original operation key and return the existing task. The caller's timeout is not evidence that nothing was saved.
- Queue delivery repeats. Claim work conditionally under a lease. Use a revision or fencing token so an expired worker cannot overwrite a newer result.
- Worker crashes during a lookup. Resume from durable checkpoints. Retry read-only requests within a bounded budget; avoid rerunning every completed step.
- A metered research service accepts work; its response is lost. Mark that operation unknown and reconcile using its request reference or supported idempotency mechanism before paying for another run.
- Result is saved; notification fails. Retry notification separately. Keep the task confirmed and its result available in the app; notification delivery is not the research outcome.
- Compatibility evidence conflicts. Preserve both sources and request clarification. Do not convert an ambiguous listing into a confirmed match just to finish the task.

## Reconnect from saved facts and recheck permission

On return, authenticate the user and fetch their current task record. Show its revision, last verified update and next action. When starting another RTA call, your server supplies instructions and a compact context snapshot from that record. A new session does not automatically inherit durable memory. Keep credentials and unrelated history out of the snapshot; treat retrieved page text as evidence, never execution instructions.

Recheck authorization before each external operation, not only at job creation. If access is revoked, stop future dispatch and request cancellation where supported. Do not promise that revocation undoes work already sent. Reconcile in-flight operations; mark failed with a revocation reason only when the outcome is known and no further authorized work can proceed.

## Frequently asked questions

### Does ending the call cancel my background task?

Not in this design. Call lifetime and job lifetime are separate. Offer a distinct Stop task control backed by your worker's cancellation behavior, and explain whether it stopped execution or merely requested a stop.

### Can the transcript webhook be my task queue?

No. Optional transcript delivery occurs after the call and is not an authoritative execution receipt. Persist tasks when accepted. Private session diagnostic logs can contain conversation text and have a separate 30-day storage lifecycle; disabling transcript delivery does not establish zero retention.

### Must users start another call to receive results?

No. Provide an authenticated task page and an optional notification through your application's delivery system. Another call can explain the saved comparison, but reading the result or supplying a model number should not require keeping an avatar session open.

### Can my background agent replace the live voice pipeline?

That is a different integration. RTA manages speech recognition, the language-model response, speech synthesis and video. External language-model endpoints require workspace approval and a host allowlist. The public SDK does not accept arbitrary live audio from your own text-to-speech service.

## Start with one recoverable research task

Build the task record and result page first, then connect the call. Test closing the browser after acceptance, losing the acknowledgement and revoking access during execution. The useful outcome is an inspectable result that survives disconnection, not a longer conversation.

- [RTA Calls: server-owned policy and context](https://realtimeavatar.ai/docs/sessions)
- [The broader personal-agent interface idea](https://realtimeavatar.ai/blog/give-your-personal-agent-a-face)