Blueprints for production AI

Create and distributereliable AI automations

Add AI inference to a business process that removes unnecessary human-in-the-loop.

Consumers

Interfaces & triggers

Consumers

Interfaces


Triggers

MCP

API

Blueprint

AI automation, defined as code

Inference exactly where the process needs judgment—deterministic everywhere else.

Declare its inputs, decisions, tools, sessions, and output schema in one typed, executable blueprint.

Distribute

API · MCP server · Schedule

Govern

RBAC · ABAC · DLP on every run

Schema-validated output

Versioned & auditable

Runtime connections

Tools, data & models

MCP servers


DBs & APIs


LLMs

Google Gemini

IAM & Gateway

Enterprise SSO, SAML, and federation at the door

SSO / SAML

Native DLP — PII protection

Runs where you already work

See all integrations

What you'll get

Your best AI automations need to be Blueprints.

Reliable

  • Schema-validated output — the same shape, every run.

  • Inference only where judgment is needed. The rest executes deterministically.

  • Scoped sessions, so each step sees just the context it needs to get it right.

Distributed

  • Published once as both an API and an MCP endpoint.

  • Callable from your app, an agent, a schedule, or Slack, Claude, and VS Code.

  • Self-hosted on your infra and your keys, or run on Diaphora cloud.

Governed

  • RBAC, ABAC, and DLP enforced by the runtime, not asked for in a prompt.

  • Tool access declared in the blueprint, so the blast radius is visible in source.

  • Every run versioned, readable, and auditable.

Start building

Start building reliable AI automations you control.

FML is how you instruct an automation, and a Blueprint is what you end up with: A Blueprint runs exactly as written. It reaches for inference only where judgment is needed, and declares its inputs, tool access, and output shape upfront. Describe what you want. Convert a skill. Or write it yourself.

Start with intent

  • Describe the outcome

    Explain the process in plain language. The assistant drafts the workflow file.

  • Bring a trusted skill

    Import a prompt or skill. Diaphora adds types, scope, and schema checks.

Every path produces

prep-call.fml

One executable blueprint

Typed inputs · scoped tools
checked output · version history

Start with source

  • Edit in the browser

    Change the same source that runs—without local setup or an export step.

  • Work in your IDE

    Use live diagnostics and validation, then review every change in Git.

Different starting points, one artifact your team can read, review, and version.

Already using skills?

Use Cases

Work that never needed a human in the loop.

Someone was reading, reconciling, or joining data by hand. Now a governed blueprint does it — the same way, every time.

Explore use cases by team →

All

Sales

Executive

Customer Success

Product

Platform

IT Ops

Marketing

Pull the upcoming calendar event, mine every past Avoma meeting with the account, reconcile Salesforce contacts, and synthesize one prep document — before the call starts.

No more reconciling three tools by hand before a call.

Tools

Google Calendar

Avoma

Salesforce

Sessions

1

calendar-details

2

find_meetings

3

analyze_meetings

4

generate_prep_report

Schema Output

calendar_details

meeting_analyses

crm_report

prep_document

Platform Architecture

Instruction Engine Core

Five tightly integrated components turn an FML Blueprint into a governed, callable service — instruction, identity, routing, persistence, and execution.

OSS Frags

Instruction Engine

Compiles your FML Blueprint into a schema-validated workflow.

Open-source instruction engine

Identity

IAM & Gateway

Authenticates callers and enforces roles and tenant boundaries.

Authorize access

Routing

Router

Directs each step to the right model, tool, or system.

Dispatch each step

Execution

Runner

Executes isolated sessions with guardrails, retries, and timeouts.

Run with control

Persistence

Storage

Keeps versioned Blueprints, configuration, and execution history.

Preserve the record

One Blueprint. Governed from entry to execution.

Models + tools + systems

What teams are already saying.

The limitations around AI isn't the lack of tooling but a lack of control over which systems those tools are allowed to reach. While obviously complex under the hood, Diaphora looks simple to interact with. Being able to control and govern these automations are critical, too.

Meagan

Senior Program Manager · Large Enterprise

Reliability is what turns an AI project into something we can put in front of the whole team. With Barndoor, if we know a workflow will follow the same defined process every time and can see exactly what touched it, we can deploy it far more broadly than anything we run today.

Nimrod Vered

CTO · Syndio

AI-native backend services in under 10 minutes.

Describe the workflow in plain English. Diaphora's sub-agent explores your connected tools, writes the FML, fixes its own routing, and hands you a deterministic, schema-validated service — callable over API and MCP. No boilerplate. No glue code.

Sub-agent mode

Bring your own LLM key

Web IDE + VS Code

API + MCP callable

sales-plan.fml

Copy

VALID

1

system("You are an expert sales assistant.")

2

 

3

require mcp Salesforce

4

require mcp Slack

5

 

6

