Blueprints

A blueprint is a reusable workflow that combines instructions, typed inputs, data from your cache or connections, and outputs. Each blueprint is versioned so you can edit, publish, and run the same workflow repeatedly without rewriting it.

What a blueprint contains

A blueprint ties the following together:

Instructions — the prompt document, versioned over time.
Inputs — typed parameters the run must supply or resolve.
Data bindings — live queries or rows pulled from the cache at runtime.
Plugins and connections — optional access to external systems.
Triggers — chat, schedule, events, other workflows, or MCP calls.
Outputs — a chat reply, new chunks, tasks, or another blueprint to chain into.

Prompts compose in a fixed order at runtime: system or cache rules, then blueprint instructions, then resolved inputs and data bindings.

Where to work with blueprints

Open Blueprints in the workspace (/dashboard/blueprints) to browse the built-in catalog, edit or draft new definitions, and inspect versions. Tenant admins can adjust certain system definitions where the product allows it.

For the catalog of workflows that ship with the product, see the Blueprint Library.

Blueprint Visual editor: metadata, instructions step, Chat and Schedule triggers, summary sidebar with Gmail tool. — Visual blueprint editor: instructions, triggers, and a live summary of inputs and tools.

Triggers and runs

How a blueprint starts depends on its configuration. Triggers include chat, schedules, events such as integration activity, another blueprint, and MCP when exposed. Each completed run counts against your team's plan limits. See the v0.1 release notes for baseline behavior and billing configuration.

Plugins and connections

When a blueprint needs Gmail, Google Calendar, or another service, it uses a connection (an authenticated instance of a plugin). Complete OAuth from Plugins first, then select the right connection inside the blueprint configuration.

When to build a blueprint

Reach for a blueprint when a task meets any of these conditions:

You run it more than once and want consistent inputs, outputs, and tone each time.
It depends on content already in the cache or on an external system you have connected.
You want it to run on a schedule, from chat, or from another workflow.
Multiple people on the team should be able to run it without repeating setup steps.

For a one-off task, chat is usually faster. For anything repeatable, a blueprint pays back the setup time.

Heads up: Each run counts against your plan's blueprint run limit. When setting up schedules (especially frequent ones) or chaining blueprints together, keep your monthly budget in mind so you don't hit the cap mid-cycle.

Blueprints vs. Claude Routines

If you've used Claude Routines, blueprints will feel familiar — both run a prompt on a schedule and return a result. The differences come down to context, structured I/O, and where the work lives.

Context. A blueprint runs against a specific cache. It can read databases, pull recent chunks, and follow links. Routines don't see your knowledge base.
Structured inputs and outputs. Blueprints accept typed inputs, bind to live cache data, and write results back — new Decisions logged, Inbox items routed, Tasks created. Routines produce a conversational output that doesn't persist into your systems.
Triggers beyond schedule. Blueprints start from chat, events, MCP, the Hook API, or another blueprint — not just a cron.
Versioning. Blueprint instructions are versioned documents you can edit, compare, and roll back. Routines carry a single current prompt.

Rule of thumb: reach for a Claude Routine when the task is a self-contained check-in with no dependency on team knowledge. Reach for a blueprint when the work depends on what your cache already knows, or when the result needs to land somewhere structured.