Chat

Chat is where you talk to an agent directly and watch each tool call as it happens. It is also the fastest way to find out whether an agent is configured the way you think it is, before you put it behind a schedule or a widget.

Pick the agent, type, and the response streams back with its reasoning and tool calls shown inline rather than hidden.

Choosing an agent

The Agents menu in the header switches agent. It has a search box and scrolls; arrow keys move through it, Enter picks and Escape closes, and picking an agent closes it. On a phone it is a robot icon. A workflow agent's header reads Workflow · N steps.

With no agent picked, the workspace's first agent answers. With none at all, a message fails with No agent to answer yet — create one in Agents, or ask the AI builder to make one.

The welcome line says Ready when the agent's model can answer, and Model not ready with the reason and a link to Settings → Models when it cannot — No OpenAI key is saved., Ollama is not reachable at http://127.0.0.1:11434., or Ollama has no model named mistral. Pull it with ollama pull mistral, or choose another model. The check makes no model call: it looks for a saved key, a saved server address, or the model in Ollama's list. For a workflow agent it checks every model its steps run on, and names the step that cannot answer (· A step is not ready).

Sessions

Each conversation is a session. The chat page reopens on the conversation you were in — with a question it is waiting on you for, and a reply still being written; New chat starts a fresh one. API callers keep continuity by passing the same session_id. See Memory for what persists beyond a session and what does not.

Each turn is sent the recent turns of the conversation, with a short record of the tools they used: the arguments and the start of each result for the last three turns that used tools, and the tools' names before that. The agent can open any earlier turn in full with its session_history tool. A turn you stopped keeps the calls it had made.

Long conversations are compacted automatically rather than failing when they outgrow the model — see Settings.

History

Chat History lists the conversations people had in Chat, each with its agent's name; a workflow's steps, a team's members, helpers and Synapse AI's own conversations are not in it. A workflow agent's turn that waited on you is saved once it is answered, with the workflow's answer. Escape closes the list.

A reopened conversation shows, under each answer:

• Tools used · N — each call with its arguments and the start of its result, and · N not run when some were not run.
• The images the question carried, as a note — 1 image (PNG) — not kept after the turn.
• The agent's Thinking and Reasoning panels. A turn saved before these were kept reopens without them.

Leaving mid-turn

A turn runs on the server, not in your browser. Closing the tab, reloading, navigating away or a laptop going to sleep does not stop it: it finishes, its answer is saved to the conversation, and coming back reopens the conversation with the reply — still arriving, if it has not finished yet. A dropped connection is picked up where it left off; the question is never sent a second time.

A conversation writes one reply at a time. A message sent while a reply is still being written — from another tab, say — is refused with A reply is still being written in this conversation, and the page shows that reply instead.

Images

Attach images to a message for models that accept them. A workflow agent takes them when one of its steps has Sees attachments on, on a model that can read images (Step types → Agent); otherwise Attach, a drop and a paste all say why. In the cloud, an image sent anyway is refused with the same sentence. An attached image's thumbnail opens it full size in the page.

The total cap exists because five 4.5 MB phone photos clear the per-image limit individually and fail together — and the only limit worth having is one you learn about before the round trip, not after it.

An image is seen by every model call of the turn it was attached to. It is not stored: later turns are told it was attached and is no longer, so attach it again to ask about it.

While it works

The line under the reply shows the agent's latest thought, and each tool call as it starts. A workflow agent's line names the step that is running, and its answer arrives once, at the end.

Stopping a turn

The stop control asks the turn to stop. It reports "cancelling", never "cancelled", and the distinction is honest rather than pedantic: a turn sitting inside a long provider call stops when that call returns, not the instant you click. A bash command already running is not stopped either; it runs to its own timeout.

If nothing was running — the turn had already finished — that is reported as such rather than as an error.

Stop is the only thing you do that ends a turn early. A stopped turn keeps your question in the conversation, answered (Stopped before answering.), so it is still there when you come back and Try again has something to retry. For an Orchestrator agent, Stop also stops the run the agent started.

A turn also stops itself when it is repeating: the same tool, with the same arguments, returning the same result three times in a row ends the turn with an answer that says so. After the second, the agent is told it already has that answer. Different arguments, or a new result, never count.

When the model fails

If the agent's model call fails — the provider refuses the request, the key has no credit left, the model's server cannot be reached, or it sends back nothing usable — the turn fails and says why: The model couldn't answer., the provider's own words, a link to Settings → Models, and Try again. The error is never saved as the agent's reply. The conversation keeps your question, answered (The model failed before answering.), and Try again removes that pair before asking again.

Nobody outside the app sees the provider's words: a widget visitor, someone on a messaging channel and an API caller each get a fixed sentence instead.

A reply that arrives empty counts as a failure too, and the error says which kind it was: the model returned nothing, or the provider withheld the reply — a safety filter, a content filter or a guardrail. A reply that is all thinking, with no answer and no tool call, is asked for once more; a second one fails the turn. None of these is reported as a finished answer.

An Orchestrator agent whose workflow fails shows the failure as the turn's error, in the run's words; the conversation keeps your question, answered (The workflow failed before answering.).

Approvals mid-conversation

When tool policy is set to ask first, a tool call stops the turn and asks you: Permission needed, with Allow once and Refuse — and a box for why, which the agent reads and works around. While it waits, the turn shows the card alone. Allowing applies to that call, with those arguments, only. The turn then continues from where it paused.

This is the one pause a chat turn cannot recover from on its own, so the pending call is parked together with the conversation's last turn-boundary snapshot and resumed from it — which is why an approval survives a restart rather than stranding the conversation.

Sending a new message instead of answering refuses the call. The card reads You moved on — this was not run., the agent is told, and the call cannot be allowed afterwards. A workflow agent's run that asked is stopped. Text typed under an approval card is always a new message, never an answer to it.

A call that was not run — refused by you, or blocked by policy — is marked ⛔ … — not run as it happens, and listed under the answer, with why: the answer is the model's own words, and can say something was done when it was not.

Your answer applies to the exact call you were shown, and to that call only. If two answers arrive at the same moment — two tabs, a double click, a retried request — one is applied and the other is refused; the tool runs once. A card left open in another tab cannot answer a later question either: if the turn resumed and stopped to ask something else, answering the old card is refused rather than spent on the new call.

Reasoning effort

Where a model has a real reasoning channel, chat honours the agent's effort setting. Turning it up for a hard question and down for routine ones is the single biggest lever on what a conversation costs.

Sources

When the agent answers from a knowledge base, the passages it cited are listed under the answer as Sources — each with its file, page and section, linked to the file — and [K2] in the answer jumps to its row. A quote that is not in its passage, and a label no search returned, are flagged in amber. Sources are saved with the conversation. See Agents, chat and workflows.

On SynapseOrch Cloud

Chat works the same way on Cloud. Its screen differs in a few places:

• The agent picker is labelled Agent and has a search box (Search agents…). A workflow agent shows Workflow where other agents show their model.
• A question's images are kept with the conversation, so Try again and editing a question send them again.
• A reopened answer shows its thinking above it.
• An approval you refused reads Refused — this was not run.
• A viewer can read conversations but not send a message.

Chat and the rest of the product

• The agent uses whatever tools, skills and memory it is configured with — chat is not a different mode.
• Conversations appear in Runs › Logs alongside workflow runs.
• Thumbs up and down feed evals, so a rubric can be checked against what people actually thought.