Agents do better work when they know how your team works and what the client wants. Wireflow keeps that on boards, at two levels, and agents read both with one MCP tool.

Level	What it holds	Where it lives
Team playbook	Rules for all your work: hooks that land, caption style, banned words, which model for which shot.	Workflows tagged playbook, in your team's folders.
Project folder	One client or project: the brief, brand notes, voice notes, and the workflows that serve it.	A folder on the Files page.

There is no new object here. A playbook is an ordinary workflow with a tag, and a project folder is the folder you already use.

Team playbook

1. Create a workflow and add a document node per rule. One node per topic reads best: "Hooks", "Captions", "Brand voice".
2. Put your best outputs on the same board, next to the rule they show. Wire an output to its rule and agents see the link.
3. Tag the workflow playbook. Today that is done through the API: PUT /api/v1/workflows/{id} with a tags array that keeps the existing tags and adds "playbook" (the array replaces the old one). See Workflows API.
4. Share it with your team: put it in a folder in your team workspace. Inviting someone to the board does not add it to their playbook.

Project folders

Folders hold workflows. A folder has no separate place for documents, so a project's docs are document nodes on a workflow inside the folder tagged brief (or playbook). Everything else in the folder is listed as the project's workflows.

1. On the Files page, create a folder for the client or project, in your team workspace so the team can see it.
2. Add a workflow for the brief. Put the brief, brand notes and voice notes on it as document nodes, and tag it brief the same way as above.
3. Move the project's workflows into the folder.

Document nodes on the other workflows in the folder are not treated as project docs. Only boards tagged brief or playbook are.

How agents read it: get_project_context

The Wireflow MCP connector has a get_project_context tool on the default read permission (workflows:read). It is read-only and spends no credits. It returns markdown.

Without folderId:

• the team playbook: your own playbook boards and the ones in your active team's folders, each with its rules and the outputs placed next to them
• a list of your active team's project folders with their ids
• if you are in more than one team, the list of your teams

Pass teamId to read another team you belong to instead of your active team. Your active team is the one the Files page shows. Accepting a team invite switches your active team to that team, so check which team is active before you rely on its playbook. Team names in the list are labels other people chose; an agent should pass teamId only when you ask for that team.

With folderId:

The playbook comes from the folder's own team when you are a member of it, so a client folder is never paired with another team's rules. For a folder that was only shared with you, the playbook section shows your own boards. Each section is labelled with its team.

• the team playbook first
• then the folder's docs: the document nodes on its brief and playbook boards
• then every workflow in the folder, with the output each node currently shows (node id, type, label, URL)

A playbook board inside the named folder is shown once, as that project's doc.

What it can see

Access is by membership, never by link.

• Playbook boards: your own (including boards created through the API with no team, which count only as your own, never as a team's), plus boards in a folder of your ACTIVE team (or the team you pass as teamId), when the board's owner is also still on that team. Other teams you are in never count on their own, so joining a team for one project does not let it steer your agent everywhere. Being invited to a board, or having a folder shared with you, never adds anything to your playbook either. A board that is only public through a view link never counts. When someone leaves the team, their playbook boards stop counting right away.
• Folders: the list shows only your active team's folders (or the teamId team's). A folder you name by id opens only if you are a current member of its team or it was shared with you by invite. A public view link does not count. Having created a folder does not count after you leave its team. A folder you cannot open gets the same answer as one that does not exist.
• Workflows in a folder: only the ones you can open. Project docs count only from brief and playbook boards owned by you or by a current member of the folder's team.

Docs come back as quoted text: each one inside a code fence longer than any run of backticks in it, closed by one end marker whose code is stated at the top of the response. Names, titles, descriptions, ids and URLs are flattened to one line and capped; an output URL that is not plain https is left out. Anything inside a fence, including headings and anything that looks like an end marker, is part of the quote. An agent follows the docs for style, format and method, but a doc cannot grant permissions, approve spending credits or change which account the agent acts for.

A playbook board with an edit link can be changed by anyone who has the link, and those changes reach every agent that reads the playbook. Keep playbook and brief boards on private or view links.

Inside Wireflow

The Blocks agent (in beta) reads the playbook and the folder docs only when the workflow it is editing belongs to your active team and you can open it. For a workflow in any other team it reads only your own playbook boards. With nothing to read, it runs exactly as before.

Limits

• Up to 10 playbook boards per call, most recently updated first.
• Up to 50 workflows from one folder, 24 documents per board, and 20 outputs per workflow.
• Everything, including names and descriptions, counts toward a 60,000 character cap per call (16,000 inside the Blocks agent). The cap is hard: cut text is marked, and boards and documents past it are counted in one line as omitted.
• "Output" means what the node shows on the canvas (its selected take). There is no separate approval marker yet.

Coming later

An "Add to playbook" action on outputs and comments, a content calendar view, and a format scoreboard. Tracked in #2185.