Frags Runtime

The OSS runtime for AI-powered backend services.

Frags turns AI-powered automations into real backend services. It executes FML plans as typed, multi-session workflows — coordinating tools, scoped context, deterministic prework, and schema validation so a prompt becomes a service you can call.

View on GitHubBrowse FML plans

frags · runtime

$ frags run revenue-brief.fml --llm claude
▸ loading plan ................. ok
▸ required tools .............. apicp:salesforce, mcp:slack
▸ session collect_accounts
    queryAccounts → 38 records
    accounts[] schema validated
▸ session identify_risk
    scoped context → accounts only
    riskFindings[] schema validated
▸ session notify_team
    chat_postMessage → #revenue
✓ complete · typed output ready for the caller
Runtime engine
Built for workflows that need more than one prompt.
Frags treats an AI workflow as a plan with explicit inputs, tool requirements, sessions, dependencies, and output ownership. That makes it possible to compose agentic work without giving every step the same oversized context. Where an agent framework hands you an autonomous black box and asks you to trust it, Frags hands you a typed, inspectable plan you can read, diff, and version — the difference between hoping it worked and knowing it did.
Multi-session orchestration
Break a complex output into focused sessions. Each session owns a slice of the schema, can depend on earlier work, and can run only when its gate passes.
Scoped context by design
Frags controls what each model sees, so downstream sessions get the useful prior output without dragging the whole workflow into every prompt.
Schema-first output
Plans produce machine-consumable JSON that is validated against the declared schema. The runtime is built for services, not loose chat transcripts.
Bring the tools you need
Declare MCP servers, APICP-backed APIs, collections, or custom functions. Tool use stays explicit and local to the sessions that need it.
Deterministic work outside the model
Pre-calls, lightweight transforms, and output filters handle mechanical work before and after LLM calls to reduce cost and improve reliability.
CLI and Go library
Use Frags directly from the command line while prototyping, then embed the runtime into your own services when the workflow becomes production code.
FML contract
Plans are executable specifications.
FML is the first programming language for instructing LLMs — the plan language Frags interprets. It describes the workflow shape, not just a prompt: caller parameters, declared tools, deterministic preparation, session order, context boundaries, and the final JSON Schema.
system(...)
The shared system prompt for the plan
parameter(...)
Typed inputs supplied by the caller
require mcp
Declare the MCP servers, APICP APIs, and functions a plan may use
session(...)
A scoped LLM work unit with its own context and dependencies
use / call(...)
Tool use and deterministic pre-calls inside a session
schema { }
The typed output each session assembles
{{ ... }}
Templating across parameters and prior sessions
revenue-brief.fml
Copy
system(`You brief the revenue team before a renewal call.`)

parameter("account_id", type=string) # Salesforce account to brief.

require mcp Salesforce

session("collect_accounts") {
    use mcp Salesforce {
        allowlist = ["query"]
    }
    + Pull recent activity and open opportunities for account {{ .params.account_id }}.
    - Extract the facts that matter for a renewal conversation.
    schema {
        accounts: {
            name: string   # Account name
            stage: string  # Current opportunity stage
        }[]
    }
}

session("identify_risk", after="collect_accounts") {
    context "Accounts: {{ .context.collect_accounts.accounts }}"
    + Identify renewal-risk signals from the account facts.
    - Return the concrete risk findings for the call.
    schema {
        riskFindings: string[]
    }
}
In action
The EMA Pipeline
Whether you upload a skill or write from scratch, every Diaphora plan runs through three deterministic stages. Each fires a scoped LLM session with exactly the context it needs — no context rot, no bloat, typed output every time.
Plan Input
meetingQuery: "Acme Corp"
E
fetch-signals
prompt
Pull raw data from Calendar, Slack, and Salesforce in parallel preCalls.
GCal
Slack
Salesforce
M
build-prep
prompt
LLM session with only the signals in context. Builds structured meeting prep.
A
publish-to-notion
prompt
Final session writes the result to Notion and returns a typed schema.
Notion
Typed Schema Output
meeting_details · signals · prep_summary · notion_publish
diaphora · fetch-signals
RUNNING
E · Extract
fetch-signals
LLM Session · extract_signals
Scoped prompt: given raw data, extract only relevant signals for the meeting.
schema output →
{
  title: "Acme Corp Call Prep
  participants: [...]
  opportunity: { stage: "Proposal" }
  slack_msgs: 20 results
}
Frags and APICP work together.
APICP narrows external APIs into clean MCP tools. Frags runs the plan that decides when those tools are used, how their results are transformed, and which session owns each output field.
Explore APICP