> ## Documentation Index
> Fetch the complete documentation index at: https://helpcenter.magure.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Build with AI

> Describe a workflow in plain language, review the generated plan, and synthesize a runnable workflow onto the canvas

<Info>
  **Beta.** Build with AI (Autobuild) is available in MagOneAI Studio as a beta feature and is under active development. The two-step generate-then-synthesize flow described here works today; behavior and coverage will continue to expand.
</Info>

## Purpose

**Build with AI** (also called Autobuild) turns a plain-language description into a working workflow. You write what you want the workflow to do, it produces a reviewable build plan, and once you approve it, it synthesizes a runnable workflow onto your canvas in [MagOneAI Studio](/platform/magone-studio).

It is a starting point, not a black box. Autobuild never publishes anything from a prompt alone: the plan is a human checkpoint you read and edit before a single node is created, and the synthesized workflow lands as a draft you can inspect, adjust, and run like any hand-built [workflow](/workflows/overview). Autobuild is grounded in what your project already has: it reads your real MCP tool catalog and knowledge bases, so it reuses existing tools instead of inventing ones that don't exist.

## How it works

Autobuild runs in two turns with a review step in between: generate a plan, then synthesize it.

<Steps>
  <Step title="You describe the workflow">
    You write a natural-language prompt describing what the workflow should do. The prompt is bounded (up to 8,000 characters) and treated as untrusted input, sandboxed before it reaches the model.
  </Step>

  <Step title="A plan is generated">
    Autobuild drafts a build plan: a summary, the interface type (`form`, `chat`, or `hybrid`), the input fields, the capabilities it needs, the agents to create, and the ordered steps. Generation is grounded in your project's actual MCP tool catalog and knowledge bases so it reuses what already exists.
  </Step>

  <Step title="The plan is validated and repaired">
    Before you ever see it, the plan runs through a validate-and-retry loop. Autobuild checks that agents have names, roles, and instructions, that inputs resolve, that referenced knowledge bases exist, and that the plan can actually be built. If a check fails, it regenerates with the exact issues as feedback until the plan is sound or it gives up (rather than handing you a plan that looks fine but won't build).
  </Step>

  <Step title="Capabilities are matched to tools">
    Each capability in the plan is matched against your project's MCP tool catalog. Confident matches become tool bindings. Anything that can't be matched to a real tool is reported as missing, with a copy-paste build spec for the MCP server you'd need to add.
  </Step>

  <Step title="You review and edit the plan">
    Nothing is persisted yet. You read the plan, adjust it, and decide whether to proceed. This is the cheap checkpoint before any nodes, agents, or versions are created.
  </Step>

  <Step title="The plan is synthesized onto the canvas">
    When you approve, Autobuild maps the plan into agents and a workflow definition, validates it against the same gates as a manual canvas save, lays it out as positioned, connected nodes, and persists it as a draft use case with an `autobuild` version snapshot.
  </Step>
</Steps>

<Note>
  The generate step is bounded by a total time budget (180 seconds). If a slow model run exceeds it, Autobuild returns a `timeout` result instead of hanging the request, and no partial workflow is created.
</Note>

## How to use

### Write the prompt

Describe the outcome you want, the inputs the workflow will receive, and any tools or knowledge it should use. The more concrete you are about inputs and the desired output, the closer the first plan lands. Autobuild picks the interface type for you: a `form` workflow for structured inputs, `chat` for a conversational assistant, or `hybrid` for both.

### Review the plan

The generate step returns a plan without saving anything. Each plan carries:

| Part             | What it is                                                                      |
| ---------------- | ------------------------------------------------------------------------------- |
| `summary`        | A one-line description of what the workflow does                                |
| `interface_type` | How users interact with it: `form`, `chat`, or `hybrid`                         |
| `input_schema`   | The input fields the workflow accepts                                           |
| `capabilities`   | The external actions it needs (each matched to a tool or flagged missing)       |
| `agents`         | The agents to create, with role, instructions, and any attached knowledge bases |
| `steps`          | The ordered nodes and how they connect                                          |

The result also carries a status that tells you what you're looking at:

| Status        | Meaning                                                                                          |
| ------------- | ------------------------------------------------------------------------------------------------ |
| `ok`          | Plan built and every capability maps to an existing tool. Ready to synthesize.                   |
| `needs_mcp`   | Plan built, but some capabilities need MCP servers you don't have yet. Build specs are included. |
| `partial`     | Plan built, but capability matching failed. The plan is still returned for review.               |
| `plan_failed` | Autobuild could not produce a valid plan from the prompt.                                        |
| `timeout`     | Generation exceeded the time budget. Try again or simplify the prompt.                           |

<Warning>
  A `needs_mcp` result means the workflow depends on a tool that isn't connected in your project. Add the [MCP server](/tools/overview) from the included build spec before synthesizing, otherwise those capabilities land unbound and the agents that need them won't be able to act.
</Warning>

### Synthesize the workflow

Approve the plan to synthesize it. Autobuild creates one agent per planned agent, wires the steps into a workflow definition, and validates the whole thing against the same rules a manual save enforces. If validation fails, nothing is committed, so a bad plan never leaves a half-built workflow behind.

By default the workflow is saved as a **draft**, so you review it on the canvas before it goes live. You can opt into publishing it immediately, but the safe default keeps a human between the prompt and a live workflow. Every synthesis is recorded as a workflow version marked `autobuild`, so the provenance is always visible in the version history.

### Rebuild an existing workflow

Autobuild can also target a workflow that already exists rather than always creating a new one. Applied this way, it replaces that use case's workflow with the newly synthesized one and rebuilds its agents; the previous workflow is preserved as a version snapshot you can restore. This is the co-pilot path for regenerating a workflow from an updated description.

<Note>
  Autobuild covers `agent`, `tool`, `conditional`, and `respond` steps today. `parallel` and `foreach` steps are not synthesized yet, so build those by hand on the canvas after synthesis if your workflow needs them.
</Note>

## Use cases

### Bootstrap a new workflow from a description

**Scenario:** You know the outcome you want but not the exact node layout.

```
Prompt:
  "Take an uploaded invoice, extract the vendor, amount, and due date,
   check it against our approved-vendor list, and flag anything unmatched
   for a human to review."

Autobuild:
  1. Generates a plan: form interface, one extraction agent, a lookup
     capability, a conditional step, and a human review step.
  2. You review and tweak the agent instructions.
  3. Synthesize -> draft workflow on the canvas, ready to test.
```

### Discover the tools a workflow needs

**Scenario:** You're not sure which integrations a workflow requires.

Autobuild matches each capability against your connected tools and returns a `needs_mcp` result listing exactly what's missing, with a build spec for each one. You add those MCP servers, regenerate, and get an `ok` plan.

### Regenerate a workflow after the requirements change

**Scenario:** An existing workflow's scope has grown and you'd rather restate it than re-wire it.

Point Autobuild at the existing use case with an updated description. It rebuilds the workflow in place and keeps the old version as a snapshot, so you can compare or roll back.

## Best practices

<AccordionGroup>
  <Accordion title="Be specific about inputs and outputs">
    Name the inputs the workflow receives and describe the result you want. Concrete inputs and a clear target output produce a tighter first plan and fewer review cycles.
  </Accordion>

  <Accordion title="Connect tools before you generate">
    Autobuild reuses the MCP tools and knowledge bases already in your project. Connect the integrations you expect the workflow to need first, so capabilities bind to real tools instead of coming back as `needs_mcp`.
  </Accordion>

  <Accordion title="Treat the plan as the real review point">
    The plan is the cheap checkpoint before anything is created. Read the agents, steps, and capabilities carefully and edit there, rather than synthesizing a rough plan and untangling it on the canvas.
  </Accordion>

  <Accordion title="Keep the draft default, publish deliberately">
    Leave synthesized workflows as drafts and run them yourself before publishing. Auto-publishing skips the human check that keeps a prompt from becoming a live workflow.
  </Accordion>

  <Accordion title="Add parallel and foreach by hand">
    Autobuild synthesizes agent, tool, conditional, and respond steps. If your workflow needs [parallel](/workflows/parallel-node) branches or a [foreach](/workflows/foreach-node) loop, add those on the canvas after synthesis.
  </Accordion>
</AccordionGroup>

<Tip>
  Use Autobuild to get from a blank canvas to a working first draft in one pass, then refine it like any other workflow. It scaffolds the agents, wiring, and tool bindings; the canvas is still where you tune instructions, add branches, and test before publishing.
</Tip>

## Next steps

<CardGroup cols={2}>
  <Card title="Workflow overview" icon="diagram-project" href="/workflows/overview">
    Understand how workflows execute once Autobuild has built one
  </Card>

  <Card title="MagOneAI Studio" icon="pen-ruler" href="/platform/magone-studio">
    The builder portal where you generate, review, and refine workflows
  </Card>

  <Card title="Agent node" icon="robot" href="/workflows/agent-node">
    Tune the agents Autobuild creates for each step
  </Card>

  <Card title="Tools overview" icon="wrench" href="/tools/overview">
    Connect the MCP tools capabilities bind to
  </Card>
</CardGroup>