An AI support agent that builds the workspace

Heliune’s builder agent is not a second inbox. It lives in the right rail while you are already in a thread or on a call. You describe the object; tool calls write a flow, widget, automation, or dashboard into the workspace.

Those objects are the same ones the manual builders edit. If the draft is wrong, you open the flow or widget editor and change it. The agent does not sit in front of the source of truth. It does not paste a ticket into ChatGPT in another window and hope the refund rule survived the copy.

Where the rail sits

The rail is always on. It is not buried on /agent. You can talk to it from the inbox, from calls, from the flow builder, from widgets. The conversation you are looking at stays on the page. The draft lands as a workspace object you can open.

That is the difference between a builder and a copilot tab. A copilot tab consumes the ticket and emits text. The rail consumes a description and emits a flow with nodes, or a widget with an install snippet, or an automation with a conversation.resolved trigger.

What a tool call can create

• create_chat_flow — trigger, message, condition, action, handoff, and delay nodes. Status is draft, live, or paused. Prefer edit_open_flow or add_flow_steps when the flow editor is already open.
• create_widget and update_widget — placement, greeting, starters, attached flow, theme. The install snippet reads this object.
• create_automation — fires when a conversation is created or resolved. Actions include assign, tag, task, and a bot line.
• create_dashboard — permissioned charts for volume, channel mix, and quality. Custom dashboards sit on Pro and Business.
• list_workspace — flows, widgets, dashboards, automations already in the workspace so the rail does not invent twins.
• list_mcp_connections — connected MCP actions the automation catalog can call.

Flows the rail drafts are still graphs

A chat flow is nodes on a canvas. Live is the only status that answers a public widget. Draft is safe to edit. Paused keeps the graph without serving it. The runner records a flow run on the conversation: success or failed, step by step, last fifty on the flow.

If the rail puts a refund condition on the wrong edge, open the flow builder and move it. The widget that attached that flow will use whatever you saved as live. There is no shadow graph the visitor sees instead.

Widgets the rail drafts still install

create_widget writes the same config the widget builder shows: floating, page, or pane; panel, popup, or sidebar; pre-chat none, greeting, starters, or the first live flow step. update_widget patches that object. Copying Install is still a person in the workspace clicking a button.

Free workspaces get one widget and keep the Heliune mark. The rail cannot hide the mark on Free. Paid plans drop it. That is billing, not a prompt.

What still belongs to people

Supervisors still listen, whisper, or barge on live voice. Roles still decide who can change automations and dashboards. The rail drafts; the team keeps the keys. A builder message budget sits on each plan — 25 on Free, 100 on Starter, 400 on Pro, 1200 on Business — and extra packs exist when you run out.

Voice minutes are a different entitlement. The rail can draft a flow while a supervisor is on listen. It cannot invent listen on a Free workspace that has no voice minutes. The call page and the LiveKit token still decide who publishes.

How to ask it

Name the object. “Draft a widget that opens in a pane and starts the billing flow” is a tool call. “Help me sound nicer” is not. If you are already on the flow editor, say what to change on the open graph. list_workspace first when you are not sure the object exists.

The rail will be wrong sometimes. That is why the manual builders exist. A workspace where only the agent can edit is not this product. A workspace where the agent writes objects you can open is.

Automations the rail drafts still need a trigger

create_automation does not watch a vibe. It watches conversation.created or conversation.resolved on an inbox thread. You can ask the rail for “when a VIP widget conversation is created, assign a supervisor.” The object it writes is the same automation the manual editor opens. If the trigger is wrong, change it there.

The rail can also list MCP connections and put those actions on an automation. That is still a workspace object, not a secret side channel. If the connection is missing, list_mcp_connections says so. Do not invent a Slack post the workspace cannot send.

What not to ask

Do not ask it to be the customer. The inbox thread is for the visitor. Do not ask it to barge on a call — listen, whisper, and barge are supervisor modes on the LiveKit token, not rail tools. Do not ask it for a case study. It has none. Ask it to build the next object, then open that object.

