AI Orchestrator

Type: orchestrator • Category: AI • Tags: ai, agent, orchestrator

Description

AI agent that coordinates other workers. Select the workers it may use and give it a task; it chooses their parameters, calls them (possibly repeatedly), adapts when data cannot be retrieved, and produces a final answer.

Parameters

Name	Type	Description	Required	Default
prompt	textarea	The task for the orchestrator (what to produce / analyse).	yes
allowedWorkers	autocomplete	Workers the orchestrator may call (they are exposed as tools). Triggers and visualization/widget nodes are not executable tools and are hidden. Prefer a small, focused set.	yes
memoryScope	string	run: remember only within this run. workflow: persist session history AND long-term facts (remember/recall) to MongoDB. none: no memory.	no	"run"
advancedSettings	boolean	Show advanced tuning options (planning mode, step/time/token limits). The defaults work well for most workflows.	no	false
planningMode	string	react: act as you think. plan: write a numbered plan first, then execute it.	no	"react"
maxSteps	number	Maximum reasoning/tool steps.	no	15
maxRuntimeSeconds	number	Overall wall-clock budget for this node (seconds). The executor kills the node after this time; keep maxSteps and toolTimeout consistent with it.	no	180
maxHistory	number	How many past sessions to keep (workflow memory).	no	20
tokenBudget	number	Total LLM token budget per run (prompt+completion). 0 = unlimited. The agent stops and answers when reached.	no	0
maxToolCalls	number	Hard cap on worker invocations per run. 0 = unlimited. Identical worker+params calls are cached and do not count twice.	no	0
toolTimeout	number	Max seconds a single delegated worker may run.	no	180

Help

Overview

The AI Orchestrator is an autonomous, tool-calling agent that runs inside a workflow. It does not replace your workers — it decides which of the selected workers to call, with which parameters, in which order, and how many times. When it has enough information it writes the final response and returns it in the answer field.

Use it when the task requires reasoning across several data sources, adapting parameters after seeing intermediate results, or producing a written analysis instead of a fixed pipeline.

How it works

1. The node receives your prompt, the selected allowedWorkers, and the run context (workflow variables, current time, previous memory when enabled).
2. Each allowed worker is exposed to the model as a tool, with a JSON schema generated from that worker's parameters_schema.
3. The agent runs a ReAct-style loop: reason, call a tool, observe the result, decide the next step, and repeat. It can retry a worker with different parameters when a result is empty or invalid.
4. The loop stops when the agent writes a final answer or reaches a guardrail: maxSteps, maxRuntimeSeconds, toolTimeout, tokenBudget, or maxToolCalls.
5. The node returns the final answer, the plan, the calls trace, the workers_used list, token usage, and an optional numeric score.

The orchestrator is a normal workflow node. It never starts workflow runs by itself and it does not decide which downstream nodes execute.

Wiring

A typical workflow is:

[Trigger] -> [AI Orchestrator] -> [Telegram / Save to DB / Condition / ...]

• Before it: a trigger or any node that prepares context variables.
• After it: any consumer of the result. Downstream nodes can read vars['Orchestrator']['answer'], plan, calls, workers_used, score, and usage.

Choosing allowed workers

Only real executable workers are exposed as tools. The picker automatically hides:

• trigger category nodes (Schedule, Webhook, List Change, ...),
• visualization category nodes (Table, Chart, Metric, Markdown/widget),
• the orchestrator itself and parameter_loop.

The remaining categories are the useful tool set:

• data connectors — market data, calendars, news, databases, HTTP APIs,
• data processing — Python, SQL, aggregation, sorting/filtering, merging,
• indicators — TA-Lib and custom technical indicators,
• AI — classifier, summarizer, analyzer, and other AI workers,
• flow workers that fetch or transform data (for example http_request, python_exec, fetch_yahoo, aggregate, llm).

Keep the selection small and focused: 5–10 workers is usually enough. A long tool list increases prompt size, cost, and the chance that the model picks the wrong tool.

Configuration

The full parameter table is in the Parameters section above. The most important fields are:

Parameter	What it does
prompt	The task, expected output format, and any constraints.
allowedWorkers	The only workers the agent may call.
memoryScope	run (default), workflow, or none.
advancedSettings	Reveals planning mode, step/time/token limits, and tool tuning.

Advanced settings:

• planningMode: react (act immediately) or plan (write a plan first).
• maxSteps: maximum reasoning/tool steps; default 15.
• maxRuntimeSeconds: wall-clock budget for the whole node; default 180.
• toolTimeout: maximum time for one delegated worker call.
• maxHistory: how many past sessions workflow memory keeps.
• tokenBudget: total prompt+completion tokens per run; 0 means unlimited.
• maxToolCalls: hard cap on worker invocations; 0 means unlimited. Identical worker+parameter calls are cached and do not count twice.

