Phase 2: Edit

The Editor is where a compiled draft becomes your workflow. The canvas shows the graph; the rail on the right hosts the editor chat. You can change anything two ways: describe it in plain English, or click a block and work directly. The canvas updates live either way.

Throughout this page we'll use the Order Triage & Fulfilment workflow as the running example: an email trigger, an input and parser, a browser agent that checks the order in an admin portal, and a three-way condition that routes to fulfilment, rejection, or a human review handoff.

Reading the graph

Every workflow is built from a small vocabulary of blocks:

The node inspector

Click any block to open its inspector. Everything the agent will follow at run time is here, in plain language:

• Goal. What this block is trying to accomplish ("Open the order in the admin portal and read its validation status").
• Stop when. The condition that ends the block ("The status and ETA have been captured").
• Hands off. What it passes to the next block.
• Starts at. The page the agent begins on.
• Instructions. The step-level guidance the compiler distilled from your session.
• Active tools. The abilities this block is allowed to use, such as reading and writing workflow variables.

Capabilities

Four toggles give a block extra powers. Each one changes what the block can do at run time:

Detail: Email / OTP polling

The block can watch your team inbox mid-run. At run time this looks like: the agent triggers an email (a login code, a confirmation, an exported report link), then polls the inbox until the message arrives, extracts the code or value it needs, and continues. No human touches anything. Point the sites that send codes at your team inbox address and 2FA stops being a blocker.

Detail: Human in the loop

The block can pause the run and ask a person to drive. At run time: the workflow reaches the step, pauses, and notifies the team. The signed-in user opens the live browser, completes that one step (an approval, an SSO screen, a judgment call), and presses Continue. The run resumes automatically and everything after the checkpoint stays fully automated.

Detail: Datastore retrieval

The block can look up facts in the workflow's uploaded documents. At run time the agent searches the files wired to this block (a price list, a routing table, a policy document) and uses what it finds; it does not see files wired to other blocks.

Detail: Output agent

Marks this block as the source of the workflow's final result. See "Output ownership" below.

Output ownership

Every path through the graph has exactly one output owner: the terminal block whose result becomes the run's result. In the triage example there are three paths, so there are three owners: Fulfil Order owns the result on the approved arm, Notify Rejection on the failed arm, and Manual Review Handoff on the review arm. Whichever path a run takes, its owner produces what you see as the run output, what the API returns, what a reply email contains, and which saved files come back as attachments. If you restructure a branch, make sure each new path still ends in a block with the Output agent capability; the editor will point it out if one is missing.

Comment on a block with the sparkle button

Hover a block and click the sparkle button labeled Ask the editor to edit this block. An Edit block popover opens; type what should change and hit Send. For example, on the Check Order Status block:

Also capture the shipping ETA from the status page and include it in the handoff summary.

Your comment lands in the editor chat already scoped to that block, as an @-mention. You never have to describe which node you meant.

The editor chat

The chat in the rail is a full editing surface. Describe any change and the editor streams its narration and patch summaries while the canvas updates live. A worked example on the triage workflow:

You: Add a duplicate-order check before the status lookup. If the order was already fulfilled in a previous run, skip straight to a notification instead of fulfilling it again.

Editor: (streams) Looking at the graph around Check Order Status... I'll add a lookup step and a condition. Added Duplicate-Order Check (Browser Agent). Searches the portal's order history for the order number and records whether it was already fulfilled. Added Already Fulfilled? (Condition). Routes previously fulfilled orders to Notify Rejection; everything else continues to Check Order Status.

Each "Added / Updated / Removed" line is a patch summary you can expand, and the new blocks appear on the canvas as they're created. When a request is ambiguous the editor asks a clarifying question instead of guessing, and it offers suggestion chips for likely next edits. You can attach up to 4 files to a message when the change needs context.

@ mentions

Type @ in the composer to tag exactly what you're talking about: blocks, parsed inputs, variables, or datastore files. Mentions scope the editor's attention, which makes edits faster and more precise. "Add a duplicate-order check before @Check Order Status" leaves nothing to interpretation.

The variable store

The Variable store drawer is the data view of your workflow: everything that flows between blocks, in three sections.

• User request. The free-text launch request the parser reads at run time (for example, "Which order should be triaged?").
• Parsed inputs. The typed fields the parser extracts, such as order_number (string). Add, rename, or retype them here. You can also bind a credential key to a field so it resolves from Passwords instead of the launch form.
• Workflow variables. Typed values and files that agent blocks write and read to pass results forward, such as order_status. Read/write counts show you what's actually used.

Inside block prompts you'll see three reference styles:

So a block instruction like "Open the order inputs.order_number in the admin portal and write its status to @order_status" reads exactly the way it runs.

The workflow datastore

The Workflow datastore drawer holds reference files the workflow can consult at run time: price lists, policy documents, lookup tables. It accepts PDF, text, Markdown, CSV, JSON, HTML, XLS, and XLSX. You can create new Markdown, text, or CSV documents in place, Upload from your machine, or Import from Data Integrations such as OneDrive.

Files don't attach to the whole workflow blindly. You wire them to specific blocks through the Datastore retrieval capability, which lists the files that block is allowed to read. A pricing agent can read the price list; the rejection notifier doesn't need to.

Adding blocks by hand

You don't have to chat for structural changes. The Add block menu inserts a new block after the one you've selected:

• Agent block. A general browser agent step.
• Email poll agent. Waits on the team inbox for a message or code.
• Human review agent. A checkpoint where a person drives.
• Datastore agent. A step focused on reading workflow documents.
• Output agent. A terminal block that owns the final result.
• Condition block. A new decision point.

Wiring, versions, and recompiling

Three more tools live in the editor toolbar:

• Edit edges. A toggle that unlocks the graph wiring so you can drag new connections between blocks or remove edges directly. Useful when you're restructuring branches and want precise control over what flows where.
• Versions. Every Save and Publish creates a version snapshot. The Versions dropdown lists them with their changes ("8 blocks added"); load one to review it on the canvas, expand it to read the change list, jump Back to latest, or publish a historical version if a newer edit went wrong.
• Recompile from trace. Rebuild the graph from the original Builder session. Useful when edits have drifted and you want a clean start from the demonstration.

---

When the graph reads the way you want, move on to Phase 3: Test & Iterate.