The conversational builder

The conversational builder lets you describe what you want an agent to do in plain language, then translates that description into a working node graph — tools wired up, prompts drafted, and a run ready to test.

How it works

You describe the agent's job: what it should do, which systems it needs to touch, and what a good outcome looks like. The builder reads that description and configures the underlying agent: it selects tools (code_execution, api_call, knowledge_search, connector_action, mcp tools, subagent delegation), sets up the system prompt, and adds any connectors you mention.

The result is the same node graph you'd get from wiring things by hand in the canvas — the conversational builder is a faster way to produce it, not a separate execution model. Everything it creates is visible and editable afterward.

When to use it

Use the conversational builder when:

• You're starting from scratch and don't yet know exactly which tools or nodes you need.
• You want to move fast and are comfortable refining the result afterward.
• The agent's logic is straightforward enough to describe in a few sentences (a support triage agent, a data-lookup assistant, a scheduled report generator).

It's less suited to agents with intricate branching logic or precise node-by-node control — for that, drop into the canvas directly.

Iterating

Configuring an agent through chat isn't a one-shot action. You can keep the conversation going:

• Ask for a tool to be added or removed ("also let it search the knowledge base before answering").
• Ask for a connector to be wired in ("send the summary to Slack instead of email").
• Ask for the approval behavior to change for a destructive action.
• Point out something wrong after a test run and ask for a fix.

Each instruction updates the node graph incrementally rather than rebuilding it from scratch, so earlier configuration you're happy with is preserved.

How it maps to the node graph

Every choice you describe in chat becomes a concrete, inspectable piece of the node graph:

• A tool you mention becomes a tool node with its arguments and validation schema.
• A condition you describe ("only escalate if the customer is on the enterprise plan") becomes branching logic between nodes.
• A destructive action you call out becomes a node behind an approval gate, so the run halts and asks a human before it executes.
• A data source you reference becomes a connector or knowledge-base node.

Because the conversational builder and the canvas produce and read the same graph, you can move freely between the two: start a conversation to scaffold an agent, then switch to the canvas to fine-tune wiring, add a node the conversation didn't cover, or inspect exactly how a tool call is configured. Changes made in the canvas are reflected back if you return to the conversation, since both are views onto the same underlying agent.

Testing as you go

After each round of configuration, run the agent and watch it work. The agentic harness executes your instructions as a real multi-turn tool-calling loop — the model picks tools, arguments are validated, and destructive actions pause for approval — so what you see in a test run is exactly how the agent will behave once deployed. If a run doesn't do what you expected, describe the gap in chat and let the builder adjust the configuration rather than editing nodes manually.