Skip to main content
Arcanflows

The Builder

Describe what you want and the Builder designs and creates tables, forms, agents, workflows, dashboards, tools, and whole apps — for you to review and build

The Builder is a conversational assistant that designs and creates no-code components — data tables, forms, agents, workflows, tools, analytics dashboards, and whole apps — from a plain-language description. Instead of opening each editor by hand, you have a conversation: describe what you need, review the proposed plan, refine it, and click Build to create everything, already wired together.

Open it from the sidebar under Build → Builder (/builder), or from your terminal with arcanflows builder.

How it works

  1. Describe what you need — e.g. "An app for technical support: tickets, an intake form, a triage agent, and SLA escalation."
  2. The Builder replies — it asks a clarifying question if the request is ambiguous, or goes straight to a plan.
  3. Review the plan — each proposed component appears as a card showing what it is and how it connects to the others.
  4. Refine by just talking — "drop the escalation workflow", "add a priority field to tickets", "why do I need a history table?" The Builder answers questions and revises the plan in place.
  5. Click Build — the components are created in the right order and wired together (the form saves to the table, notifies the agent, etc.), with a link to open each one.

Nothing is created until you click Build. The conversation only ever produces a proposal — you are always in control.

Starting from a screenshot or document

You can give the Builder a starting point instead of describing everything:

  • Attach an image or screenshot (a form, a spreadsheet, a sketch) — the Builder reads the text out of it and uses it as context.
  • Attach a document (PDF, Word, text, CSV, Markdown) — its contents become your spec.

Reviewing what it builds — the health check

Right after you Build, each component shows a status. Green means ready; an amber "needs attention" card lists exactly what to fix — for example "charts will render empty until there's data in Orders", "this workflow step still needs a data source selected", or "the form isn't mapped to save into its table." This catches empty or half-wired components immediately. Agents are created as drafts — open each one, pick a model, and finalize it.

Analytics dashboards, with live previews

The Builder can create real analytics dashboards with charts — KPI cards, bar, line, area, pie, and detail tables — bound to your data tables:

  • Along with new tables — "a sales CRM: a Deals table and a dashboard with total revenue, revenue by month, and deals by stage."
  • Over data you already have — "analyze my Orders table and build a dashboard with the key KPIs."
  • From a spreadsheet you upload — click Import data, choose a CSV/Excel file, and the Builder creates a table from it, loads the rows, and proposes a dashboard.

Live previews before you Build: when a dashboard charts data you already have, the proposal card renders the real charts — actual bars, lines, pie, and KPI values from your rows — so you can catch a wrong grouping before creating anything.

Automations (workflows)

When you describe a process — "every morning pull new leads from our CRM, score them, and Slack the hot ones", "when an expense over $500 is submitted, send it for approval" — the Builder models it as a workflow, not one big agent. It breaks the request into steps and picks the right kind of step for each: a tool call for an API/integration, a data step to read or write a table, a branch for a rule, and an AI agent step only where a step genuinely needs to reason. This keeps automations fast, predictable, and cheap — agents are used where they add value, not for everything.

Tools and API integrations

To connect an agent or workflow to an outside service, the Builder creates a tool — and it asks for the real details instead of guessing:

  • REST API / integration — the Builder asks for the API's OpenAPI/Swagger spec (a URL or pasted text) or its docs, plus the auth method, and builds the tool from the real endpoints. Click the plug icon to open the Import API spec dialog: paste a spec, link its URL, or load a file, then pick exactly which operations become tools.
  • Custom logic (script) — it asks the language, inputs, computation, and output shape.
  • Webhook — it asks the direction, payload, and target URL.

The Builder records what auth the tool needs (e.g. an API key in the X-API-Key header) but never the secret value — you enter the actual key once, afterward, in the tool's editor.

Resuming and editing what you built

The Builder remembers your projects. Open History and Open a past project to reload the conversation, then edit by talking:

  • Agents — change the prompt, model, tone.
  • Data tables — add fields.
  • Dashboards — add/change/remove charts.
  • Workflows — "add a step that emails the manager"; the Builder re-drafts the flow while keeping the wiring of the steps that stay.
  • Forms — "add a phone field", "make email required", "reorder so name comes first".

The Builder shows an Update card; click Build to apply the change to the real component — its links and data are preserved.

From the terminal

The same Builder is available in the CLI: arcanflows builder "a contacts table and an intake form" streams the plan and creates it with /build. See the CLI documentation.

For super admins

Under Super Admin → Builder (/super-admin/builder), platform administrators can choose the model the Builder plans with, review or override its behavior, raise the max message length, and see a health panel with the Builder's success/failure rates and top failure reasons.