Text to Workflow: Build Automation with AI

TL;DR: Text to workflow converts a plain-English description of a task into a runnable automation pipeline. An AI model generates structured JSON (the workflow DSL) that maps your description to typed nodes, wired connections, and data references. Heym's AI Canvas implements this with two distinct modes: Agent (builds and modifies the canvas) and Ask (answers questions without touching it). This guide explains how DSL generation works, walks through a five-step build process, and shows three real-world examples.

Key Takeaways:

• Text-to-workflow generation works by prompting an LLM with your natural language description plus the platform's full node-type schema, then applying the resulting JSON to the visual canvas
• The workflow DSL is a JSON graph of typed nodes (textInput, llm, http, agent, loop, output) and edges — a language the AI reads and writes as fluently as prose
• Heym's AI Canvas has two modes: Agent builds and modifies the canvas; Ask answers questions without changing it
• The AI can modify an existing workflow by reading the current canvas state and producing an updated graph that preserves unchanged nodes
• Text-to-workflow excels at first-draft generation and iterative refinement; manual canvas building stays better for precise handle wiring and isolated node debugging

Table of Contents

• What Is Text to Workflow?
• How AI Generates a Workflow from Text
• The Workflow DSL: What the AI Actually Produces
• Agent Mode vs Ask Mode
• How to Build a Workflow from Text in Heym
• Real-World Text-to-Workflow Examples
• Text-to-Workflow vs Manual Canvas Building
• Limitations and When to Build Manually
• Key Takeaways
• FAQ

What Is Text to Workflow?

I lead platform development at Heym — an AI-native workflow automation platform with a visual canvas for building multi-step AI pipelines — and have shipped text-to-workflow generation as a first-class feature inside the canvas editor. The patterns in this guide reflect what we have learned from hundreds of real workflow generation sessions. This guide is for developers and technical teams who want to understand how AI workflow generation works and how to get reliable results from it.

Definition: Text to workflow is a technique where a language model converts a natural language description of a task into a structured automation pipeline. The AI produces a machine-readable workflow definition — nodes, connections, data references, and configuration — that a workflow engine can execute directly. The input is a sentence or paragraph in plain English; the output is executable automation.

The concept is straightforward in principle: you describe what you want to automate in plain English, and the AI builds the pipeline. In practice, the reliability and usefulness of the output depend entirely on how the AI is instructed. A general-purpose LLM given a vague prompt produces vague JSON. A workflow platform that trains its AI on the exact node types, expression rules, and validation constraints of its own engine produces workflows that run on the first attempt.

The critical insight: A text-to-workflow system is only as reliable as the schema it has learned. Platforms that encode their complete node type specifications, expression syntax, and validation rules into the AI's system prompt generate workflows that execute correctly the first time. Generic LLMs without this context produce structurally plausible but functionally broken automation JSON.

Text-to-workflow sits at the intersection of LLM orchestration and developer tooling. It is a specific application of LLM generation where the target format is not prose or code, but a directed graph of typed automation steps. The same techniques that make prompt chaining reliable — focused system prompts, strict output schemas, constrained generation — are what make an AI workflow generator trustworthy.

The value proposition is clearest for three scenarios. First, when you have a verbal or written description of a process (a support ticket triage SOP, a content publishing checklist, a lead enrichment sequence) and want to convert it to a runnable pipeline without starting from a blank canvas. Second, when you want to explore several pipeline architectures quickly before committing to one. Third, when a non-engineer stakeholder can describe what they want in words but cannot translate it to nodes and edges themselves.

How AI Generates a Workflow from Text

The generation process has three components working together: the system prompt, the user message, and the output parser.

The system prompt is the most important component. It defines every node type the platform supports — textInput, cron, llm, agent, http, loop, set, variable, output, and the full set of event triggers (slackTrigger, imapTrigger, telegramTrigger, webhookTrigger). For each node type, the system prompt specifies: its purpose, how many inputs and outputs it has, what data fields it accepts, what downstream expressions it exposes, and any absolute constraints (for example, output nodes may never appear inside a loop body — this is a hard rule the AI must follow).

