Conversations, tasks and files

​

Sending a message

Every message you send is one turn of the conversation. Xpander Chat opens a stream and shows the turn as it happens: your message as a bubble, the agent’s text as plain paragraphs streamed token by token, and each skill call as a collapsed row (a chevron, the skill’s icon and its title) you can expand into Summary (what it asked, what came back) or Full (the raw call). The conversation keeps the whole thread. The turn runs on xpander, not in your browser. Closing the tab, a deploy or a network drop does not stop it. If the stream breaks, Xpander Chat polls the run’s state for half a minute and then tells you the reply is saved in the thread. Turns in one conversation run one at a time. A second message sent while a turn is running is steered into it: it reaches the agent at its next skill boundary and shows in the thread as a steering message, so a correction lands in the work in progress instead of waiting for it to end. From Slack the steered message gets an eyes reaction; from WhatsApp and Telegram it is silent. With nothing running, a message starts the next turn.

​

Sub-tasks

An agent can hand part of the work to another agent as a sub-task: a separate execution with its own record, listed under the conversation and in the Task Manager. The agent decides whether to wait for it or let it run on when it creates it. The API’s sub-task mode (sync, async or auto) says how the agent’s own sub-tasks run inside the turn: inline, queued, or the agent’s per-task choice. A sub-task that runs on reports into the conversation when it finishes, and a sub-task never fans out background sub-tasks of its own. Turns from Slack, Teams, WhatsApp and email are created with the inline mode, so the channel reply is the whole answer. Omni, the built-in agent, is an agent like the others: asking it to task another agent creates that agent’s own conversation, and the result comes back into Omni’s thread.

​

Where the work runs

Every turn runs in a sandbox in the location the agent belongs to: xpander’s cloud, or a self-hosted location your organization connected (see Locations). Model calls leave through xpander’s LLM proxy; skill calls go to the controller, where the credential is attached and the call is recorded. The mechanics are on Agents and conversations.

​

Uploading a file

Attach a file in the composer, up to 50 MiB. Two things happen:

1. The file is stored in the file store for your organization, and its link is part of the message.
2. It is copied into the conversation’s working directory under uploads/<name>, so the agent reads it as a file. When the copy fails you are told the agent will read it from the link instead. Images and documents are also handed to the model directly when the model accepts them.

Anyone who can open the conversation can see the upload. On an org-wide agent, the default, that is every member of your organization; on a restricted agent, you and the agent’s owner. The working directory belongs to the conversation, so another conversation of the same agent does not see it. See who can see a conversation.

​

Results and the files an agent produces

The conversation shows the answer; the task panel shows the files created or changed, token usage and cost. Files live in the conversation’s working directory, browsable in the Computer view, where you can open, edit, upload and download them. Hidden entries are dimmed, and credential stores such as .aws, .ssh and .kube never appear. Share on a file mints a link with an audience: Just me, My org (anyone in the organization with the link), or Public (anyone on the public internet with the link) where an admin allows public links under Settings > Sharing. A link the agent shares on its own is public unless public sharing is off for the organization. Make live on a document the agent produced turns it into a live surface the agent keeps updated on each run.

​

The task record

Every conversation and every sub-task is a task with the same record; a conversation’s record carries the latest turn’s status and result, and its thread holds every turn’s messages and skill calls. Conversations recorded before September 2026 (conversation_kind: gateway) are read-only; start a new conversation with the agent to continue. Every task has:

• status: pending, executing, paused, error, failed, completed or stopped
• the messages
• every skill call, with its parameters, result and the credential it used
• held approvals and their decisions
• files, tokens and cost
• the model that ran it

Task Details summarizes it. The execution log lists every action. GET /v1/tasks/{task_id} returns it, /thread its messages, /llm_usage its model calls. A failed action shows a readable line with the raw error text kept alongside it. Failures on xpander’s side show as Budget limit reached, Out of credits, Quota reached or Account blocked, not as a stack trace. More on Audit and debugging.

​

Continuing later

A conversation can be reopened at any time. The next message resumes the harness session where it stopped or, when the session is gone, starts a new one with the conversation history handed over. The working tree of a conversation idle for 14 days is removed; the record stays. Switching harness mid-conversation keeps the conversation: the new harness receives the transcript, all of it the first time and only what it missed afterwards, at the top of the next message.

​

Working together

Several people can write in the same conversation when they have access to the agent. Every message carries its author’s name, and every action is recorded under the person who asked. Share conversation gives others a read-only view: your organization, named people or groups, or a public link where allowed. Allow replies lets a viewer continue in a copy of their own; the original is untouched. For a live room where people and several agents are equal members, with one transcript and one shared set of files, your organization can enable shared sessions; see Shared sessions.