Talon FlowTalon Studio v1.0.2-beta

Nodes & data

The building blocks of a flow (read, logic, action and tool-adapter nodes), how branching and failure are handled, and the blackboard that carries data between nodes.

Node types

There are 49 node types. The 24 built-in nodes below are listed with the label the builder's palette shows; the other 25 are tool-adapter nodes, thin wrappers over the tools the Claw agents use.

lookup_cve

Look up CVE: the CVE and the ATT&CK techniques it maps to, with existing detections and data readiness.

assess_coverage

Assess coverage: this workspace's coverage gaps (hasGap, topGap, gapCount).

lookup_mitre

ATT&CK technique: a technique by ID, such as T1059.

list_streams

List log sources connected to the workspace.

list_detections

List detections, so a later step can branch on what exists.

list_feeds

List threat feeds and how many indicators each holds.

consult_skill

Consult skill: pull in the most relevant playbook.

set / noop

Set fields for later steps; Stop / no-op ends a branch.

if / switch

If routes to a true or false output; Switch routes to the first matching case, or default.

subflow

Run a flow: runs another saved automation as one step.

filter / merge / loop

Filter items in a list; Merge items from several lists; For each: run a saved automation once per item.

run_search

Run SIEM search: a read-only search on your SIEM.

talon_search

Talon Search: a federated search across the workspace's data lake and SIEMs, returning a row count. Searching more than one source at once is an Enterprise feature.

http_request

HTTP request: a governed GET or HEAD to an allowlisted host.

notify

Notify: sends a Slack or Teams message to your configured notification destinations.

llm_call

LLM call: a prompt you write, with blackboard values substituted; the reply (optionally parsed as JSON) goes on the blackboard.

draft_detection

Draft detection: the AI drafts a SIEM detection for a technique.

propose_change_request

Propose change request: stages a drafted detection as a draft change request.

run_agent

Run agent: hands a goal to one of your agents, which runs in the background and proposes change requests.

create_card

Create board task: a card on the workspace board for a person to pick up.

Tool-adapter, Read (13): get_detection, get_detection_source, get_validation_summary, search_content_library, semantic_search, recall_runs, list_change_requests, get_change_request, find_related_work, get_deployment_status, get_replay_results, validate_detection_draft, link_to_surface.

Tool-adapter, Propose (4): propose_siem_action, propose_new_detection, propose_detection_edit, run_detection_validation. The detection nodes stage a draft change request in one step, like propose_change_request.

Tool-adapter, SIEM (8): siem_search_all, siem_event_sample, siem_field_presence, siem_sourcetype_volume, siem_fields, siem_inventory, siem_validate_query, siem_data_model_status.

Three of the logic nodes are array operations rather than control flow, and one action node is a governed outbound fetch:

filter keeps the elements of an items array whose condition holds, evaluated once per element with the element bound as ${item.field}.

merge concatenates values from several referenced inputs into one array. This is a data merge, distinct from the runner joining control-flow branches.

loop (For each) runs a saved flow once per element of an array, one after another, capped at FLOW_LOOP_MAX_ITEMS (default 25). The child flow reads the element from its trigger.

http_request is read-only: GET or HEAD over http(s). The host must be on the operator's FLOW_HTTP_ALLOWLIST, a comma-separated list of hostnames where a leading *. allows subdomains. It is empty by default, so every request is refused until an operator sets it. IP-literal hosts and redirects are refused, and each request is capped by FLOW_HTTP_TIMEOUT_MS (default 10 s) and FLOW_HTTP_MAX_BYTES (default 256 KB).

Nesting cap

subflow and loop share one nesting bound: a chain of flows calling flows is capped at 3 levels deep.

Branching & failure

Branches. An if node has a true and a false output; a switch node has one output per labelled case plus default, and the first case whose condition holds wins. Nodes on a branch that was not taken are skipped, not failed, and the skip propagates downstream.

Run only if. Any node can carry a condition (when in the YAML); if it is not truthy when the node is reached, the node is skipped and the timeline records the unmet condition.

Retries. Each node can retry 0–5 times before it counts as failed; every attempt is bounded by the node timeout.

On error. Every node has a red handle at its bottom edge. An edge drawn from it runs only if that node fails, which is how a flow handles a failed step (for example, notify on failure). A failed node's ordinary outgoing edges stay live, so downstream nodes still run after an upstream failure.

The blackboard

Each node's output is stored in one shared JSON object, the blackboard, under the node's id. Downstream nodes read upstream results by reference: ${nodeId.field} pulls a value from a named node, and ${trigger.field} pulls from the trigger. A tool-adapter node puts the whole tool response under result, so reference it as ${nodeId.result.field}. Logic nodes evaluate the same references.

Reference syntax

Any string parameter can interpolate blackboard data. A value that is exactly one reference keeps its real type (a number, list or object); a reference inside longer text is substituted as text.

Use the data picker

The builder's data picker lists each upstream node's output fields before you run anything. Test run adds live values for nodes that run for real in a dry run (lookups and logic); searches, LLM calls and propose steps return stubs there, so check their field names against a real run in Executions.