The system prompt also teaches the AI the platform's expression syntax. In Heym, $nodeName.field references a specific field from any upstream node. Template strings mix prose with references: "Customer $userInput.body.name submitted a request". The AI must learn to generate these references correctly across all node configurations, which is why the expression rules are embedded in the system prompt rather than left to the model's general training.

The user message is your natural language description. The AI receives your text alongside the current canvas state (if any). If the canvas already has nodes, the AI reads the existing graph and produces an updated version that incorporates your new instruction while preserving what you did not ask to change.

The output is a JSON workflow definition. The platform parses this JSON, validates it against the node schema, and applies it to the visual canvas — placing nodes at calculated positions, drawing edges, and populating each node's configuration panel with the generated values.

How it works in one sentence: The AI reads your description + the node schema → produces JSON → the canvas renders the graph.

This is why text-to-workflow generation in a dedicated platform is more reliable than asking a general LLM to produce workflow JSON. A general LLM does not know your platform's reserved names, expression syntax rules, or output node constraints. A purpose-built system prompt encodes all of those rules and the model applies them consistently.

The Workflow DSL: What the AI Actually Produces

Definition: A workflow DSL (Domain-Specific Language) is a structured JSON format that describes an automation pipeline as a directed graph. Each node declares its type (such as llm, http, agent, or loop), a camelCase label used to reference its output downstream, and a data object with its configuration. Edges connect nodes by their IDs to define execution order and data flow.

DSL stands for Domain-Specific Language. In the context of workflow automation, the workflow DSL is the structured format that describes a pipeline as a graph. Heym's DSL is JSON. Here is a complete, minimal example: a customer support email classification workflow.

{
  "nodes": [
    {
      "id": "n1",
      "type": "textInput",
      "position": { "x": 100, "y": 200 },
      "data": {
        "label": "supportEmail",
        "inputFields": [{ "key": "emailBody" }]
      }
    },
    {
      "id": "n2",
      "type": "llm",
      "position": { "x": 400, "y": 200 },
      "data": {
        "label": "intentClassifier",
        "systemPrompt": "Classify the customer email into one of: billing, technical, general. Return only the category name in lowercase.",
        "userPrompt": "$supportEmail.body.emailBody"
      }
    },
    {
      "id": "n3",
      "type": "output",
      "position": { "x": 700, "y": 200 },
      "data": { "label": "classifiedIntent" }
    }
  ],
  "edges": [
    { "id": "e1", "source": "n1", "target": "n2" },
    { "id": "e2", "source": "n2", "target": "n3" }
  ]
}

Three things to notice in this DSL:

Node labels use camelCase. Labels must follow camelCase convention and cannot use reserved system names. The label is also how downstream nodes reference the output: $intentClassifier.output would access the LLM's classification result in a subsequent node.

The expression $supportEmail.body.emailBody wires data across nodes. The body accessor is how textInput fields are accessed when the workflow is called via API. The AI must generate these references correctly for each node type — the rules differ between textInput, http, llm, and other node types.

Output nodes appear only at the end. The DSL enforces that output and jsonOutputMapper nodes are never placed inside a loop body. The AI's system prompt contains this as an absolute constraint, and the workflow validator enforces it at runtime.

For more complex pipelines, the DSL scales to include loop nodes (with sourceHandle: "loop" and sourceHandle: "done" edges), parallel branches drawn by connecting one source to multiple targets, and agent nodes with tool configurations. The graph structure remains the same regardless of complexity — nodes and edges, each with a type and configuration.

Agent Mode vs Ask Mode

Heym's AI Canvas panel has two distinct operating modes, toggled at the top of the panel.

Agent mode generates and modifies the workflow canvas from a natural language prompt. The AI produces workflow JSON, which you review and apply with one click. It reads the current canvas state so it can refine an existing workflow as precisely as it creates a new one.

