Build a workflow from an agent

Ask a connected AI agent to build or change a whole workflow in one call — what apply does, how the answer reads, and how to get back to where you were.

An agent connected through the platform connector can build a workflow for you, not just run one somebody else built. It reads the same slim YAML you would write by hand and applies it in a single call.

You do not learn a new format for this. The definition an agent sends is the definition on Author a workflow as YAML and in the YAML reference — the one dibbla wf reads.

What you ask for

Talk about the workflow, not the tool. A useful request names the trigger, the steps and where the result should go:

Build me a workflow called incident_triage that takes a question over HTTP, sends it to the reasoning agent, and returns the answer. Then run it once with a test question.

The agent will look at what functions exist, write the definition, apply it, and tell you what it made. Changing it later is the same conversation:

Add a step that posts the answer to Slack, and keep everything else.

What “apply” does

The agent sends the whole workflow, not a patch. The stored workflow becomes exactly what the definition says, which means a step the definition leaves out is removed. This is deliberate: it is why the agent never has to keep a half-finished sequence of edits straight, and why the same request twice cannot produce a different result the second time.

Before anything is saved, the entire graph is checked. A cycle, an edge pointing at a step that is not there, a missing input or an unknown step type refuses the whole apply and names the place in the definition. There is no partly saved workflow to clean up: either the change happened or nothing did.

The answer you get back reads like a change description rather than a database row:

Workflow incident_triage updated: 4 step(s), 3 connection(s).
Run it with platform_workflow_execute through Start.
Added:
  - step "Post to Slack" (agent running slack_post)
  - connection reasoning_agent_function -> post_to_slack
Changed:
  - step "Summarize" (agent running reasoning_agent_function): model changed
Revision 7f2a holds the workflow as it was before this apply.

Every apply leaves a revision behind holding the workflow as it was before the change, so “put it back the way it was” is always available:

That is not what I meant — go back to the previous version.

The agent restores that revision, and the restore itself leaves a revision, so changing your mind twice is fine.

What an agent cannot do here

• Carry a secret into the graph. A definition references credentials and data sources by name. One that embeds a credential value is refused before it reaches the engine, so a key cannot end up stored in a workflow — or in the model’s context — by way of an apply.
• Touch another organization’s workflows. A workflow outside your organization answers exactly the way a name that never existed does, for reading and for writing alike.
• Keep working after you revoke access. Access is checked on every call, so withdrawing the grant in the Console stops the next change, not the one after some cache expires.
• Edit a graph piece by piece. There is no “add a node” or “connect these two” tool. Everything goes through one apply, which is what makes a change atomic and reviewable.

Turning it on

Building workflows needs a workflow write scope, which is not part of the default read-only consent. When an agent first tries to build something, you will be asked to approve that access in the browser. Running a workflow is a separate scope again — granting write does not grant execute, and neither implies the other. The platform capability contract names the exact scope each operation asks for.