Wireflow has four things that look alike, because they are all made of boards. They do different jobs.

	Workflow	Blueprint	Project folder	Team playbook
What it is	Your board. Nodes, wires, outputs.	A frozen snapshot of a workflow's nodes and wires, taken when it was published.	A folder on the Files page holding one client's or project's workflows, including its brief.	Workflows tagged playbook: your team's rules as document nodes, next to example outputs.
Use it for	Doing the work.	Reusing a finished setup: a character, a brand kit, a proven method.	Keeping a client's brief, brand notes and pipelines together.	Rules that apply to all your work.
Changes when you edit it	Yes, it is live.	No. Editing the source board does not touch it until it is republished.	Yes.	Yes, it is a live workflow.
Who can create one	Anyone.	Wireflow admins only, today.	Anyone.	Anyone who can tag a workflow (API only today).
Status	Shipped.	Shipped.	Shipped. Agents read a folder's docs with get_project_context.	Shipped. Agents read it with get_project_context.

How agents read the playbook and project folders: Team Playbook and Project Folders. Later parts (an "Add to playbook" action, a content calendar, a format scoreboard) are tracked in #2185.

Workflow: where you work

A workflow is the canvas you build and run. One made in your personal workspace is private until you share it (invite someone, share its folder, or set a view or edit link). One made in a team workspace belongs to that team. Everything else on this page starts as a workflow. See Creating Workflows.

Blueprint: a frozen, forkable snapshot

A blueprint is a copy of a workflow's { nodes, edges } frozen at publish time. Runtime state is stripped from it. Later edits to the source board do not change the blueprint until someone republishes it.

Browse them at /blueprints. Each blueprint page gives you two ways to use it.

Fork to canvas

Fork to your canvas copies the snapshot into your account as a new workflow and opens it at /flow/<id>. The copy is yours. Edit anything, it does not affect the blueprint or anyone else's copy.

Use this when you want to start from someone's setup and change it.

Add to an existing workflow (the blueprint:invoke node)

Add to an existing workflow drops the blueprint into a workflow you own as a single Blueprint node (blueprint:invoke). You wire it like any other node.

How the node behaves:

• Its ports are worked out per blueprint, from that blueprint's own input and output nodes. Two Blueprint nodes can have completely different ports.
• When the run reaches it, the frozen snapshot runs inside your run. Paid nodes inside it charge credits to the person running the parent workflow, per node.
• An input port you leave unwired uses the value baked into the blueprint. You only wire what you want to change.
• A node the author pinned when publishing serves its saved output instead of running again, at zero credits.
• There is no separate run record for the nodes inside the blueprint, so you see the Blueprint node's result, not a step-by-step log of its insides.

Use this when you want the finished result of a setup inside a bigger board, without copying its nodes.

The same two actions exist for agents: the REST API has POST /api/v1/workflows/{id}/blueprints, and the MCP connector has add_blueprint_to_workflow.

Context blueprints