Memory

memoryScope controls what survives between runs:

Scope	Behaviour
run	Memory is available only inside the current run. Nothing is persisted.
workflow	Session history and long-term facts are persisted for this workflow/node/owner and injected into later runs.
none	No memory is loaded or saved.

With workflow scope the agent also gets two tools:

• remember — save a stable fact, convention, data source, or lesson learned.
• recall — search previously saved facts before assuming something.

Memory is keyed by workflowId + nodeId + ownerId, stored in MongoDB collections orchestrator_memories (session history) and orchestrator_memory (facts). Store insights, not transient prices. Example: "CoinGlass funding-rate endpoint is reliable for BTC derivatives" is useful; "BTC is 86,500 right now" is not.

Output

Field	Description
answer	Final written response. This is the main result.
plan	The agent's plan when planning mode is enabled (or its working plan).
calls	Trace of worker calls: worker name, parameters, and a result preview.
workers_used	Unique worker types that were actually invoked.
status	finished when the agent completed normally.
steps	Number of reasoning/tool steps used.
usage	Token accounting: prompt, completion, total, cached, and LLM call count.
score	Optional numeric score extracted from a final SCORE: n line.
error	Error message when the agent failed or produced no answer.

In the node output panel, answer appears as its own one-row answer group next to the calls and workers_used tables. Select calls to inspect the trace and workers_used to see which tools were touched.

Numeric score for branching

Ask the agent to end with a score, for example:

Rate the setup from 1 to 5, where 1 means no signal and 5 means very strong.
Write the analysis, then end with a line exactly like: SCORE: 4

The node exposes score (0 when no score was produced). Put a Condition node after the orchestrator and branch on vars['Orchestrator']['score'] >= 4, then send Telegram only on the true branch.

Examples

1. Market brief

Prepare a short market brief for EURUSD. Cover recent price action, the most
important news from the last 24 hours, and the next high-impact economic
events. End with a clear bias and a confidence score from 1 to 5.

Allowed workers: fetch_price, fetch_rss, browse_calendar.

2. Calendar and news impact

Check the economic calendar for the next 4 days and the latest market news.
Identify the three events most likely to move the Dow Jones. Explain the
direction of the risk and what to watch. Be concise.

Allowed workers: browse_calendar, fetch_rss.

3. Conditional alert

Analyse BTCUSD on the 4h timeframe and the latest crypto news. If the setup is
strong, write a Telegram-ready alert and end with SCORE: n. If there is no
clear setup, answer exactly NO_SIGNAL and end with SCORE: 1.

Then branch on score >= 4 and on answer not containing NO_SIGNAL.

4. Remember a preference

Use the remember tool to save: "For this workflow, always report prices in
EUR and use the London timezone." Then confirm with REMEMBERED.

Run with memoryScope="workflow". Later runs can recall the preference.

5. Multi-step research

1. Fetch the latest prices for the symbols in vars['symbols'].
2. Fetch news for the same symbols.
3. Compare the two sources and highlight disagreements.
4. Return a table with symbol, direction, reason, and confidence.

The agent will call the workers step by step and chain their results.

Limits and cost

• Each tool call is a real worker execution and may consume API credits.
• The LLM loop makes one model call per reasoning step (plus tool results), so maxSteps and maxRuntimeSeconds are the main cost controls.
• tokenBudget and maxToolCalls are hard stops. Use them for scheduled or high-frequency workflows.
• planningMode="plan" adds one planning call but often reduces wasted tool calls on complex tasks.
• Identical worker calls with identical parameters are cached inside the run.

Best practices

• State the output format explicitly: bullet list, table, Telegram message, JSON, maximum length.
• Mention the date range and timezone when relative dates matter.
• Tell the agent what to do when data is missing: retry, use another worker, or answer with a clear limitation.
• Prefer a small, focused allowedWorkers list.
• Use SCORE: n when a downstream Condition node needs to branch.
• Use memoryScope="workflow" only for stable knowledge, not for market snapshots.
• Keep prompts specific. "Analyse the market" is weaker than "compare the last 24 hours of news with the 4h trend for EURUSD and list three catalysts".

Troubleshooting

Symptom	Check
Empty or missing answer	Run status, error, usage.llm_calls, provider configuration, and whether the node hit maxRuntimeSeconds.
Agent does not call a worker	The worker must be in allowedWorkers; its parameters must be described clearly in the prompt.
Wrong or stale data	Add an explicit date range and timezone to the prompt; verify the worker parameters in calls.
Too expensive / too slow	Reduce allowedWorkers, lower maxSteps, set tokenBudget or maxToolCalls, and use react mode.
Trigger or widget missing from the picker	This is intentional: triggers and visualization/widget nodes are not executable tools.
Memory does not persist	Use memoryScope="workflow" and keep the same workflow, node, and owner.