Background tasks

A peer call normally blocks the calling agent until the peer answers, for at most 10 minutes. For work that takes longer, an agent can hand a task to a peer and let it run in the background. The user can keep chatting, and the answer arrives in the conversation when the peer is done.

Enable background tasks for a peer

On the calling agent’s Connectivity tab, switch on Run tasks in background for the peer in the A2A Peers table. The switch is off by default. The same switch exists for SAP data sources.

The switch is a decision of the calling agent, per peer. Whether the peer itself keeps working after a caller disconnects is a separate setting on the peer, Continue tasks after disconnect.

Background tasks only start from a streaming chat, such as the chatbox component or the Playground. Calls made through non-streaming APIs wait for the peer as before.

How a task moves to the background

The call moves to the background as soon as the peer reports that it has started a task. A peer that only answers with messages, and never creates a task, always runs in the foreground even when the switch is on.

For a peer built in Neptune DXP - Open Edition, this means the peer must have Task & artifact tools enabled, and its instructions should tell it to call create_task before it starts the actual work. The default instructions for agents with task tools already say this. An agent that creates the task after finishing the work never runs in the background.

Once the call is in the background, the calling agent’s turn ends with the status "Working in the background…​". The nested activity panel for the peer stops updating.

What the user sees

Working in the background

The message bubble shows this status and a Cancel background task link. The user can send new messages in the meantime.

Late answer

When the peer finishes, the answer is delivered to the conversation. If the original message is still the last one, the answer fills its bubble. If the user has continued chatting, the answer appears as a new bubble at the bottom with a link back to the original message, and the original message gets an Answered below link.

Needs answer

If the peer needs more information from the user, the bubble shows a Needs answer badge and an inline reply field. The user answers there or in the normal message field. The reply resumes the peer.

Cancel

Cancel background task closes the turn with "Task canceled." and marks the task as canceled. Only the user who started the conversation can cancel it. A task that is waiting for a reply cannot be canceled through this link; answer it instead.

The late answer reaches the browser through the AI socket connection. If the user reloads the page, the conversation shows the pending status again and the answer is delivered when it arrives.

Expiry

A background task that never finishes is cleaned up after 24 hours. The turn is then marked as expired in Agent Trace and the task is canceled. A task that is waiting for a user reply expires the same way.

For peers on another instance, the instance polls the peer every five seconds. When the peer supports push notifications, the instance registers a webhook and the poll interval drops to once per minute as a safety net. Polling stops after 30 minutes at most.

Agent Trace

Background tasks appear in Agent Trace as follows:

  • The log of the turn that started the task has the status paused until the answer arrives, or expired if it never did.

  • On the Steps tab, the sendMessageToAgent step shows the result working-async with the peer, context, and task IDs.

  • On the Artifacts tab, tasks and their artifacts are listed with their state.

  • The peer’s own run is logged on a child thread of the conversation.

Limits

  • A task whose worker process restarts is lost. The turn stays paused until the cleanup marks it as expired.

  • Canceling does not stop a peer that is already running. The peer’s result is discarded when it arrives.

  • Push notifications from a peer on another instance are verified against that instance’s signing keys. If the webhook cannot be reached or verified, the instance falls back to polling.