The expensive part of FluidGrids has never been running a workflow. It is authoring one. You have to know which connector packages exist, its exact operation names, the input fields of the operation you want, which credential adapter it needs, and the precise shape of the definition the builder expects. And there is a nastier trap underneath all of that: the server accepts almost any well-formed JSON, so a workflow that is subtly wrong saves cleanly, reports success, and then does nothing. "Saved" is not "works". Closing that gap is exactly what an agent holding the catalog and a corpus of working examples is for.
The assistant is mounted on every screen of the app as a floating widget, and its Workflow mode is the authoring agent. Every prompt carries the context of where you are: the current URL plus a resolved entity, so the builder route reports the workflow you are looking at, a run page reports the run, a connections page reports the connection, a vault page reports the vault. Static segments that share a shape with detail routes — the new-workflow page, the list page — are deliberately excluded, so the agent never tries to operate on a workflow called "new". You can say "add a Slack step to this one" instead of pasting an id.
Grounding is the whole trick, and it is done in code rather than left to the model. The agent runs a catalog helper that queries the live node registry for every node available in your workspace and, per node, the operations with their real input and output fields. Two things are enforced there that a model gets wrong when left alone: the registry returns node operations in two different shapes depending on how the node was registered, which the helper normalises away; and the Adaptive-Card form specification — roughly half the payload — is stripped out, because a model that reads the form spec emits form element ids where parameters belong, and the resulting workflow saves and silently does nothing. From there the agent mirrors the shape of a reference workflow that is known to execute, then calls the ordinary workflow-creation mutation.
The boundaries are as important as the capability. The agent never invents a node type or an operation name: if the catalog holds nothing for what you asked, the honest answer is that no node exists, not a plausible guess. Credentials never travel from the agent — an authored workflow arrives with its connection slots open, and you are told exactly what to bind before activation. Nothing is auto-activated on your behalf.
Because the result is an ordinary versioned draft, everything else you know still holds. The graph validator, the node palette, and the Adaptive-Card configuration panels all apply. The draft moves through the same DRAFT to ACTIVE lifecycle, every run pins the exact version that executed, and rollback stays one operation. The assistant gives you a first pass that is grounded in your real catalog; the platform keeps every guarantee it had before you asked.
Do it yourself
Ask the in-app assistant for the automation you want — it reads your live node catalog, creates a real versioned workflow, and tells you which connections to bind — then you review, activate, and watch it run.
Open the My Workflows page so the assistant knows which part of FluidGrids you are working in.
You should see: Your workspace workflows are listed, and the floating AI button sits in the corner of the shell.
Ready to make this your story?