A blueprint can also be published with the context role. A context blueprint never runs and never bills. Placed on a board, it is a visible record of what the agent should know (a brand's voice, banned phrases, its logo), and the in-app chat agent reads it when you chat on that board. It has no ports, so nothing can be wired to it.

Who can publish

Publishing a blueprint (POST /api/blueprints, POST /api/v1/blueprints, or publish_blueprint over MCP) is limited to Wireflow admins today. If you built something worth publishing, send us the workflow id.

Blueprint use cases

Characters: a face and voice "Passport"

A Passport is one board that pins down a recurring person so every later video uses the same face and voice.

1. Identity refs. Generate or upload a small set of reference stills of the person: a front view, a three-quarter view, and a close crop of the face. Keep only takes you approve.
2. Voice clone. Add a Fish Voice Clone node, give it a clean recording, and run it. It outputs a voice_id you wire into Fish TTS. Over MCP, prepare_voice_clone sets up the same thing from an uploaded recording.
3. Recipe. Add a document node that says how to use the Passport: which refs to pass to which model, framing that holds the likeness, what not to do.
4. Use it. Fork the board for a new video, or have it published as a blueprint and add it to each new board as a Blueprint node. With the approved stills pinned at publish, every use serves the same images at no cost instead of generating new ones.

A face and a voice identify a real person. Read the privacy note below before this leaves your account.

Brand kits: logo, colors, fonts, end card

1. Put the logo on the board as an image input node.
2. Write the colors (hex values) and fonts into a document node, along with tone and any banned words.
3. Build the end card once: logo, tagline and call to action on a compositor or video node.
4. Reuse it: fork the board per campaign, or have it published and add it to other boards as a Blueprint node so the end card is one wire away. Published with the context role, the kit is read by the chat agent instead of run.

To start from a live site, the New brand from URL button on the Files page reads the site and builds a brand board in its own folder. For a client, that folder is a natural project folder.

Recipes: a proven method

A recipe is a blueprint that carries its method in writing: one or more document nodes that say what worked, what failed, and why. A trend format is a good example: the shot order, timing, caption style and the models that handled it, with the board that produced it right there.

1. Build the format on a workflow until it works.
2. Add document nodes with the method. Write down the failures too, they save the next person the credits.
3. Have it published as a blueprint.

Agents find recipes over MCP: search_recipes searches titles, descriptions and the text of the method pages, and get_recipe returns every method page in full. A blueprint with no document node is not a recipe and does not show up there.

Privacy: keep characters and brand kits private

Character and brand blueprints should be private, or visible to your team only. Here is exactly what ships today:

• Every usable blueprint is public. The publish routes create public blueprints. Anyone can see, fork and add a public blueprint.
• Private blueprints exist but are inert. An admin can mark a blueprint private. Its creator and admins can still read it, but it cannot be forked, added to a workflow or run by anyone.
• Team-scoped blueprints are not shipped yet. They are in review (#2033): a team blueprint would be visible and usable only by members of its team.

Until team blueprints ship, keep a Passport or a brand kit as a workflow, not a blueprint. Made in your personal workspace, a workflow stays private until you share it, and you can share it with specific people by invite or by sharing its folder. Never publish a real person's face or voice as a public blueprint.

Project folder: one client or project

Folders already group workflows on the Files page. A folder belongs to a workspace, so a folder in your team workspace is visible to the whole team, and you can also share a folder with specific people or by link. Sharing a folder shares the workflows in it.

Use one folder per client or project, and keep its brief with the work:

1. Create the folder in your team workspace.
2. Add a workflow for the brief: the brief itself, brand notes and voice notes as document nodes.
3. Move the project's workflows into the folder.

Tag the brief's workflow brief (tags are set through the API today: PUT /api/v1/workflows/{id} with a tags array). Agents then read the folder as one piece of context with the get_project_context MCP tool: the team playbook first, then the folder's docs, then its workflows and their outputs. See Team Playbook and Project Folders.

Team playbook: rules every agent follows

The team playbook is a normal workflow tagged playbook. The rules are document nodes on the board, placed next to example outputs that show what good looks like. No new object to learn: if you can edit a board, you can edit your playbook. Keep it in a folder in your team workspace: that is what makes it the team's playbook. Inviting someone to the board does not.

Agents read it with the get_project_context MCP tool, so they follow your rules without being told each time. It covers your own boards plus ONE team, your active team (the one the Files page shows) unless the agent passes another team you belong to; details in Team Playbook and Project Folders.

Which one do I use?

• Building or running something: workflow.
• Want a copy of someone's setup to change: fork a blueprint.
• Want someone's finished setup as one node in your board: add a blueprint (blueprint:invoke).
• Want the same person, brand or method in every video: keep it as a workflow now, a blueprint once it can be private to your team.
• Keeping one client's brief and pipelines together: project folder.
• Want every agent to follow your team's rules: team playbook.