BusyBot concepts

Chat #

One conversation, one model, streamed token by token.

Chat is the plain case: you pick a model and talk to it. The reply streams as it is generated rather than arriving in one block, and the conversation keeps its context when you switch models mid-thread — the thing that normally forces you to start over in another tab.

A chat turn can also generate images, in which case the image is stored in your workspace and billed per image rather than per token.

Burst #

The same prompt sent to several models at once, answers side by side.

Burst runs one prompt across a squad of models in parallel and lays the replies out together, so the comparison is the output rather than something you assemble by hand across four tabs.

Squads are grouped by intent — Lite (each provider's fastest, cheapest model), Regular (the flagship daily drivers), Reasoning (extended-thinking models), and Custom, where you pick the line-up yourself. Every model in the squad is metered individually, because every one of them really ran.

Agent mode #

A conversation with something that can act, not just answer.

In Agent mode the model on the other end has tools, workflows and knowledge bases attached to it. It decides what to call, calls it, reads the result and keeps going until the job is done — see Agent below.

Workflow #

A directed graph of nodes that runs as one unit.

A workflow is a DAG — a directed acyclic graph. Nodes are the steps, edges say which step feeds which, and anything with no unmet dependency runs immediately. Two branches that do not depend on each other run at the same time, not one after the other.

You build one on a canvas by dragging nodes and connecting them. It can be run by hand, called by an agent as a single tool, fired by a trigger, or put on a schedule.

Node #

One step in a workflow — an action, a trigger, or a routing decision.

Every node is a shipped, versioned unit with declared inputs, outputs and error behaviour. There are 456 of them: SaaS integrations, AI model calls, data transforms, file and storage operations, and the core routing nodes (switch, merge, split, loop) that hold a graph together.

Each node has its own reference page with its real parameters — browse all 456.

Trigger #

A node that starts a workflow instead of sitting inside one.

A workflow can start three ways. A webhook trigger gives the workflow a URL and runs it when something POSTs to it. A polling trigger checks a service on an interval and runs when a condition is met, keeping state between checks so the same row is not processed twice. A schedule runs it on a clock.

Item #

The unit of data that moves along an edge.

Nodes do not pass single values to each other; they pass lists of items. A node that receives 200 items generally runs its operation 200 times, which is why looping is usually implicit rather than something you wire up.

Large payloads and binary data are stored once and referenced by pointer, so a 50 MB attachment moving through six nodes is not copied six times.

Expression #

How one node reads another node’s output.

Any parameter can be a static value or an expression in double braces: {{ $json.email }} pulls a field off the current item, {{ $index }} is its position in the batch, and {{ $datetime.now }} stamps the moment of execution.

The editor autocompletes field names from the data the upstream node actually produced on its last run, so expressions are written against real output rather than a guess at the shape.

Execution #

One run of one workflow, kept as a record.

Starting a workflow creates an execution. It streams progress as it goes — which node started, what it produced, which failed — so a run is watchable rather than a spinner that eventually turns into a result.

Executions are retained, so you can open a run from last Tuesday and see the exact data each node received and returned.

Agent #

A configured model that can call tools and decide what to do next.

An agent is a saved configuration: which model drives it, which tools it may use, which saved workflows it may run, which knowledge bases it may search, and the instructions that shape how it behaves.

Given a task it runs a loop — reason, call something, read the result, reason again — rather than producing one answer and stopping. Between turns it checks its own progress and can change plan.

Tool calling #

The mechanism an agent uses to act on the world.

The model emits a structured call — a name and arguments — and the engine executes the real node, then hands the output back into the conversation. The model never touches your credentials or the network directly; it asks, and the platform runs it under your permissions.

Working memory #

What the agent knows about the task it is currently running.

Working memory holds the tools already executed and the data already retrieved during a run, so an agent twelve steps in still knows what it found at step two without re-fetching it.

Planning and reflection #

Deciding the approach, then checking whether it is working.

For longer tasks an agent drafts a plan before acting and reviews progress against it as results come in, replanning when something turns out not to work. Reasoning models — the ones with extended thinking — are supported here and are usually the right choice for work with real branching in it.

Knowledge base #

A searchable collection of your own documents.

A knowledge base ingests documents — PDFs, contracts, transcripts, spreadsheets, audio and video — and makes them searchable by meaning. Agents and chats can be pointed at one so their answers are grounded in what your documents actually say, with the source passage available rather than implied.

Chunk and embedding #

How a document becomes searchable by meaning.

Ingestion splits a document into chunks and converts each into an embedding — a vector capturing what the passage means. A search converts your question the same way and returns the closest passages, which is why "what did we agree about termination" finds the right clause even when it never uses that word.

Semantic search #

Retrieval by meaning, not keyword match.

Search runs over the embeddings and returns ranked passages with their source documents. An agent can issue several searches in a row, narrowing as it learns what it is looking for, rather than getting one shot at a query.

Dataset #

Tabular data an agent can query rather than read.

Structured uploads — CSVs, exports, spreadsheets — are stored as datasets and queried with SQL-like filters and aggregates. Counting 40,000 rows is a query, not something to feed through a context window.

Credential #

A stored connection to one external service.

A credential holds the API key, token or OAuth grant a node needs. It is created once and reused: a single openai credential lights up every node that needs OpenAI. There are 297 credential types across the 456 nodes — see what each one needs.

Secret values are encrypted at rest with AES-256-GCM, are never displayed again after saving, and are scoped to your account — another account's workflow cannot use them.

Schedule #

A workflow on a clock, running without you.

A schedule fires a saved workflow on a repeating cadence. How many schedules you can hold and how frequently they may fire depend on your plan — see pricing. Each fire is an ordinary execution, metered like any other.

Group #

A folder for workflows, agents or knowledge bases.

Groups organise saved objects once there are more than a screenful. They are organisational only — a workflow behaves identically whichever group it is in.

Credit #

The single balance every kind of usage draws down.

Rather than a token bill, a compute bill and a storage bill, everything settles into one credit balance. Credits arrive by subscription grant or prepayment, and every charge is an entry on a ledger you can read.

The three meters #

Tokens, compute and storage — the only things measured.

Tokens are charged wherever a model runs, at your plan's markup over the provider's list price. Compute is charged per hour a workflow's runtime is alive, beyond what your plan includes. Storage is measured nightly across your knowledge bases and files and charged at a monthly rate. Full numbers are on the pricing page.

BYOK #

Bring your own model keys and skip the markup entirely.

On any paid plan you can supply your own provider API keys. Model calls then run on your key and are billed by the provider directly, with no BusyBot markup on tokens. Compute and storage are still metered, because they are still ours.

Private cloud workspace #

A runtime that belongs to you rather than to a shared pool.

On the higher plans your workflows run on a dedicated workspace that wakes when you use it and scales to zero when you do not. Because the capacity is yours rather than rented by the hour, compute stops being metered at all. Organisations get the same arrangement at team scale, with pooled billing and their own URL.