Visual Workflow Studio
Visual Workflow Studio lets you design agentic workflows visually, composing the steps an agent takes, while every action step remains governed by Gateway. It turns the zero-trust model into something you can build and see, and review, before it runs.
What it is for
Section titled “What it is for”Agentic work is usually a sequence: gather context, reason, call a tool, check a result, write back. Workflow Studio lets you lay that sequence out as steps rather than code, so governance and business teams can understand and shape what an agent does, not just engineers.
The building blocks
Section titled “The building blocks”A workflow in Studio is assembled from a small set of governed objects, each held in Agentic CISO and each carrying its own policy:
| Object | What it is |
|---|---|
| Workflow plan | The overall design: the ordered steps an agent will take. |
| Workflow step | A single step. Action steps reference a governed connector by tool name. |
| Toolset | A named bundle of connector adapters with allowed actions and allowed data classes, gateway-enforced, with approval required for high-risk actions. |
| Skill | A reusable capability: instructions plus the toolsets it may use, with input/output contracts and a “no direct provider calls” policy. |
| Checkpoint | A saved, resumable state with a rollback policy, so long-running work can pause and resume inside the trust boundary. |
Toolsets and skills both default to gateway-enforced and start in a pending approval state,
so a capability is not usable until it has been reviewed and approved.
Governed by construction
Section titled “Governed by construction”A workflow built in Studio does not bypass the agentic stack. Each step that takes an action references a governed connector by its tool name, and that call is subject to the same checks as any other:
- The step’s tool must be permitted to the agent in Agentic CISO.
- Gateway must allow the action type, context and payload, and must be within the agent’s ATF level boundary.
- Any required approval gates must be satisfied, and high-risk toolset actions carry their own approval requirement.
So a visual workflow is as governed as a hand-written agent. The design surface changes; the enforcement model does not.
Runtime backends
Section titled “Runtime backends”A workflow targets a registered runtime backend, either Gamut Claw or, for external frameworks, a BYO runtime. Backends are themselves governed: they default to a deny network posture, no raw secret mounts, and gateway-only egress. A backend with direct egress or mounted provider secrets is not how Gamut runs agents. In every case the rule holds: think anywhere, act through Gateway.
Checkpoints and resumable work
Section titled “Checkpoints and resumable work”Long-running or multi-stage workflows can save checkpoints, a captured state summary with a rollback policy that requires approval to roll back. Checkpoints let work pause and resume without ever leaving the governed boundary, and they are retained under an assessment-lifecycle retention policy by default.
Why it matters
Section titled “Why it matters”Visual workflows make agentic governance legible. Reviewers can see exactly what an agent is designed to do, step by step, the toolsets and skills it draws on, and the approvals it must clear. The runtime evidence from Gateway then shows what it actually did, closing the gap between design and behaviour.
- Agentic stack overview: how the pieces fit together.
- Connector catalog: the tools workflow steps can call.
- Gamut Claw: a runtime backend workflows can target.