Anatomy of a blueprint

A blueprint is the engine's manifest — a single FML file that declares everything a run needs: the tools it can call, the inputs it accepts, the sessions that do the work, and the typed shape each one returns. This guide walks through one complete, realistic blueprint and points out what each part is doing, before you dive into any single piece in depth.

Prerequisites

None — this is the big-picture tour. Start here before Build a hello-world blueprint if you want the map before the walk.

A complete example

Here's a blueprint that pulls a caller's calendar, CRM, and Slack signals ahead of a meeting, drafts a structured prep doc, and publishes it to Notion:

require mcp gcal
require mcp salesforce
require mcp slack
require mcp notion

parameter("meetingQuery", type=string)

session("fetch-signals") {
    use mcp gcal
    use mcp salesforce
    use mcp slack
    + Pull calendar, Salesforce, and Slack
      signals for {{ .params.meetingQuery }}.
    - Extract only what's relevant to the call.
    schema {
        meeting_details: {
            title: string
            participants: string[]
        }
        signals: string[]
    }
}

session("build-prep", after="fetch-signals") {
    context true
    - Build structured prep from the signals only.
    schema {
        overview: string
        talking_points: string[]
        open_items: string[]
        suggested_agenda: string[]
    }
}

session("publish-to-notion", after="build-prep") {
    use mcp notion
    - Create a Notion page, return its URL.
    schema {
        page_url: string
        published_at: string
        success: bool
    }
}

Four things are doing all the work here: tools, parameters, sessions, and typed schema. Every blueprint is built from the same four, whatever it does.

1. Tools

require mcp gcal
require mcp salesforce
require mcp slack
require mcp notion

Declare the MCP tools a blueprint needs with require at the root, before any session. Diaphora handles auth, routing, and retries for each one — you just name them. A session can only call a tool it (or the blueprint root) has declared; see Connect Frags to your data for how sessions pull required tools into scope with use.

2. Parameters

parameter("meetingQuery", type=string)

Parameters are typed, validated inputs — the values a caller supplies when they run the blueprint. Declaring meetingQuery here means this same blueprint runs for any meeting; nothing about the sessions below needs to change. A parameter can carry a default, making it optional, and is referenced anywhere with {{ .params.meetingQuery }}.

3. Sessions

session("fetch-signals") { ... }
session("build-prep", after="fetch-signals") { ... }
session("publish-to-notion", after="build-prep") { ... }

Each session is a scoped, isolated LLM step. + prePrompts enrich context with tools available; the single - prompt is tool-free and produces the output. after chains sessions deterministically — build-prep only starts once fetch-signals has finished, and pulls its output in with context true. This blueprint's three sessions form a straight line, but sessions can also fan out, gate on conditions, or iterate over a list — covered in Control the flow of a blueprint. For everything inside a single session, see Anatomy of a session.

4. Typed schema

schema {
    page_url: string
    published_at: string
    success: bool
}

Every session ends in a typed schema. Diaphora validates each session's output against it and pins the result to the session that produced it — context.publish-to-notion.page_url, in this example — so nothing downstream has to parse freeform text. See Design your output schemas for the full field syntax, including nested objects and reusable $Component refs.

What this buys you

The same four declarations are why a blueprint is schema-validated, versioned, parametrizable, and auditable by construction — not bolted on after the fact. Diaphora compiles and executes the FML deterministically, every time, and the blueprint above is callable as-is over API or MCP once deployed.

Next steps

• Write your own from scratch in Build a hello-world blueprint.
• Go deep on one session's parts in Anatomy of a session.
• See how data moves between sessions in Data flow: params, vars & context.
• Browse finished examples in the blueprint marketplace.