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, dashboard, task, contact, or knowledge base 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 another chat window and hope the refund rule survived the copy.

Where the rail sits

The rail is always on for people with agent.use. It is not buried on /agent. You can talk to it from the inbox, from calls, from the flow builder, from widgets. Viewers never see it — the panel does not render. 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, delay, lookup, and ai nodes. Status is draft, live, or paused. Prefer edit_open_flow or add_flow_steps when the flow editor is already open.
• create_widget, update_widget, get_widget — placement, greeting, starters, attached flow, theme. get_widget reads the object before you restyle it. The install snippet reads the same object.
• create_automation — fires when a conversation is created or resolved. Actions include assign, tag, task, a CSAT line, and knowledge.reply. Trigger and action ids come from the workspace catalog, not from a made-up list.
• create_task — a kanban card, optionally assigned and linked to an existing conversation or client. It does not invent a conversation id.
• save_contact — create or update a person the workspace supports. Conversations and tasks link by email, visitor id, or exact name.
• create_knowledge_base, add_knowledge_source, search_knowledge — a named base of articles, public websites, and uploaded files. Lookup / AI steps and knowledge.reply search it. search_knowledge verifies a source landed.
• create_dashboard — permissioned charts for volume, channel mix, and quality. Custom dashboards sit on Pro and Business.
• list_workspace — flows, widgets, dashboards, automations, tasks, contacts, and knowledge bases already in the workspace so the rail does not invent twins.
• list_mcp_connections — connected actions the automation catalog can call. Discovering new connections requires integrations.manage.

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.

Lookup and ai nodes sit on that same graph. A lookup step can read visitor history, a knowledge base, or both. Knowledge lookups write knowledge.found, knowledge.excerpt, and the related fields so a later condition can branch. An ai step picks a path or writes a reply from those facts and, unless you turn Use knowledge off, from matching sources. They are not a second product. 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.

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. get_widget is how the rail reads theme tokens and custom CSS before it iterates. 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.

Tasks and contacts the rail writes

create_task writes a card on the workspace kanban. You can ask for a title, a teammate, a due date, and a link to an inbox conversation that already exists. The tool looks that conversation up. If you invent an id, the link stays empty. Status is todo, in progress, or done. Priority is low, normal, or high. Opening /tasks is how you see the card, not a second board the rail hid.

save_contact writes a person. Pass an id from list_workspace to update; omit it to create. Name is required. Email, phone, company, location, notes, and tags are optional. Later inbox threads and tasks attach to that contact by email, visitor id, or an exact name match. The rail does not scrape the host page for this. It writes the same contact object the contacts list opens.

Knowledge bases the rail writes

create_knowledge_base writes the same object /knowledge opens. Name is required. Description is optional. Enabled defaults to on. A disabled base still sits in the list; lookup steps, AI steps, and knowledge.reply skip it. Opening /knowledge/{id}/edit is how you see the sources. The rail does not hide a second vault.

add_knowledge_source adds an article, a public website, or an uploaded file. Article and file need the text in content. Website needs the URL as origin and empty content — the tool fetches the page. Localhost and private hosts fail. If no base exists, the tool creates one named Support answers. If you pass an id list_workspace does not know, it tells you to list first. Attach a .txt, .md, .csv, .json, or .html file on the rail and the composer adds it as kind=file. Paste a PDF as an article. search_knowledge is how you check a source landed: it returns titles and excerpts. It does not invent policy.

Only enabled bases with a ready source are searched. A source with no text stays error. Search returns up to five hits. knowledge.reply on an automation posts the first excerpt as a bot line on the inbox thread, or “I could not find that in our help articles.” when nothing matches. That is the same search the knowledge builder preview uses. It is not a second bot.

What still belongs to people

Supervisors still listen, whisper, or barge on a live voice room. 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 voice-room 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. Native actions include assign, tag, task, a CSAT line, and knowledge.reply. You can ask the rail for “when a VIP widget conversation is created, assign a supervisor,” or “when the thread is created, reply from knowledge.” The object it writes is the same automation the manual editor opens. If the trigger or the knowledge base id is wrong, change it there.

The rail can also list connected actions and put those 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. Discovering a new connection is a different door: the discover route requires integrations.manage, which viewers and agents do not have.

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 voice-room 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. You ask the rail for a follow-up task on that conversation, a contact with the email the visitor typed, and a knowledge base from the billing help page. The task and contact open on /tasks and /contacts. The base opens on /knowledge. search_knowledge should return the excerpt you just indexed. 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 or merge 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 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. If no model is configured on the workspace, the rail cannot draft. That is configuration, not a content problem.

Automations are zero on Free, three on Starter, unlimited on Pro and Business. Custom dashboards and custom connections 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 voice-room 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, the trigger, the task card, the contact, or the knowledge sources, 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, write gates, 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 — the panel returns nothing, it is not a disabled composer. inbox.write is separate: agents can reply and resolve. flows.edit, widgets.edit, automations.edit, knowledge.edit, and analytics.edit sit on owner and admin only. Supervisors can listen, whisper, and barge. They do not get the flow canvas or the knowledge builder keys.

That split is enforced on save, not only in the UI. A workspace write compares the previous widgets, flows, automations, dashboards, and knowledge bases to the next ones. If a collection changed and the role lacks the matching permission, the save is a 403. An agent who can talk to the rail still cannot wipe a widget or a knowledge base. The rail drafting either object does not grant widgets.edit or knowledge.edit. If the save fails, check the role before you rewrite the prompt.

integrations.manage is the same kind of gate. Owners and admins have it. Supervisors, agents, and viewers do not. list_mcp_connections can describe what is already connected. Discovering a new connection is a write the role must actually have.