Work history

History is where you review what agents have already done. It is the operational record for runs, waiting items, notifications, and failures.

What Work History is for

Use History when you want to:

• check whether a task is still running
• review a completed result
• respond to a request for human input
• isolate notifications or digests
• follow work that moved between agents

Open History

Choose Work > Operations from the left sidebar. The Work group gathers what your agents produce — Operations (their runs), Presentations (their decks) and Files (their outputs and your uploads) — and the Work hub page shows the three at a glance.

Operations opens on its Executions tab, which is the run history described in this chapter. The other tabs — Background Tasks, Work Items, Shared State, Worksets — cover the delegations, durable work items, cross-run state and corpora your agents coordinate through. The last one, Workspaces, lists the environments that group conversations and keep that coordination apart per topic (see Workspaces). An agent builds a workset when it carries the Workset built-in tool, chosen in the Built-in Tools card of its configuration: on an assignment the corpus belongs to that assignment and the person it runs as, and is kept between its runs; in a chat each agent has its own corpus, one per person and per workspace. A company-managed agent's chat corpus is itself company-managed, so whatever you add through that chat is listed in Worksets for every user, just like the work items and shared state such an agent produces. Its automatic summaries stop at a call budget per corpus, after which the agent has to write the missing ones.

Note

Agents chatted with before each one got its own corpus wrote into a single shared corpus per person. That older corpus is no longer read by chats; it stays listed under Worksets until you delete it.

Work items and shared state written by a company-managed agent are company-managed: everyone who can use that agent sees them, and they are read-only for everyone else. Only company-managed agents (whoever they are working for) and administrators can change them, claim them or delete them; a company-managed flow can also claim and settle the company-managed work items its work-item trigger picks up. Your own agents and flows can read them but not change them, and on these tabs only an administrator can resolve, complete or delete a company-managed entry, including one created while you were chatting with a company-managed agent.

A company-managed agent can narrow this for what it produces: its Coordination access, in the Built-in Tools card of its configuration, says which agents can read and which can change the work items it creates and the shared state it owns - everyone and every company-managed agent (the default), selected company-managed agents, or only itself. An agent that can change them can always read them, and the agent a work item is assigned to, and the agent that claimed it, can always work on it. An agent left out of an entry never sees it, so two groups of agents narrowed to themselves can each use the same key for their own entry. The setting applies at once to what the agent already created. It only concerns agents: these tabs show the same rows as before, and administrators keep full access.

Reading a work item

Each row of the Work Items tab names the agent that owns the item (the one expected to act on it), the agent that created it, the chat, assignment run or flow run it came from, and the person it acts for. An agent that is not shared with you is shown as an agent you cannot open, never by name, and so is a run or a chat you cannot open. Filter the list by owner agent with the picker next to the status filters.

A badge says what will act on the item:

• Picked up automatically: an inbox (an assignment or a flow triggered by work items) drains the owner agent's queue and takes the item within about a minute. Picked up once due is the same for an item with a due date still to come.
• No automatic pickup: no inbox drains the owner agent's queue, so the item waits until someone asks that agent to process its work items, or completes it by hand.
• Not picked up: filtered out: the owner agent has an inbox, but its minimum priority or correlation key prefix leaves this item out.
• Unassigned: nothing picks it up: no owner agent is set.
• Being worked on and Blocked: not picked up: an agent holds the item, or it was blocked, for example after repeated failed dispatches.

Open a row for the full picture: why you see the item (yours, company-managed, or filed in a workspace you can see), each inbox with whether it takes the item, the full description, result and payload, its timeline, and when the retention sweep would cancel an item nobody picks up or delete a finished one.

Mark done and Cancel work item ask for confirmation and let you record what was done, or why it is no longer needed. Put back in the queue reopens a claimed, blocked or finished item with its claim and failed dispatch attempts cleared, so an inbox can take it again. Items created before this view existed show no origin: it was not recorded then.

The Executions tab shows runs across your visible agents. It is designed for filtering first and investigation second.

Use the main filter tabs

At the top of the page, XTM One provides quick filter tabs.

You can switch between:

• All
• Notifications
• Digests
• Running
• Awaiting Input
• Completed
• Failed

These tabs are the fastest way to narrow the page to the type of work you care about.

Use the other filters

In addition to the main tabs, you can refine the list with:

• search
• ownership
• agent selection

Ownership usually includes:

• All
• My Runs
• Shared Runs

This is useful when you work in a shared environment and only want to focus on your own workload or on cross-team runs.

Understand the run cards

Each run card gives you a quick status summary.

You may see:

• the agent name
• the assignment or run title
• a short summary
• the current state
• the creation time
• delegation indicators

Typical states include:

• running
• awaiting human input
• completed
• failed
• cancelled — a run cut by the emergency stop carries the cause Stopped by an emergency stop.

Notifications and digests

