The Visual Editor

A betool pipeline is a graph of nodes that you assemble in the visual editor. Each node type declares server-side its configuration and the keys it produces; the editor validates the graph and the configuration before letting you publish it.

Pipeline anatomy

[Start]──▶[agent]──▶[router]──┬──▶[agent]
                              └──▶[webhook_action]

• The Start node is created automatically with the model; it carries the receivers (input channels) that trigger the pipeline. A single Start can declare several of them.
• Each downstream node reads the keys produced by upstream nodes from the execution context.
• A router or filters create branches; each execution leaves a trace you can inspect.

Core concepts

Flow key

A key is a named piece of data that flows between nodes. For example: an agent node can write its output under exchange.intent, and a downstream node (filter, router) tests that key.

What a node produces is declared by its contract, in two forms:

• Fixed key (fixed_key) — always the same, defined by the node type (e.g. input.entry_kind for the Start).
• Configurable key (configurable_key) — chosen in the node's configuration (e.g. an agent's output key).

What a node reads is set in its configuration (the field tested by a filter, an agent's inputs…).

Contract

Each node type exposes a contract declared server-side: its configuration fields (type, allowed values, required fields, default values) and the keys it produces. The editor relies on this contract to build the configuration panel and validate what you enter.

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.

Secrets

Fields that a node's or receiver's contract declares as secret (HMAC secret of an inbound webhook, token or password of an HTTP call, access token of a Page, secret of a sub-pipeline…) are never returned in plain text once saved: not to the editor, not through the API, not to the MCP tools and agents that read a pipeline, and not in proposals.

In the inspector, such a field shows "•••••• saved — type to replace":

• left empty, it keeps the saved secret;
• typing a value replaces it;
• the Remove button clears it (for an HMAC secret, signature verification is then disabled).

Creating a pipeline

1. Models → New — in betool, a model carries your pipeline.
2. The canvas opens with a Start node. Configure it to select the input channel(s).
3. Add nodes with the Add a node button when hovering over a link, or by right-clicking a node (Add a node before / after), then choose their type from the module catalog (search by name).
4. Connect the nodes together. The pipeline is a tree: each node has a single parent.
5. Click a node to open its configuration in the inspector.
6. Run a test — execute the published version on a freely entered payload, in real mode or in Simulation mode (nodes with external side effects are skipped).
7. Publish — a commit message is mandatory; the pipeline is validated, then the new version becomes the one executed by the runtime.

Versioning

Each publication creates a version. From Versions, you can:

• Compare a version with the current state (nodes and links added, removed, modified).
• Reload a version into the editor (the draft is overwritten, without publishing).
• Republish an earlier version (rollback).

From the history, a past execution originating from a receiver can also be replayed on the published version, with an optionally modified payload and in simulation mode if needed.

Validation

On publication, a validator checks the graph:

• Blocking — cycle in the graph; node with several parents; mandatory output left unwired (the body of a foreach loop, the children of a parallel, each declared route of a router); incorrect number of Start nodes; errors specific to a node type (e.g. non-existent agent role or mission).
• Warning (non-blocking) — node unreachable from the Start; an existing configuration diverging from its node's contract.

When a configuration is written (editor, proposals, API), a value outside the allowed values or a missing required field is refused, with the expected correction.

As a result, a published pipeline has passed these structural checks. Remaining errors belong to execution (a third-party API call failing, an unexpected parse result).