Agents

Agents is where automations grow beyond a single browser task. On the Agents page you describe what you want in plain English, and a builder agent assembles it on a live canvas: API calls, Python or TypeScript code, LLM steps, tool-using agents, loops, waits and approvals, and your existing published browser workflows as callable steps inside the same graph.

Agents vs. browser workflows

The two surfaces are complementary, not competing:

A browser workflow is the hands; an agent is the plan. The most common pattern is exactly that: an agent fetches records from an API, loops over them (running a browser workflow for each), post-processes the results with code, and delivers the output by email. Every browser workflow you've published is available to your agents as a ready-made step.

One word, two meanings

Inside an agent, some individual blocks are themselves agents: a tool-using agent step, or a one-off browser agent. When these docs say "an agent" on its own, they mean the whole automation you build on the Agents page.

Building is a conversation

There's no drag-and-drop palette to learn. You brief the builder the way you'd brief a colleague, it adds nodes one at a time onto the canvas while you watch, and it narrates as it goes. Each change comes with a per-node "changes made" summary, so you always know exactly what was added, what was updated, and what was deliberately left alone.

The builder tests as it builds

The builder doesn't work blind. It can execute individual steps with sample inputs while you chat, checking that an API call returns what it expects or that a code step produces the right shape, and it can kick off a full sandbox run when you say "try it". You see the results inline in the chat.

A worked example

Here is the whole lifecycle of one real automation, built entirely in chat. It starts with a single brief:

Get ten ABC numbers from an API, run my Create JODL DS Order in Zoho browser workflow for each, build a CSV, and email it to me.

What the builder assembles

The builder reads the brief, then places blocks one at a time, narrating each one. For this brief it builds six:

Step 1

Trigger. A manual/scheduled trigger, so the automation can run from the Run button today and move onto a schedule later without any rework.

Step 2

Inputs. A typed input block. The builder notices "ten" is a choice, not a constant, and makes the count an input with a default of 10.

Step 3

Fetch ABC Numbers. An API Call block: one GET request to the endpoint, returning the list of records to process.

Step 4

Loop. A for-each loop over the fetched records. Inside the loop sits the Create JODL DS Order in Zoho browser workflow block: your published workflow, run once per item, with each record's fields mapped to the workflow's inputs.

Step 5

Build CSV. A Python code step that takes the collected loop results and turns them into a CSV file.

Step 6

Email CSV Report. An output block that delivers the final result by email, with the CSV attached.

Along the way the builder inspects the published workflow's contract (its exact input fields and outputs), so the loop wiring matches reality instead of guesswork. It also test-runs the deterministic steps as it places them.

Here is the finished pipeline on the canvas, published and ready:

Asking for a change

Changing an automation works the same way as building it. There's no separate edit mode; you just keep talking. Suppose the loop results came back with a different field name than the CSV step expected. You'd say something like:

Inspect the saved browser workflow contract and fix the repeated workflow input mapping to use its real required field. Keep the API, loop concurrency, CSV, and email behavior unchanged.

The builder replies with a per-node "changes made" summary. In the screenshot above you can see the reply in the right rail: a table with one row per touched node ("Input mapping corrected", "Output schema updated", "Column list updated to match what the workflow actually returns"), followed by an explicit Unchanged list confirming that the API endpoint, the loop's concurrency of 3, and the email delivery were left exactly as they were.

That unchanged list matters as much as the changes. You never have to diff the graph yourself to be sure an edit didn't quietly touch something else.

Other change requests work the same way:

• "Make the loop parallel, three items at a time."
• "Email the CSV to ops@ instead."
• "If the API returns nothing, skip the loop and tell me."

The builder's model

A model picker above the composer lets you choose which RamAIn model tier powers the builder: a faster tier for quick edits, a deeper tier for complex pipelines.

This affects how the automation is built; individual LLM and agent steps inside the graph are configured separately.

Around the canvas

The header carries the whole lifecycle:

• New starts a fresh automation from a blank canvas.
• Run opens the run dialog: fill in inputs, attach files, and choose a sandbox run or a live run.
• Publish promotes the draft to a published automation, exactly like workflows. Publishing enables live runs and activates its triggers.
• Runs / Canvas flips between the graph and this automation's run history.
• The automation picker (the dropdown on the automation's name, top-left) switches between your automations and starts new ones.

Automations follow the same Draft to Published lifecycle as browser workflows. You can sandbox-test a draft as much as you like; live runs and email/schedule triggers wait until you publish.

Where to go next

Building Blocks

Every block type on the canvas: triggers, API calls, code, agents, loops, approvals, and more.

Running, Sandbox & Fixes

Sandbox vs. live runs, the run history, approvals, and how failed runs self-heal into proposed fixes.

Browser Workflows

Build the browser tasks your agents will orchestrate.

Triggers

Start automations manually, on a schedule, from an email, or through the API.