The Notifications and Digests filters are there for communication-oriented runs.

Use them when you want to:

• review automated updates sent by the platform
• separate digest-style outputs from normal task runs
• find communication outputs without scanning every run

When a run is waiting for you

Some runs pause and ask for human input.

When that happens:

• the run appears under Awaiting Input
• the run detail page shows the question or pending action
• you can respond directly from the run
• you can dismiss the waiting item if it is no longer needed

This is the main place where human approval or clarification appears in the UI.

When an integration resource goes missing

An assignment can keep pointing at something its integration can no longer see - a Notion database that was deleted, moved, or is no longer shared with the integration. A single miss can be a typo in one run, so it changes nothing. When the integration reports the same resource missing in two separate runs, the platform treats it as the assignment's configuration:

• the run that used it again is marked failed with the cause Integration resource missing, and its error names the resource and the integration; whatever the agent produced stays in the result
• the assignment owner gets one notification when this starts, not one per run
• after a few consecutive scheduled runs like this (three by default), the assignment is paused; the assignment page shows why, and Resume switches it back on

To fix it, share the resource with the integration again, or update the assignment so it no longer uses it, then resume the assignment. Resuming starts a fresh count, and a scheduled run that succeeds ends the episode. Only a resource the agent used counts: an id it only read along the way - the target of a relation, a child block, a search result - never fails a run.

When an assignment's owner is deactivated

While an administrator has disabled the account that owns an assignment, nothing starts that assignment unless it is company-managed - an assignment whose agent is shared with a group or a person pauses too: not its schedule, webhooks, integration events or work items, not a chained assignment or a retry, not a flow step, and not a manual run, whoever asks - an administrator included. The assignment page and the agent's assignment list show it as paused because its owner's account is deactivated.

• nothing about the assignment itself changes: its own on / off switch and any pause its owner set are kept, so re-enabling the account resumes it exactly as it was, and a schedule that came due meanwhile runs once, as after a resume
• a run that was already waiting to start (a delayed run, a queued webhook delivery, a retry) is marked skipped with the reason when it would have started; a run in progress finishes, but one that stopped to wait (for a partner's answer, for example) is marked skipped - stopped before resuming - when it would go on
• a webhook delivery to it is answered ignored with the reason; a question it asked stays pending until the account is back (dismissing it still works)
• company-managed assignments are not affected: they keep running even when the administrator who created them is deactivated
• to keep one running while the account stays disabled - a shared agent other people rely on, for example - an administrator transfers its agent to an active owner or makes the agent company-managed

Open a run detail page

Click any run to open the detailed view.

The run detail page usually includes:

• the run title
• the status
• the agent
• the trigger that started the run
• timestamps for created, started, and completed states
• shortcuts to the related agent, assignment, or parent run

Review the result

For completed runs, the detail page helps you understand what happened.

Depending on the run, you may see:

• a final summary
• tool actions
• intermediate reasoning or step history
• output sent to another system
• child runs created through delegation

This makes the page useful both for everyday checking and for troubleshooting.

Rate the result

Once a run has completed or failed, the Result card asks Was this result useful? with a thumbs up and a thumbs down, like the buttons under an answer in the chat. A thumbs down lets you say what went wrong. Your rating is yours: rating again replaces it, and clicking the thumb you chose removes it.

The same rating is offered wherever an agent's work can be read: on a finished background task that was started from a chat (in Operations > Background Tasks; a task started by an assignment is rated on its run page), and on the answer an agent gave when another agent consulted it for you, in the agent's Delegations tab (a background task is rated as the task or its run, and a transferred conversation in the chat, so the same work is never rated twice). The people who manage the agent see every rating in its Feedback tab, with a link to the rated run or conversation when they may open it.

When your administrators have defined feedback criteria (Settings > Quality), the dialog also asks you to score each of them, such as the accuracy of the answer on a scale of 1 to 5 or its tone. Score what matters to you and skip the rest: a thumb alone is still a complete rating.

Follow delegated work

One run can create more runs if work is handed to another agent.

Use the history list and the detail page together to understand:

• where the work started
• whether another agent took over
• which parts succeeded or failed

This is especially important in environments that use multi-agent flows.

Bulk actions

The history page also supports selection and cleanup actions.

Depending on your permissions, you may be able to:

• select multiple visible runs
• delete selected runs
• select all runs matching the current filters

Bulk actions are useful when you need to clean up large sets of test runs or old operational records.

Administrator-only cleanup

Administrators can also see Cleanup Stale Runs.

This action is meant for recovery situations, such as:

• a restart left some runs stuck
• a run exceeded its timeout
• the page still shows work as running when it should have failed

The cleanup action marks those stale runs as failed so the history becomes accurate again.

Next step

The next chapter covers Resources, which includes knowledge bases, prompts, skills, MCP servers, tools, variables, and integrations.