session("sales_plan") {

7

    use mcp Salesforce

8

 

9

    # Fetch open opportunities for the current quarter

10

    call("queryOpportunity") -> opportunities {

11

        fields = "Id, Name, Amount, CloseDate, StageName"

12

        where  = "CloseDate = THIS_QUARTER AND IsClosed = false"

13

        limit  = 50

14

    }

15

 

16

    + Review my open opportunities for this quarter:

17

      {{ .vars.opportunities | json }}

18

 

19

      Analyze these opportunities and create a weekly sales Blueprint for me.

20

      Identify priority deals, group them logically, and outline the key

21

      actions I should take this week to move them forward.

22

 

23

    - Produce the detailed weekly sales blueprint, plus a concise summary

24

      that I can share with the broader team.

25

 

26

    schema {

27

        salesPlan: string # The detailed weekly sales Blueprint with steps

28

        summary:   string # A concise summary ready for Slack

29

    }

30

}

31

 

32

session("notify_team", after="sales_plan") {

33

    use mcp Slack

34

 

35

    # Automatically send the summary to the sales channel

36

    call("chat_postMessage") {

37

        channel = "123456789"

38

        text    = $(context.sales_plan.summary)

39

    }

40

 

41

    - Confirm the summary was posted to the sales channel.

42

 

43

    schema {

44

        posted:  bool    # Whether the summary was delivered to Slack

45

        channel: string  # The Slack channel the summary was sent to

46

    }

47

}

Create blueprint

~4 min elapsed

Build me an automation that pulls my opportunities for the quarter and creates my weekly sales blueprint. Additionally, Slack the sales summary to my sales channel — 123456789

Tool: list_available_tools

Tool: list_mcp_commands

Tool: list_mcp_commands

This Blueprint fetches your open opportunities for the current quarter from Salesforce, drafts a weekly sales Blueprint with a concise summary, then uses a deterministic tool call to send that summary to your Slack channel (123456789). Just make sure the Salesforce and Slack MCP tools are connected.

Tool: update_plan

Tool: update_plan

Compiled and schema-validated — the Blueprint is clean and ready to run. It will query your Salesforce opportunities for the quarter, assemble the weekly sales Blueprint and summary, and post that summary directly to your Slack channel.

Type a message…

Inspect before you run

Debug, observe, audit.

Review the executable source before it runs, watch each session as it executes, and keep the record it leaves behind. Logs, run history, and developer debugging are part of the platform—not a separate observability stack you assemble yourself.

FAQ

The questions we get.

How Blueprints work, where they fit, and what it takes to get started.

Have a different question?

Talk to our team

A skill's guardrails are suggestions an LLM can talk itself out of, and it runs locally on one person's machine — which makes it hard to trust and harder to distribute. A Blueprint constrains the model step by step: what's deterministic stays deterministic, inference is used only where judgment is needed, and access control is enforced by the runtime rather than by the prompt.

Publish it and it becomes a governed service — an API or MCP endpoint anyone with the right access can call, reliably and repeatably.

n8n, Zapier, and the rest handle deterministic steps well — right up until a step needs judgment, where they stop. Skills go the other way: they'll reason about anything, but that inference isn't governed, so “right most of the time” is as good as it gets.

A Blueprint does both in sequence: deterministic steps run as written, and the inference between them is fenced in by scoped context and a schema it has to validate against.

It's also stored as source rather than as a canvas — reviewable in a pull request, diffable between versions, and roll-back-able like any other code — and published as an API and MCP endpoint anyone with the right access can call, instead of living on the laptop that built it.

Three things, enforced by the runtime rather than asked for in a prompt:

Deterministic execution
Inference runs only where judgment is genuinely required. The rest of the process executes consistently and repeatably, at scale.
Unified access control
Every Blueprint you build becomes a governed MCP tool that inherits your identity provider's role-based access controls automatically — no separate provisioning step, no second policy to keep in sync.
Governed distribution
Publish once and the automation is available as both an API and an MCP endpoint, callable by anyone with the right access. Every run is observable and logged.

No. You can describe what you want in chat and the assistant writes the FML for you, or drop in an existing skill and Diaphora converts it into a typed blueprint. FML is there when you want to read, review, or hand-tune what actually runs — which, eventually, you will.

The model still writes the words; the Blueprint controls everything around it. Each session gets a scoped context instead of one sprawling prompt, and every session declares a schema its output must validate against. So the shape of what comes back is fixed and machine-consumable, even though the prose inside it varies.

Anything exposed over MCP, plus REST APIs and your own functions. Blueprints declare their requirements up front — including an optional allowlist of the specific methods a session may call — so a blueprint's blast radius is visible in the source rather than discovered at runtime.

You call them like any other service: over an API, as an MCP server for another agent, on a schedule, or from Slack, Claude, ChatGPT, and VS Code. The same Blueprint backs all of them — you author it once rather than rebuilding it per surface.

The Free plan is free forever — one user, 1,500 credits a month, no credit card and no expiry. Starter is $50/mo and Team is $200/mo (both cheaper annually), and paid tiers add credits automatically if you run past your allowance rather than throttling your runs.

Stop re-prompting.
Start shipping.

Join engineers, operators, and builders who are done shipping skills and ready to ship services. Deterministic, repeatable, production-grade — by design.

Start freeBook a demo

No credit card required

Not ready to sign up?