Ask mode answers questions about the current workflow conversationally without generating DSL output or modifying any node or edge. Use it to understand node behavior, debug expression syntax, or explore restructuring options before committing to a change.

Agent mode is the text-to-workflow mode. When you type a description and submit in Agent mode, the AI generates a full workflow JSON and offers to apply it to the canvas. It has access to your current workflow state, so it can also receive modification instructions: "add a Slack notification step after the classifier" or "replace the output node with a webhook POST to our CRM." Agent mode only writes to the canvas when you explicitly click Apply.

Ask mode is a read-only conversational mode. In Ask mode, the AI can see your workflow but will not generate DSL output or modify the canvas. Use Ask mode to understand what a node does, debug an expression that is not resolving correctly, or get advice on how to restructure a pipeline before committing to changes. Ask mode responds in plain language only.

The practical workflow is: use Ask mode to think through a problem, then switch to Agent mode to implement the solution. This prevents accidental canvas modifications while you are still exploring options.

The shift toward AI-assisted automation creation is accelerating. McKinsey's Technology Trends Outlook 2025 identifies AI-enabled workflow automation as a top-priority technology investment for enterprise engineering teams (McKinsey Global Institute, 2025). The pattern we observe in Heym aligns with this: teams use Agent mode to generate first-draft workflows and Ask mode for iterative refinement, treating both modes as complementary rather than alternatives.

How to Build a Workflow from Text in Heym

Step 1: Open the AI Canvas assistant

Screenshot: Heym's AI Canvas panel slides in from the right side of the editor. The mode toggle (Agent / Ask) is visible in the panel header alongside the model selector.

Open any workflow in the Heym editor. Click the sparkle (AI) icon in the canvas toolbar to open the AI Canvas panel. The panel slides in alongside your workflow without obscuring the canvas. You will see a model selector, the mode toggle (Agent / Ask), and a chat input at the bottom.

Step 2: Select Agent mode

Toggle the mode switch to Agent. The label changes from Ask to Agent and the input field updates its placeholder to indicate it is ready to build. If you are modifying an existing workflow, the AI will see the current canvas state automatically — no need to describe what is already there.

Step 3: Describe your workflow

Write a clear description of the pipeline you want. The more specific you are about triggers, data sources, processing steps, and outputs, the closer the first-draft JSON will be to what you need. A strong description includes:

• Trigger: What starts the workflow? (User sends a text message, a new email arrives in a support inbox, a cron job fires every morning at 8 AM)
• Processing: What transformations or AI steps are needed? (Classify the intent, extract key fields, call an external API, run a sub-agent)
• Output: What should the workflow return or do? (Return a JSON summary, send a Slack message, POST to a webhook, write to a database)

Example prompt: "Create a workflow triggered by an inbound email. Use an LLM to extract the sender's name, company, and the main question they are asking. Return a structured JSON object with those three fields."

Step 4: Review and apply

The AI streams the workflow JSON to the chat panel. Before clicking Apply, read through the node labels and edge connections to verify they match your intent. Pay attention to expression references — confirm that $nodeName.field patterns point to the correct upstream nodes.

Click Apply. Heym parses the JSON, validates it, and renders the nodes and edges on the canvas. LLM and Agent nodes inherit your current credential and model selection from the panel if the AI used placeholder values.

Step 5: Test and refine with follow-up prompts

Run the workflow with a test input. The execution trace panel shows each node's inputs, outputs, and timing. If a step produces an unexpected result, use a follow-up prompt in Agent mode to refine: "The classifier sometimes returns 'Technical Support' with capital letters and spaces — normalize the output to lowercase with underscores before it reaches the output node."

The AI reads the current canvas state and produces an updated workflow that adds or modifies only the nodes relevant to your instruction.

Real-World Text-to-Workflow Examples

Example 1: Lead qualification pipeline

