A workflow is a named, reusable procedure saved onto an agent. It teaches Zero how your team does a specific kind of work, so the next person who needs it doesn't have to rewrite the prompt.
The first time you ask Zero to do something, you write a prompt. The second time, you paste the same prompt with small tweaks. By the third time, you're copying a long prompt out of a Notion doc someone called the "team prompt library." That's the moment to save a workflow.
The problem workflows solve
A one-off chat is fine for a one-off task. But almost every team has a backlog of work that recurs — different inputs, same shape:
- A customer writes in → look up their history → draft a reply in their language → log the ticket
- A bug report appears → extract repro steps → classify severity → file a structured issue
- Monday morning → pull last week's numbers → compare to the week before → post a digest
Without workflows, each of these is a 200-word prompt everyone has to remember. With workflows, each is a name: triage-bug-report, weekly-metrics, customer-reply.
A workflow on its own has no schedule and no trigger — it's the procedure. To make it run on its own, attach an automation.
What's in a workflow
| Field | What it does |
|---|---|
| Name | Lowercase, hyphenated, unique on the agent — triage-bug-report. This is what you type to invoke it explicitly. |
| Display name | The human-readable label shown in the workspace. |
| Description | One line telling Zero when this workflow applies. Zero matches incoming requests against descriptions, so phrasing matters. |
| Instruction | The procedure itself. Plain prose works — mention the tools to use, the output shape, and any constraints. |
| Files | Optional supplementary files — templates, checklists, brand guidelines, reference data — bundled with the workflow. |
| Visibility | private (only you) or public (everyone in the workspace). |
No node graph, no YAML config, no triggers section. The instruction usually looks a lot like the chat prompt that worked the first time.
A good description is the difference between a workflow that fires when it should and one that never fires: "triage a customer-facing bug report and file it to GitHub with severity" is better than "do bug stuff."
Workflows belong to agents
Every workflow belongs to exactly one agent. That's what makes behavior predictable: the workflow runs with that agent's tone, defaults, and connector grants.
- Private workflow — visible only to you. Right for personal automations tied to a personal Gmail or personal CRM seat.
- Public workflow — visible to everyone in the workspace, on an agent your team can reach.
The same procedure can live on two agents and produce different results, because each agent brings its own voice and its own permissions. To hand a workflow to another agent, copy it — this forks it, so the two can then diverge.
See Agents for how agent ownership shapes what a workflow can touch.
Creating a workflow
From a chat that already works. The fastest path — get the result you want in a chat first, then say:
"Turn the last conversation into a reusable workflow called
triage-bug-report. Make the description tight."
Zero reads back the conversation, extracts the procedure, proposes a description, saves it to the agent, and tells you the name to use later.
From scratch. Open the Workflows page in your workspace and write the instruction directly. Useful when you already know the shape and don't want a dry run first.
Either way, you can edit the instruction, swap the files, change the description, or flip visibility at any point afterwards.
How Zero picks a workflow
You don't have to invoke a workflow by name. Zero loads one automatically when an incoming request matches its description. A workflow called customer-reply-draft described as "draft a reply to a customer email using our voice and docs" fires when you forward a customer email — no name required.
To force a specific one, say so: "Use the customer-reply-draft workflow on this email."
Built-in workflows
Every Zero agent ships with a roster of cross-functional workflows maintained by VM0 — research and analysis, finance and accounting, legal and compliance, product, marketing, customer support, and team communication. They're domain procedures, not connector plumbing: each teaches Zero how to handle a recurring kind of work.
A sampler:
deep-dive— structured research and solution design; gather facts, then explore optionsprd-writing— product requirements with structured problem framing and acceptance criteriacopywriting— marketing copy across channels (blogs, emails, social, landing pages)competitor-matrix— feature comparison matrices, positioning teardowns, win/loss analysiscustomer-reply— empathetic, on-brand replies tailored to channel and urgencynda-screening— classify incoming NDAs as GREEN / YELLOW / RED and route themstatus-updates— progress reports and stakeholder updates tailored to any audience
Your own workflows sit alongside these and take precedence when their descriptions match more closely.
When to make one
The honest rule: if you've written substantially the same prompt more than twice — or you can imagine a teammate writing it — save it.
Concrete signals:
- The work has a name your team already uses ("morning brief," "competitor scan")
- The prompt names specific tools, channels, or templates that shouldn't change every run
- The output has a fixed shape (a digest, a draft, a filed issue)
- More than one person needs to trigger it
- You want it to run on a schedule or an event — see Automations
Common patterns
- The intake form. Takes a piece of input (an email, a bug report, a thread) and produces a structured artifact (an issue, a draft, a row).
- The cadence brief. A workflow paired with a scheduled automation that runs daily or weekly and posts somewhere visible.
- The mid-conversation helper. Triggered by
@Zeroin a channel to do one focused subtask — look up, summarize, classify. - The composer. Produces a multi-format bundle — blog draft plus social posts plus cards — in one run.
- The event responder. Paired with an event automation: a new email, a merged PR, or a new Notion page starts the run. See Automations.
Pitfalls to avoid
- Too narrow. A workflow that only fits one specific input is brittle. Aim at the shape of the work, not the details of one example.
- Too vague. "Help with marketing" is so broad Zero won't know when to apply it. Be specific in the description.
- Hardcoded credentials. Never paste API keys into an instruction. Use custom connectors instead — the credential stays on the platform, out of the model's reach.
- Buried output shape. State what the artifact should look like: "a numbered list of three items" or "a draft reply under 150 words."
- Forgetting the agent. A workflow can only use the connectors its host agent is authorized for. If a workflow can't reach Gmail, check the agent's Authorization tab, not the instruction.
What's next
- Attach a trigger with Automations so a workflow runs without you.
- See Agents for who runs a workflow and with which permissions.
- See Permissions for restricting what a workflow can touch.
- See Example workflows for five written end to end.