If the rail wrote a dashboard you cannot see, check the role. Permissioned analytics are not a prompt failure. They are the same permission the rest of the workspace already uses.

A worked example

You are on an inbox thread from a widget. You tell the rail: draft a pane widget for billing, attach a live flow that asks for the order id, then hand off. The rail calls create_widget and create_chat_flow. You open both objects. The handoff edge is wrong. You move it in the flow builder, save live, copy Install, put the pane iframe in the billing page.

The next visitor types an order id. The flow run shows on the flow and as an inbox event. Handoff sets pending. You reply in the same thread. That is a finished loop. The rail did not “handle the ticket.” It built the objects the ticket now uses.

If you had stayed in another model’s tab, you would have a paragraph about refunds and no widget id. The install snippet would still be empty. This page exists so that difference is obvious before you sign in.

edit_open_flow versus a new graph

If the flow builder is already open, the rail should call edit_open_flow or add_flow_steps so the canvas updates. create_chat_flow on an open editor is how you get a twin nobody asked for. The system prompt on the rail says the same thing. If you see a second draft flow after a small edit, you asked the wrong tool.

add_flow_steps appends nodes to the open graph. edit_open_flow can rename, rewrite the description, change status, and replace nodes. Neither tool publishes the public widget by itself. Live is still a save you confirm. A draft graph can sit next to a live one. Only live answers.

Action nodes on a graph fail closed when the integration or MCP is missing. The run records “Connect the integration or MCP for this step.” That is not a mysterious model error. It is the runner telling you the workspace cannot execute that id.

Budgets the rail cannot talk past

Builder messages are 25 on Free, 100 on Starter, 400 on Pro, and 1200 on Business. Extra packs are 500 messages. When the budget is gone, the rail stops drafting. It does not silently switch to another model. Anthropic Claude is the default; OpenAI is fallback only if the workspace is configured that way.

Automations are zero on Free, three on Starter, unlimited on Pro and Business. Custom dashboards and custom MCP sit on Pro and Business. The rail can still list_workspace on Free. It should not write a custom dashboard the plan cannot store.

Voice minutes are a different meter: none on Free and Starter, fifty on Pro, two hundred on Business. The rail can draft a flow while a supervisor is on listen. It cannot mint listen on a workspace with zero minutes. The LiveKit token still decides who publishes.

What a stranger should do with this page

If you are comparing “AI support agents,” ask whether the agent writes workspace objects you can open. If it only drafts email replies, it is a copilot. If it only chats with the visitor, it is a bot. This rail is a builder. The visitor still talks to the inbox and, when a room exists, to the person on the handset.

Sign in. Leave the rail open. Ask it to list_workspace. Then ask it to draft one object you already know you need. Open that object. If you cannot find the nodes, the install snippet, or the trigger, the draft failed. Rewrite the ask. Do not paste the answer into another tool.

The rest of the site can sell a feeling. This note is the inventory: rail tools, manual builders, plan caps, and the rule that live is a save state. Keep those names. Drop the rest.

Roles the rail does not override

agent.use is what opens the rail. Owners, admins, supervisors, and agents have it. Viewers do not. inbox.write is separate: agents can reply and resolve. flows.edit, widgets.edit, and automations.edit sit on owner and admin only. Supervisors can listen, whisper, and barge. They do not get the flow canvas keys.

That split is easy to miss. A supervisor can sit on a room and talk to the rail. They still cannot save a live graph unless someone with flows.edit opens the builder. The rail drafting a widget does not grant widgets.edit. If the save fails, check the role before you rewrite the prompt.

The default model is Anthropic Claude (claude-sonnet-4-5) when ANTHROPIC_API_KEY is set. OpenAI gpt-4.1 is the fallback when Anthropic is missing. If both keys are missing, getBuilderModel returns nothing and the rail cannot draft. That is configuration, not a content problem.