Prompt: "Build a workflow that receives a lead's company name and job title. Use an LLM to score the lead from 1 to 10 based on ideal customer profile fit, and return the score with a one-sentence rationale."

Generated structure: textInput (two fields: companyName, jobTitle) → llm (ICP scoring prompt with $leadInput.body.companyName and $leadInput.body.jobTitle references) → output. Three nodes, two edges, ready to run in under a minute.

Example 2: Scheduled content digest

Prompt: "Create a workflow that runs every morning at 7 AM. Fetch the top 5 posts from a news API endpoint, summarize them with an LLM, and send the summary to a Slack channel."

Generated structure: cron (7 AM daily) → http (GET news API) → llm (summarization with $newsData.body reference) → http (POST to Slack webhook). The AI sets the cronExpression field to "0 7 * * *" and wires the HTTP nodes correctly without additional instruction.

Example 3: Multi-step document processing

Prompt: "Build a workflow that accepts a document as text input. First extract all named entities (people, organizations, locations). Then for each organization, run a web search to get a brief description. Collect all descriptions in a variable and return the final enriched report."

Generated structure: textInput → llm (entity extraction, returns structured JSON) → loop (iterates over organizations) → http (web search per organization) → variable (accumulates descriptions) → loop back-edge → output (on done branch). The AI correctly places the output node on the done branch of the loop, not inside the iteration path — applying the hard constraint from its system prompt.

These examples show that text-to-workflow generation handles both simple linear pipelines and multi-step branching structures. The quality of the first-draft output scales with the specificity of the description.

Text-to-Workflow vs Manual Canvas Building

The most productive approach combines both: use AI generation for first drafts and structural changes, use manual editing for fine-grained configuration.

Limitations and When to Build Manually

Text-to-workflow generation is a productivity accelerator, not a replacement for understanding the underlying platform. There are scenarios where manual building remains more effective.

When the pipeline has non-standard connection handles. Some node types expose multiple output handles (a loop node has a loop handle and a done handle; an if-else node has true and false handles). The AI generates these correctly in common patterns, but unusual branching logic benefits from direct canvas manipulation where you can see exactly which handle connects where.

When you are debugging a single node in isolation. If one node in a ten-node workflow is producing unexpected output, isolating and testing that node manually is faster than describing the debugging scenario to the AI.

When the generation requires integration-specific credential IDs. The AI uses placeholder values for credentials and model selections. You will always need to fill in real credential IDs and confirm model selections in the node panel after applying a generated workflow.

When the workflow description is ambiguous. If the task has multiple valid interpretations, the AI picks one and proceeds. Manual building forces you to make every structural decision explicitly, which reduces ambiguity for complex pipelines.

For agentic AI systems with autonomous tool use and memory, text-to-workflow handles the structural skeleton well. The fine-tuning of agent system prompts, tool selection, and memory configuration typically requires manual editing after the initial generation.

Key Takeaways

• Text to workflow converts a natural language description into a JSON workflow DSL that a canvas engine executes directly
• The reliability of AI workflow generation depends on the system prompt encoding the platform's complete node schema, expression rules, and validation constraints
• Heym's DSL is a JSON graph: an array of typed nodes (textInput, cron, llm, agent, http, loop, output) and an array of edges connecting them by node ID
• Agent mode generates and modifies the canvas; Ask mode provides conversational analysis without touching the workflow
• The AI reads the current canvas state when generating modifications, preserving unchanged nodes and updating only what you described
• Combine text-to-workflow generation for first drafts and structural changes with manual editing for precise configuration and debugging

FAQ

Related reading: What Is AI Workflow Automation? covers the fundamentals of workflow automation platforms. LLM Orchestration: A Developer's Guide explains the orchestration patterns that power multi-step AI pipelines. How to Build an AI Agent walks through building a complete autonomous agent from scratch. Multi-Agent AI Systems explores how multiple agents coordinate in production. Best AI Agent Builders in 2026 compares the leading platforms for teams evaluating their AI workflow generator options.