Blueprints

A blueprint is a versioned, reusable template that defines what an application can do. It is the build-time definition of an app — the skeleton that describes agents, flows, actions, integrations, collections, screens, and event handling.

Blueprints do not contain runtime data. They define structure and behavior, not user-specific content.

What a blueprint contains

A blueprint is composed of several types of components:

All of these components live inside the blueprint and are versioned together.

Blueprint structure

Blueprint
├── metadata (name, title, version, status, UID)
├── project (ownership, organization)
│
├── Integrations[]
│   ├── Operations[]        → become Actions (runner: integration)
│   ├── Auth Methods[]      → become blueprint auth methods
│   ├── Event Channels[]    → become blueprint event channels
│   └── Data Types[]        → become blueprint data types
│
├── Actions{}               → all callable operations
├── Agents{}                → AI personas with flows
├── Flows{}                 → automation workflows
├── Screens[]               → UI definitions
├── Collections[]           → data table schemas
├── Auth Methods[]          → authentication schemes
├── Event Channels{}        → inbound/outbound event endpoints
├── Event Definitions{}     → typed events from channels
└── Data Types[]            → shared schemas

Versioning

Blueprints use semantic versioning with major and minor numbers:

• Minor bump (default): 1.0 → 1.1 — backwards-compatible changes
• Major bump: 1.0 → 2.0 — breaking changes

Version identifiers follow the format:

{name}-{uid}@{major}.{minor}

For example: [email protected]

Lifecycle

Every blueprint goes through a defined lifecycle:

Draft → Published → Deprecated → Archived

• Draft — actively being edited. Only one draft version exists at a time.
• Published — frozen and immutable. Represents a released version that apps can install.
• Deprecated — still functional, but marked for future removal.
• Archived — no longer available for new installations.

Publishing

When you publish a blueprint:

1. The current draft is frozen and marked as published with a release timestamp.
2. All components are deep-copied — agents, flows, actions, integrations, auth methods, and screens are duplicated to preserve the published state.
3. A new draft is automatically created with an incremented version number.
4. Cross-references (for example, an agent's default flow ID) are updated to point to the copied components.
5. Apps using this blueprint are notified and can be updated to the new version.

This process ensures that published versions are immutable snapshots. Changes to the new draft do not affect the published version or any apps currently using it.

Projects

Each blueprint belongs to a project, which tracks ownership and organization context. Projects link blueprints to the organization that created them and manage access control.

Identifiers

Blueprint components use structured identifiers for cross-referencing:

These identifiers are used throughout the platform — in flow step configurations, action calls, and API requests.

Related concepts

• Apps — what happens when a blueprint is installed
• Actions — the callable operations defined in blueprints
• Build-time vs. Runtime — how blueprint definitions relate to runtime data
• Publishing and Distribution — versioning, artifacts, and cross-org distribution