Getting started

Core concepts

The words this platform uses, and what each one corresponds to mechanically. Worth twenty minutes — most agent problems are really a misunderstanding of one of these.

The model, and what it can't do

A language model is a function from text to text. It has no memory between calls, no access to your files, and no ability to act on the world. Everything else on this platform exists to work around one of those three limits.

It also has no notion of truth — only of plausibility. A model asked for a total it cannot compute will return a number that looks like a total. This is not a bug that better prompting fixes; it is what the machine is. The reliable move is to never ask it for facts it would have to invent, and instead hand it facts retrieved by something deterministic.

Agent

An agent is a saved configuration: a system prompt, a model, a set of permitted tools, optional knowledge and data, memory settings and guardrails. It is not a running process. Each time you chat with it, the platform assembles those pieces into a request.

your message
      │
      ▼
┌──────────────────────────────────────────┐
│ system prompt + retrieved context        │
│ + conversation history + tool definitions│
└──────────────────────────────────────────┘
      │
      ▼  model decides: answer, or call a tool
      │
      ├─ tool call ──▶ platform runs it ──▶ result appended ──┐
      │                                                        │
      │◀───────────────────────────────────────────────────────┘
      ▼  (loop until the model stops asking for tools)
   final answer + sources

What one agent turn actually is.

The loop is the important part. The model doesn't "use" a tool; it emits a request to use one, the platform executes it, and the result is fed back as more text. An agent that seems to ignore its tools is usually one whose prompt or tool descriptions didn't make the choice obvious.

Tools

A tool is a function the model may ask for by name, with a description and a typed argument schema. The description is not documentation — it is the entire basis on which the model decides whether to call it. Tools available here:

Tool	What it does	Reach for it when
`kb_search`	Semantic search over your knowledge base	The answer is written down in prose somewhere
`sql_query`	Read-only SQL over connected tables	The answer requires counting, filtering or aggregating
`metric_query`	Governed metrics from the semantic layer	The number has an agreed definition you must not re-derive
`web_search`	Live search via Firecrawl, Brave, Tavily or SerpAPI	The answer is outside your data and changes over time
`web_browse`	Fetch and read one page	You have a specific URL worth reading in full
`mcp_call_tool`	Call a tool on a connected MCP server	Another system owns the capability
`calculator`	Arithmetic	Any arithmetic at all — never let the model do it in its head

Why it works this way

Tool choice degrades as you add tools. With three tools the model picks well; with ten it starts pattern-matching on surface wording and reaching for whichever description sounds richest. The platform mitigates this by injecting explicit routing rules into the prompt, but the real fix is giving each agent a narrow job and only the tools for it.

Retrieval, or "RAG"

Retrieval-augmented generation means: before asking the model anything, go and find the relevant text, paste it into the prompt, and instruct the model to answer only from it.

Mechanically, on this platform:

Your document is split into chunks of a few hundred words.
Each chunk is turned into an embedding — a list of numbers positioning it in meaning-space, so "refund window" lands near "return period" without sharing a word.
Your question is embedded the same way, and the nearest chunks are pulled back and put in the prompt with numbered citations.

This is why retrieval fails in two characteristic ways. If the chunk containing the answer never got retrieved, the model answers from general knowledge and sounds fine. If your question phrases something very differently from the source, the nearest chunks are the wrong ones. Both are visible in the trace — check what was retrieved before blaming the model.

Note

Retrieved documents are candidates, not proof. On this platform a knowledge base source is only listed under an answer when the answer actually cites it, or when nothing else grounded the answer — so a web-search answer no longer drags unrelated documents along behind it.

Swarm

A swarm is a graph of nodes: agents, routers that branch on a condition, loops, parallel fan-outs, human approval gates, code functions and tool nodes. Output flows along the edges.

Split one agent into several when — and only when — one of these is true:

The jobs need different tools. A researcher that browses the web and a writer that never should are cleanly separate.
A step must be checked before it continues. Put an approval node in the path.
Work can happen in parallel. Three independent analyses fan out and join.

Otherwise prefer one good agent. Every hop is a place for context to be lost in summarisation, and a multi-agent graph is markedly harder to debug than a single prompt. See Swarm Canvas.

Memory

Three different things get called memory. They behave differently:

Kind	Lifetime	What it is
Context window	One request	The transcript sent with this call. Finite; the oldest turns fall out first.
Short-term (STM)	One conversation	A rolling summary of earlier turns, so a long chat survives the window.
Long-term (LTM)	Across conversations	Durable facts the agent chose to remember, recalled by relevance to the current message.

Long-term memory is opt-in per agent and is stored as ordinary rows you can inspect and delete. Chat history has its own retention window — see retention.

Guardrails

Guardrails run outside the model, on the way in and on the way out — which is why they hold when a prompt is manipulated into ignoring its instructions. They can block topics, require citations, and detect or redact personal data before it reaches a provider. See Guardrails & PII.

BYOK — whose key pays

Bring your own key. You connect your own provider credentials (OpenAI, Anthropic, Bedrock, Vertex, Azure, and others) and calls are billed to your account, at your rates, under your data agreement with that provider. The operator's shared key is only a zero-config fallback so a new workspace works before anything is connected.

This is a governance property, not a billing detail: prompts and documents travel to a provider you chose and hold the contract with. Which models a user may reach is controlled separately in access control.

Traces

Every model and tool call is recorded: the resolved prompt, arguments, results, tokens, latency and cost. Traces are the ground truth for what an agent did — an agent's own account of its reasoning is generated text and can be wrong. Debugging here means reading the trace first and forming a theory second.

Which one do I actually want?

The concepts above overlap enough that the common question is not "what is retrieval" but "is this a retrieval problem or a data problem". This is the mapping that resolves most of them:

What you want	Reach for	Not
Answers quoted faithfully from documents	A knowledge base	A long system prompt containing the documents — it costs the same tokens every turn and still cannot cite
A number that has to be arithmetically right	A table and `sql_query` — Data Catalog	Retrieval. A model reading a figure out of prose is guessing, confidently
A definition everyone must compute the same way	A semantic metric	Repeating the SQL in each dashboard, where the four copies drift
A reusable transformation of your own data	A prepared table	A calculated field in each chart that needs it
Steps that must happen in a fixed order, with a human check	A swarm with an approval node	One agent and a prompt telling it to ask first — a prompt is guidance, a gate is a gate
The agent to remember something between conversations	Long-term memory, opt-in per agent	A larger context window, which forgets everything the moment the conversation ends
Something it must never say or leak	A guardrail, which runs outside the model	An instruction in the system prompt, which is exactly what a manipulated prompt talks it out of
To stop one team spending the whole budget	A cap on the group or credential	Watching the analytics page and intervening — by then it is spent

Why it works this way

Nearly every "the model isn't good enough" report is one of these choices made the other way. A bigger model does not make prose arithmetically correct, does not make a prompt into an enforced gate, and does not remember anything after the conversation ends.

Quick glossary

Term	Meaning
Token	A chunk of text (~¾ of a word) — the unit models are billed and limited in.
Temperature	Randomness. Low for extraction and classification, higher for drafting.
System prompt	Standing instructions prepended to every turn.
Embedding	A numeric position in meaning-space, used to find related text.
Chunk	One retrievable slice of a document.
Context window	The maximum text a model can consider at once.
MCP	Model Context Protocol — a standard way to expose tools to any agent.
Idempotency key	A client-supplied id that makes a retried API run execute only once.

PreviousQuickstart Next Dashboard