The AI assistant in the editor

The assistant builds and edits the scenario for you: you describe the task in words, it proposes a set of changes, you apply or discard them. You are not limited to describing nodes: “I run a shop, what could I automate?” is a task for it too.

The AI Assistant button on the right of the toolbar collapses and expands the panel. Drag its edge to resize; on narrow screens it becomes an overlay drawer. A viewer does not see the button at all: the assistant edits the scenario, and a viewer only reads it.

app.iterna.ai

Customer support

Scenario Assistant

Describe what to build…

Auto
Add an agent with a 10-message memory and wire up web search
Looking at what is already on the canvas: entry, exit and one LLM node.
Adding ai_agent, buffer_memory and websearch, linking them with link edges.
▍
Describe what to build…➤

How a turn can end

The assistant used to answer every message the same way — by starting to build. A turn now ends in one of three ways, and it picks which one from your message:

  1. It built — the ordinary case. The request names a concrete change, however roughly (“add an LLM node”, “make a bot that answers from our documents”); small gaps are filled with sensible defaults, and it says which ones it chose.
  2. It asked — when it genuinely cannot proceed: the task names a goal but not where messages arrive from or where the answer goes; or it needs an id it cannot see (a knowledge base, a connection). At most two questions, often with ready-made answers — click one and it is sent as your message.
  3. It proposed a plan — when the request is a business goal rather than a graph, or the change is large. It describes in words what the scenario will do end to end and then stops: nothing changes until you press Build this plan. Change the plan just puts the cursor back in the composer.

If it stops without finishing — rounds exhausted, the same errors coming back, the model answering too slowly — it now says so and suggests what to do. That used to be silence.

How to phrase a task

Write what you would tell a colleague: which node you need, where it should be wired, what the output should look like. Or simply describe the task in your own words — “take requests from the website and send them to Telegram”. Enter sends the message, Shift+Enter inserts a newline.

An empty conversation offers a few ready-made examples: clicking one puts it in the composer but does not send it — a request spends quarks, and that call stays yours.

Along with your text the assistant receives:

  • the current canvas graph — unsaved edits included;
  • the selected nodes, so “fix this node” resolves to concrete ids when you selected it on the canvas beforehand;
  • the last few messages of this conversation;
  • a sample of the input data — the entry envelope of a recent run, so the assistant uses real field names instead of guessing them.

What you see while it works

The turn streams, and blocks of several kinds appear in the conversation:

  • reasoning — italics with a rail; when a turn was a single answer that changed nothing, the answer is printed as ordinary text rather than as muted narration;
  • actions — monospace rows with a tick or a cross: these are its tool calls (add a node, change a config, look up a node type, read a past run);
  • auto-repair — an amber block listing what was fixed mechanically;
  • error — a red block with a Retry button.

While the turn runs, the dot next to the panel title pulses and the send button is replaced by Stop. When the assistant is working but printing nothing — calling tools, checking the graph — a line says what it is doing instead: “Thinking”, “Editing the scenario”, “Checking”, “Fixing”. The bin icon next to the checkbox clears the conversation.

The conversation is kept in the browser and survives a page reload — otherwise a thread in which you had already answered a couple of questions would be lost whole. It belongs to one scenario: open another and you start from a clean slate.

Auto-repair and validation

After every round the assistant validates its working graph against the strict rule set — the same one that gates deployment. Some findings have a single mechanical fix; those the assistant applies itself and reports in an Auto-repair block instead of spending a round on them.

It also has its own debug run: it can execute the graph on the real engine with external and paid nodes stubbed out, to check its own work. That run is not billed and is allowed at most three times per request.

The change preview

When the assistant proposes an edit, a Proposed changes block appears above the input box — a line-by-line list.

app.iterna.ai

Customer support

Proposed changes

ApplyDiscard
Change
+ Node: AI Agent (ai_agent)
+ Node: Buffer memory (buffer_memory)
~ AI Agent: system_prompt=You are a support assistant…, max_iterations=8
+ Connection: Buffer memory [memory_out] → AI Agent [memory]
− Connection: Model reply → Exit

Nodes and connections are named as they are labelled on the canvas, not by identifier. Lines that belong to a concrete node are clickable: the click focuses the camera on it. For a config change the fields and their new values are listed, not just the fact that something changed.

Apply moves the changes onto the canvas. Discard throws the proposal away and leaves the graph as it was.

When the assistant builds a graph almost from scratch (the canvas held only an entry and an exit), a single auto-layout pass runs after the apply — otherwise the new nodes would land in a pile.

Auto mode

The Auto checkbox (“Auto-apply changes without confirmation”) removes the confirmation step: every proposal goes straight onto the canvas and you watch the graph assemble as the answer streams. The setting is remembered in the browser.

The mode is convenient while building a new scenario from scratch, where you are going to review the result as a whole anyway. For edits to a working graph leave it off, so every change passes through your review.

Test runs from the panel

Two buttons in the panel header run the scenario without leaving the conversation:

  1. Mock run — executes the graph with external and paid nodes stubbed out.
  2. Test run — a real run; it asks for confirmation, because it may send messages, call paid models and spend quarks.

Both are disabled while there are unsaved edits: the run executes the saved version, so otherwise you would be testing a graph other than the one you see. The run id lands in the conversation — you can then ask the assistant to look into that run, since it has tools for reading runs and the inputs and outputs of individual nodes.

Where to next