Run & observe

Chat Playground

The playground at /playground is where you talk to agents directly. It looks like a chat app; the difference is that every message produces a trace you can inspect, and the agent runs with its full saved configuration — same tools, same guardrails, same memory as anywhere else on the platform.

Chatting with an agent

Pick an agent from the selector and the conversation runs against its saved configuration: provider, model, system prompt, knowledge bases, skills, tools, guardrails, and memory. Conversations are persisted, so you can leave and pick a thread back up later.

Attachments — drop images (sent to vision-capable models as image input) or documents (parsed and added to the conversation context) directly into a message.
Citations — when the agent answers from a knowledge base, the message carries the source chunks it used, so grounded answers are visibly grounded.
Memory chip — when long-term memory is enabled, each reply shows how many memory items were recalled (with a preview), so you can see exactly what the agent "remembered" rather than guessing.
Fallback override — if the primary model fails, the playground offers a fallback model picker; your choice sticks for the rest of the session and is shown explicitly.

The trace behind every message

Every response carries a trace ID, and the inspector panel opens the full execution record for any message: the resolved prompt, tool calls with their arguments and results, tokens, cost, and latency. This is the playground's real purpose — the fastest loop from "I changed something in my agent" to "I can see exactly what that change did". The same traces are queryable later from Logs & traces.

Skill-sample agents

The first time you open the playground, a small set of sample agents built around skills is seeded into your workspace, with a short tour overlay that demonstrates how attached skills change an agent's behaviour. They are ordinary agents in your library afterwards — edit or delete them freely.

Treat the playground as your default debugging surface: reproduce the problem in a chat, open the trace for the bad message, and read what the model actually saw and decided. Most "the agent is broken" reports dissolve at that step.

Composer controls — every button

Control	What it does
Attach	Attach images or documents to the turn. Text is extracted and included in the prompt; a summary is saved with the message so the history stays readable.
Visual BI	Generate charts from your connected tables alongside the text answer. Seeded from the agent's `tools.biVisuals` setting and toggleable per session. Ask for more than one — “show me 3 charts of sales”, “a couple of visuals”, “charts for revenue, cost and headcount” — and the question is split into one analytical question per visual (up to 4). A plain request still produces one chart and costs exactly what it did before.
PPT / Word / Excel	Generate a real, editable Office file from a prompt. See below.
Sample / Full data	How much data is pulled in — applies to Excel generation and the Visual BI row snapshot.
Model override	Swap the model for this session only. The fastest A/B test on the platform.
Stop generating	Cancels the in-flight turn.
Regenerate	Re-runs the last turn.
Edit & resend	Rewrite your message and rerun from that point.
Inspector	Live thinking, tool calls, and the full request/response for the last turn.

Sources under an answer

Every answer lists what it actually drew on, grouped by kind — web links, knowledge base documents, the tables a query read, an MCP tool, or any other tool. Several kinds appear together when the answer genuinely used several.

Why it works this way

Knowledge base documents are retrieved before the model runs, so their presence proves nothing about whether the answer used them. They are listed only when the answer cites them by number, or when nothing else grounded it — which is why a web-search answer shows links rather than a tail of unrelated documents. Reading this panel is the fastest honesty check available: ask a data question and if the sources show a document rather than a table, the agent answered from prose it half-remembered instead of counting.

Generating documents

Phase	What is happening
gathering	Collecting knowledge excerpts, table schemas and samples, the recent conversation, and — if the prompt points at the internet — live web research.
planning	An LLM produces a typed plan for the document.
building	The plan is filled with real numbers and rendered into a file.

Browser vs Deep

	Browser · fast	Deep · slow
Renders	In your browser	Server-side, native Office toolchains
Deck size	16–22 slides	24–30 slides
Diagram variety	≥8 kinds	All 14 kinds, none more than twice
Extras	—	Contents page; render-verify pass
Needs	Nothing	The docgen service running — see Install & deploy

Deep greys out when it cannot run

If the renderer is unreachable, Deep would silently fall back to the browser build and produce a file identical to Fast. The composer probes for the service and disables Deep with the reason instead, so "Deep did nothing" is visible up front rather than after a generation.

The finished file appears as a preview card with a thumbnail and a Download button, and is stored in a private bucket so Download still works after a reload — until the agent's chat retention window purges it.

PreviousAgent Builder Next Swarm Canvas