Recipes
A recipe keeps package-wide instructions, agent definitions, skills, extensions, capability policy, judges, and optional user interactions together. Pi Recipes is the open format for vertical agents, built on Pi, and the toolchain that creates, validates, resolves, runs, and distributes these packages.
A small customer-support recipe might look like this:
customer-support/
├── agents/
│ ├── agent.yaml
│ ├── triage.yaml
│ └── escalation.yaml
├── skills/
│ └── ticket-triage/SKILL.md
├── judges/
│ └── useful-support-resolution.yaml
├── SYSTEM.md
└── package.jsonBuilding a recipe? Start with the Quickstart to create from scratch, customize a recipe template, or migrate an existing agent. The guide walks you through local authoring and testing; this page explains the package it produces.
Benefits of recipes:
- Own the behavior. Instructions, agents, skills, capability policy, and quality definitions live together as reviewable source rather than hidden configuration.
- Run the same agent in every stage. Use the recipe locally with Pi, then deploy a commit-pinned version to Introspection without redefining the agent.
- Change it deliberately. Git history shows exactly which behavior changed, while structural checks, judges, and the evals you keep beside the recipe make important expectations repeatable.
- Compose instead of copy. Share package-wide rules, derive agent variants, and add focused skills, extensions, or subagents as the system grows.
- Keep behavior portable. The recipe declares what the agent needs while Introspection supplies environment-specific credentials, bindings, identity, and infrastructure at runtime.
When you deploy with Introspection, an adjacent .introspection manifest connects the committed recipe source to a managed Pi runtime. It is deployment configuration, not part of the portable Pi Recipes format. See Runtimes and environments for how a commit becomes a runtime version.
Inside a recipe
A recipe folder uses package.json as its manifest and entry point. Top-level fields identify the package; the pi block declares recipe-owned resources and policies such as agents, skills, prompts, optional extensions, and the MCP servers the recipe may use. Shared instructions live in SYSTEM.md, and each agent is a YAML file (the conventional default is agents/agent.yaml; named variants are additional agents).
The final tab shows adjacent Introspection deployment configuration for context. It is not part of the recipe itself.
package.json
{
"name": "@acme/customer-support",
"version": "0.1.0",
"description": "Triage support requests, draft grounded replies, and escalate sensitive cases.",
"type": "module",
"pi": {
"agents": ["agents/*.yaml"],
"skills": ["skills/**/SKILL.md"],
"mcp": {
"servers": [
{
"id": "slack",
"required": false,
"tools": {
"include": ["slack_read_thread", "slack_send_message_draft"]
}
}
]
}
}
}Offline evals
Judges are the recipe’s validated evals; everything else you measure with lives in an evals/ directory that is yours — versioned beside the behavior it measures, but not part of the format. See Judges & evals for the split.
More on recipes
| Topic | Read |
|---|---|
| Runnable roles, models, instructions, and delegation | Agent definitions |
| Reusable domain workflows and deliverable shapes | Skills & prompts |
| Recipe-owned code and tools | Extensions |
| Portable external capability policy | MCP tool declarations |
| Quality criteria and test coverage | Judges & evals |
| Source, dependencies, and files supplied to managed tasks | Packaging a recipe |
| Package and agent file formats | package.json manifest and Agent YAML |
| Creating, loading, and checking recipes | Local toolchain |
| Running a recipe from your own process | Embedding recipes |