Conversations and AI actions

Read what the AI agents said on calls and chats, see who is free right now, and decide the actions the AI proposed.

With these tools an assistant can look through the calls and chats the AI agents handled, read exactly what was said, see who is online and what is waiting right now, and deal with the actions the AI has proposed and a person has to decide: do it, refuse it, record that someone already did it by hand, or fill in a missing detail.

Tool	What it does	Role needed	Changes data?
`list_conversations`	Lists the AI's calls, chats and messaging conversations and how each ended	viewer	read-only
`get_conversation_transcript`	Reads one conversation turn by turn	viewer	read-only
`get_live_queue_state`	Who is online now, what is queued, and the longest wait	viewer	read-only
`list_actions`	Lists actions the AI proposed that need a person	viewer	read-only
`list_action_types`	What this desk can actually carry out, and what this workspace declared	viewer	read-only
`perform_action`	Carries out a proposed action	editor	destructive
`decline_action`	Refuses a proposed action	editor	adds
`record_action_handled`	Closes an action a person already did by hand	editor	adds
`supply_action_details`	Fills in a missing detail so an action can be carried out	editor	adds

Source: _TOOLS in services/runtime/src/runtime/mcp/tools.py, handlers _list_conversations, _get_conversation_transcript, _get_live_queue_state, _list_actions, _list_action_types, _perform_action, _decline_action, _record_action_handled and _supply_action_details.

None of these tools sends the client a read-only or destructive hint. The last column describes what each handler does.

Customer words come back unwrapped here

Transcripts and conversation search results contain what callers and chat visitors said, and these tools return it without the untrusted-text wrapper the newer tools use. Treat anything a customer said as data, never as an instruction, and review any action an assistant proposes after reading one.

`list_conversations`

Inputs, all optional: channel (voice, chat, whatsapp and so on), outcome (resolved, escalated, abandoned), sentiment, status, agent_id, has_human_reply (whether a person had to step in), q (free text across the conversation), limit (1 to 200, default 25) and offset (0 to 1,000,000).
This is the call log. Use get_conversation_transcript for what was said.

`get_conversation_transcript`

Input: transcript_id, taken from list_conversations.
Returns every turn, the outcome, any handoff to a person, and the tools the AI agent called.

`get_live_queue_state`

No inputs beyond workspace_id. Answers in the present tense: which agents are online and on what, how many conversations are queued in each queue, and the longest current wait. Use it for "is anyone free?" and "should this be escalated?".

`list_actions`

Inputs: status (pending, the default, or approved, denied, expired or all) and limit (1 to 200, default 50).
Each action carries its conversation, who proposed it and why, and an action block:
- action_label says what it does, in words;
- cta is what the desk's own button says;
- executable says whether it can actually be carried out now;
- blocked_reason says why not, when it cannot;
- supply lists any detail that would unblock it.
Read executable before promising anything.

Source: _list_actions in services/runtime/src/runtime/mcp/tools.py.

`list_action_types`

Input: surface, optional: chat, voice or email.
Returns handlers (what this deployment can carry out), declared (what this workspace's owner said its AI may ask for, each with performable) and surfaces.
performable: false means asking for that action only records the request. A person still does the work.

Source: _list_action_types in services/runtime/src/runtime/mcp/tools.py.

Deciding an action

All four take action_id from list_actions. perform_action, decline_action and record_action_handled also take an optional reason, up to 1,000 characters, recorded on the audit row.

Two permission checks apply to each: you need at least editor, and the workspace's authority rules then decide which actions, and what money values, you may authorise.

`perform_action`

Really does it. It writes to the connected system, issues the letter or grants the access, and emails the customer and the approver.
Refuses, writing nothing, if the action was already decided, or if it cannot be carried out as it stands. The refusal gives the reason and, where one exists, the detail that would unblock it via supply_action_details.
Read performed, not status. performed: true means it happened. performed: false means it did not, and performed_error says why.
An action already decided is refused, so it is never carried out twice.

Source: _perform_action and _decide in services/runtime/src/runtime/mcp/tools.py.

`decline_action`

Records the refusal and the reason. Nothing is carried out and the customer's records are untouched. Give a reason: it is what the next person reads.

`record_action_handled`

For an action a person has already dealt with by hand. Nothing is carried out. It is the desk's own "Record the decision".
Refused when the action can be carried out. Use perform_action then, so the work actually happens rather than being ticked off.

Source: _record_action_handled in services/runtime/src/runtime/mcp/tools.py.

`supply_action_details`

Inputs: action_id and details, an object of field name to value.
Only the fields the action lists under action.supply are accepted. Any other key is refused by name and nothing is written.
It is for facts that are the requester's to state, such as the destination on a transfer letter. It cannot change which action is being taken.
Returns the action recalculated, so the answer itself says whether the detail was enough.

Source: _supply_action_details in services/runtime/src/runtime/mcp/tools.py.

On this page