Core concepts
A handful of terms show up everywhere in LiveContext. Learn these once and the rest of the docs read easily. Each term is also defined in the Glossary.
At its core, a LiveContext automation is a workflow: a directed graph of nodes connected by edges. A trigger starts a run, nodes execute in dependency order, and data flows forward through template expressions. Everything else (agents, interfaces, tables) is a kind of node. Short definitions of every term live in the Glossary.
Workflows and runs
A workflow is the automation itself: a graph of nodes you build in the canvas or by describing it in chat. A workflow can have several triggers, and each trigger starts its own part of the graph.
A runis one execution of a workflow. It has a status, records every step's output, and stays browsable afterwards. When the same trigger fires again, the new results are added to the run as a new epoch, so you can browse every past fire. A spawn is a re-execution inside the same epoch, produced by re-running a step; a loop pass is counted by the iteration instead. See Runs & execution.
Nodes, edges, and ports
A node is one step. Every node is identified by a normalized key of the form prefix:label, for example mcp:send_email or core:check_status. The label is the name you give the step, lowercased with spaces turned into underscores. The prefix tells you the kind of node:
| Prefix | Kind of node |
|---|---|
trigger: | Entry points that start a run (see Triggers below). |
mcp: | Operations of a catalog integration, such as sending a Gmail message. |
agent: | AI nodes: Agent, Browser Agent, Guardrail, Classify, and Generate. |
core: | Control flow and utilities: Decision, Switch, Loop, Fork, Merge, Split, Aggregate, Transform, Wait, Code, HTTP Request, Sub-workflow, and more. |
table: | Built-in spreadsheet operations: find, create, update, delete rows. |
interface: | Web pages shown to people. |
note: | Notes on the canvas. They are never executed. |
An edge is a directed connection from one node to the next. It sets execution order only. Branching core: nodes expose named ports (written core:label:port), and each port leads to its own successor. Decision uses if, elseif_N, and else. Switch uses case_N and default. Loop uses body and exit, with iterate as the input the body loops back into. Fork uses branch_N.
Triggers
A trigger is what starts a run. There are eight kinds:
| Trigger | Starts a run when |
|---|---|
| Webhook | an HTTP request reaches its URL. |
| Manual | you start it yourself. |
| Chat | someone sends a message to the workflow's chat. |
| Tables | a row is created, updated, or deleted in a table. |
| Scheduler | a recurring time comes around. |
| Form | someone submits the workflow's form. |
| Workflows | another workflow finishes a cycle without a failed step. |
| Error | a cycle of another workflow has a failed step. Use it to alert someone or clean up. |
A workflow needs at least one trigger. See Triggers for the options of each kind.
Control flow
Control-flow nodes decide which successors run. The difference between them is the thing people get wrong most often, so it is worth memorizing:
| Node | What it does | Ports |
|---|---|---|
| Decision | Takes exactly ONE branch: the first condition that matches wins. | if · elseif_N · else |
| Switch | Compares a value against cases and runs the FIRST matching case. Exclusive like Decision, but chosen by value. | case_N · default |
| Fork | Runs ALL branches in parallel, with no condition. | branch_N |
| Merge | Waits for ALL incoming branches before continuing. There is no "first one wins" mode. | none |
| Split | Fans a list out into one parallel context per item on the same branch. | none |
| Aggregate | The counterpart of Split: collects the per-item results back into one output with lists. | none |
| Loop | Runs its body again and again while its condition is true, up to a maximum number of iterations (10 by default). It needs a condition, a maximum, or both. | body · exit |
Any node with several outgoing edges also runs them all in parallel, and any node with several incoming edges waits for all of them, exactly like Fork and Merge.
Split item variables
Inside a Split, each parallel branch can read the item it is working on. These values exist only while the branch runs:
| Expression | Value |
|---|---|
{{item}} | the current item |
{{index}} | 0-based index of the current item |
{{items}} | the whole list being split |
{{core:<split_label>.output.current_item}} | the current item, addressed through the Split node (add .field to read one field) |
{{core:<split_label>.output.current_index}} | the 0-based index, addressed through the Split node |
Versions and production
Every time you save a workflow, LiveContext keeps a new version. You can browse, rename, and restore versions from Version History, next to the Save button.
Choosing Set as production on a version pins it and puts the workflow live: the version is tagged production, and the triggers that fire on their own (schedules, webhooks, forms, chat endpoints, table changes, and other workflows) start running on that version. You can keep editing and saving without affecting what runs, then move production to a newer version when it is ready.
Composing workflows
Workflows can call and follow each other:
- A Sub-workflow node (
core:) calls another workflow and waits for its result. The called workflow must already have an active run: set a production version on it, or run it once, before a parent calls it. - A Workflows trigger fires when another workflow finishes a cycle without a failed step. An Error trigger fires when a cycle of another workflow has a failed step.
See Node reference for the Sub-workflow options.
Agents, interfaces, and tables
An agent is an AI worker that calls a model to reason, decide, or write, using a scoped set of tools within a credit budget it cannot exceed. Inside a workflow it is an Agent node. Related AI nodes include Guardrail (validate or filter), Classify (route by category), Browser Agent (act on web pages), and Generate (create an image, video, or audio file). See Agents.
An interface is a web page that displays workflow data and collects input. A page with a continue action blocks the run until the person continues. Otherwise it only displays, and the run proceeds. See Interfaces & apps.
A table is a built-in spreadsheet your workflows read, search, and write. Rows have a flexible schema, and a row change can start a workflow through a Tables trigger. See Tables & data.
Execution modes
A workflow runs in one of two modes. Automatic (the default) executes every node as soon as its inputs are ready. Step-by-step pauses after each node so you can advance one step at a time, which is useful for debugging. Either way, a node becomes ready once all of its predecessors have completed or been skipped.
Run statuses
A run is always in one of 11 statuses: 5 active and 6 terminal. Once a status is terminal, it does not change again.
| Status | Kind | Meaning |
|---|---|---|
PENDING | Active | Created, not started yet. |
RUNNING | Active | Executing nodes. |
PAUSED | Active | Suspended. The only status that can be resumed. |
WAITING_TRIGGER | Active | Waiting for its trigger to fire. |
AWAITING_SIGNAL | Active | Paused on a signal (see below). |
COMPLETED | Terminal | Finished successfully. |
FAILED | Terminal | Ended on an error. |
PARTIAL_SUCCESS | Terminal | A node verdict: the node collected items and some succeeded while others failed. Runs and epochs no longer end this way (older runs may still show it): an epoch with a failed step ends FAILED. |
SKIPPED | Terminal | The run or branch was skipped. |
CANCELLED | Terminal | Cancelled by a user. |
TIMEOUT | Terminal | Ran out of time. |
Signals: when a run pauses
A signal is a point where a run pauses (status AWAITING_SIGNAL) until something happens. There are six kinds:
| Signal | Blocks the run? | Resolves when |
|---|---|---|
| Wait timer | Yes | the delay elapses. A wait of 3 seconds or less runs inline and never pauses the run. |
| User approval | Yes | someone approves or rejects. |
| Webhook wait | Yes | the awaited external webhook arrives. |
| Interface | Only with a continue action | the person advances the page. |
| Agent execution | Yes | a queued agent finishes (only when the agent runs in the background). |
| Browser takeover | Yes, always | you hand control back to the browser agent. |
Credits and budgets
Work that costs money (model calls, generations, some integration calls) consumes credits. Every agent can be given a budgetit cannot exceed. When an agent starts sub-agents, their budgets are reserved from the parent's, so the total spend of a whole agent tree is capped by the top budget. When a budget runs out, the agent stops and reports which limit it reached. See Agents and Plans & billing.
The cloud and the self-hosted Community Edition run the same engine but meter usage differently. See Overview for the comparison.
Template expressions
Everywhere a node reads another step's output, it uses the same form: {{prefix:label.output.field}}. Some examples:
| Expression | Reads |
|---|---|
{{trigger:webhook.output.payload}} | the body a webhook trigger received |
{{core:check_amount.output.result}} | the result of a core node |
{{table:find_users.output.items}} | the rows a table query returned |
{{agent:summarize.output.response}} | the text an agent generated |
New order from {{trigger:webhook.output.payload.email}}See Expressions & variables for the full syntax, functions, and workflow variables.