Workflow generation lets you describe a multi-step agent process in plain language and receive a structured, reviewable workflow graph in return. You type what you want — "when a support ticket arrives, classify its urgency, route it to the right specialist, and escalate if it's critical" — and the system produces a draft with real nodes and edges on the canvas. You review and adjust; nothing runs until you save and trigger it deliberately.
The problem with blank-canvas authoring
Building a non-trivial workflow on a visual canvas requires you to know exactly which agents exist, what each accepts, what valid transition conditions look like, and how to sequence parallel and serial branches. For an operator who has built many workflows, this is routine. For someone new to the platform, or for a team that wants to quickly prototype before committing to full authoring, the blank-canvas problem is real and the cost shows up as friction.
When authoring requires detailed upfront knowledge, fewer people attempt it. Engineers prototype while business teams wait, and the workflows that get built tend to replicate existing patterns rather than explore new ones. Lowering the floor on initial authoring changes who can participate in workflow design — which matters as AI agent deployments expand beyond a single technical team. For teams who prefer to start from a validated structure rather than generating from scratch, reusable workflow templates provide a complementary on-ramp.
How generation works
The generation flow is asynchronous by design. When you submit a prompt from the "Chat to Build" dialog, the system accepts the request immediately and returns a job identifier. The actual language model call runs asynchronously, so your session is not blocked waiting on a potentially slow provider response. Progress updates arrive in real time — the dialog reflects the job moving through its states as the platform processes it.
When the job completes, the output is a graph: typed nodes representing agents or logic steps, and edges representing transitions, along with a generated title and description. That graph loads onto the canvas for you to inspect, adjust, and save. Nothing is committed or activated automatically.
If the job fails — because the prompt was too ambiguous, because the model returned output the system could not parse, or because the request timed out on the provider side — the dialog surfaces the error and lets you revise your description and try again.
Grounding generated nodes in your real agents
A generation that produced generic placeholders would be of limited value. The system resolves which agents are active in your organization and includes them in the context sent to the model. Generated nodes therefore reference agents that actually exist and are reachable in your environment, not invented identifiers you would need to manually replace.
This reflects a straightforward design goal: a generated workflow should be runnable after review, not a skeleton that requires rebuilding. The draft will still need your attention — you may want different routing logic, different edge conditions, an added approval step — but you are editing from a meaningful starting point rather than from nothing.
LLM configuration and cost attribution
Workflow generation uses the same model configuration layer that governs the platform's other LLM-powered features. If your organization has configured a bring-your-own-key (BYOK) provider and set it as the default, generation uses that provider and its associated key. This matters for organizations with data-residency requirements or negotiated agreements with a specific provider: generation does not route around those arrangements.
Token usage from generation is metered and attributed. Cost is recorded in the same credit ledger as agent task spend, so generation activity appears in your cost monitoring view alongside everything else. There are no shadow calls that bypass attribution or bypass the configured provider.
What to check before saving a generated draft
AI-generated workflow drafts are a starting point, not a finished product. Before saving and activating a generated workflow, a few things are worth reviewing explicitly:
Agent assignment. The model selected agents based on the names and metadata it was given. Verify that the agent assigned to each node is the one you intended and that its capabilities match what the step requires.
Transition conditions. Edges can carry conditions that determine when a downstream node runs. Review whether the generated conditions reflect your actual routing logic, especially for branches that handle error cases or escalations.
Missing steps. Natural-language descriptions frequently omit steps that feel obvious in context. A prompt like "classify and route" may not mention a notification step or an audit log entry that your real process requires. Add those before activating.
Spend limits and guardrails. Generated workflows inherit the organization's default budget and guardrail policies, but they do not automatically configure per-run spend limits for the specific workflow. If the workflow will invoke agents that interact with sensitive data or incur significant cost, set explicit per-run limits before the first real execution. See Budget Policies: Hard Spend Caps for AI Agents for how per-workflow caps work.
Humans stay in the loop by design
The generation feature is built around a deliberate division of responsibility: the model handles structural translation from intent to graph, humans handle intent verification and policy alignment. This boundary is not a workaround — it is the correct design given what language models can and cannot guarantee.
A generated workflow can reference the correct agents, sequence steps plausibly, and produce a syntactically valid graph while still being wrong in ways that matter: the wrong agent assigned to a sensitive action, a missing approval gate, a condition that routes incorrectly on an edge case. These failures are not rare model errors; they are predictable consequences of the model lacking full context about your organization's risk tolerance, operational policies, and downstream dependencies.
The approach Praesidia takes is to surface this boundary explicitly. The generated graph is presented as a draft requiring a review step before it can be saved and activated. There is no "generate and run" path that skips the canvas. The canvas is where the model's structural output and your domain knowledge meet. A focused review after generation — checking agent assignments, edge logic, missing steps, and spend configuration — takes a fraction of the time full authoring would require and catches the issues that matter.
Generation as part of a broader workflow practice
Generation is most useful for initial drafts and for exploring new workflow shapes quickly. Once a design is reviewed and validated, it can be saved as a template — a reusable pattern that other teams can clone and adapt without going through generation again.
The generation-to-template path is how good patterns spread: one team generates and refines a workflow for a specific use case, then publishes it as a template; other teams start from the validated version rather than from a blank canvas or from a fresh generation run. See Reusable Workflow Templates for how to publish and manage those shared patterns. This also changes how you should think about the prompts you write. A description that reliably produces a useful draft for a complex multi-branch workflow is itself a reusable asset. Teams that maintain a small library of well-specified prompts can regenerate or adapt workflows quickly as their agent roster or process requirements evolve. For guidance on how to trigger, monitor, and iterate on workflows once they are live, see executing and monitoring workflow runs.
Common questions
Does generation replace the visual canvas?
No. Generation produces a draft that lands on the canvas. The canvas remains the place where you review, adjust, and finalize before anything runs. Some operators use generation for initial drafts and then switch to canvas editing for iteration; others generate a new draft whenever they want to explore a significantly different structure. The two modes complement each other.
Can I use generation if I have a BYOK LLM configuration?
Yes. Workflow generation uses the organization's configured default LLM provider, which includes any bring-your-own-key provider you have set up. Token usage is attributed to your organization in the standard cost ledger, subject to the same cost monitoring and budget policies as other LLM spend.
What happens if generation times out on my end?
The generation job continues running on the backend even if the client-side dialog times out. The job's result is available for retrieval once it completes. If you close the dialog before receiving the result, you can return to the generation flow to check the status. The system retains the generated graph once the job reaches a terminal state, so the work is not lost if your session is interrupted.
For more on the visual canvas where generated drafts land for review, see designing AI workflows on a visual canvas.