The Visual Editor

A betool pipeline is a graph of nodes that you assemble in the visual editor. Each node declares what it consumes and what it produces; the editor rejects incompatible connections before you ever run the pipeline.

Pipeline anatomy

[Start]──▶[agent]──▶[condition]──┬──▶[agent]
                                 └──▶[operator HTTP]

• The Start node declares which input channel triggers the pipeline.
• Each downstream node receives the context from upstream nodes (producer / consumer slots).
• A condition creates branches; all branches ultimately produce a traceable result.

Core concepts

Slot

A slot is a named piece of data that flows between nodes. For example: an agent node can produce exchange.intent: "refund_request", which a downstream condition node then consumes.

Two families:

• Producers — what a node outputs (fixed_key, configurable_key).
• Consumers — what a node accepts as input (selector, selector_list).

Contract

Each node type exposes a contract declared server-side. The editor reads this contract to offer only valid connections.

Configuration

A node also has static parameters (its configuration) — for an agent node, for example: its role, its mission, its tools, and its LLM model.

Creating a pipeline

1. Designer → Pipelines → New pipeline.
2. The canvas opens with an empty Start node. Configure it to select the input channel.
3. Drag nodes from the left-hand palette: agent, operator, condition…
4. Connect outputs to inputs. The editor only permits compatible links.
5. Click a node to open its configuration in the right-hand panel.
6. Test — the Test tab runs the pipeline against a manually crafted exchange.
7. Publish — creates a new version. Incoming exchanges are routed to the most recent version; in-flight executions continue on their own version.

Versioning

Each published change creates a new version. You can:

• Compare two versions (visual diff).
• Replay a past exchange on a new version.
• Roll back to a previous version.

Continuous validation

The editor runs a validator continuously:

• Required slots left unwired → warning shown on the node.
• Unbounded cycles → error (publishing blocked).
• Incompatible capabilities (e.g. an agent calling a voice tool inside an email pipeline) → warning.
• Missing configuration fields → error.

As a result, a pipeline that publishes successfully is guaranteed to be structurally valid. Runtime errors come exclusively from business logic (a third-party API call failing, an unexpected parse result), not from composition.