Core Concepts

Before building on Bivariant, it helps to understand how the platform is structured. This section covers the core abstractions that everything else is built on.

The key idea

The platform is organized around one central principle: everything is a blueprint. A blueprint is the universal template for any application, integration, or service. Whether it's a customer support chatbot, a CRM connector, or an internal analytics tool — they are all expressed as blueprints composed of the same building blocks.

This creates a uniform system where:

• All operations are called through the same interface
• Blueprints can reference and compose operations from other blueprints
• Each organization gets its own isolated runtime data when installing an app
• The platform itself consumes its own abstractions

Core primitives

The platform has five foundational concepts that everything else depends on:

Blueprints

A blueprint defines what an application can do. It contains the complete structure of an app — agents, flows, actions, integrations, data schemas, screens, and event definitions. Blueprints are versioned and can be published, shared, and installed across organizations.

→ Learn more about blueprints

Apps

An app is an installed instance of a blueprint within an organization. When you install a blueprint, the platform creates an app scoped to your organization with its own service accounts, runtime data, and connections. Multiple organizations can install the same blueprint — each gets a fully isolated app instance.

→ Learn more about apps

Actions

An action is the universal callable unit. Every operation on the platform — calling an external API, running a native service function, or executing a flow step — is represented as an action with typed input and output schemas. Actions are invoked through a single interface regardless of their underlying implementation.

→ Learn more about actions

Organizations and spaces

The platform is multi-tenant by design. Organizations are the top-level isolation boundary. Within an organization, spaces provide additional separation for different projects or environments. Users, roles, and permissions control access at each level.

→ Learn more about organizations and spaces

Build-time vs. runtime data

The platform cleanly separates build-time definitions (what an app can do) from runtime data (what an app has done). Blueprint components like agent definitions, flow schemas, and integration operations are shared across all installations. Runtime data like conversation messages, collection records, and connection credentials are isolated per organization.

→ Learn more about build-time vs. runtime

How they fit together

Blueprint (build-time definition)
├── Agents          → AI assistants with identity and behavior
├── Flows           → Automation workflows with steps
├── Actions         → Callable operations (native + integration)
├── Integrations    → External API bindings
├── Collections     → Data table schemas
└── Screens         → UI definitions

    ↓ install

App (runtime instance, per organization)
├── Service accounts    → Identities for agents
├── Connections         → Authenticated credentials
├── Records             → Data in collections
├── Conversations       → Messages and threads
├── Tasks               → Execution history
└── Event subscriptions → Active event listeners

A blueprint author defines the structure once. Each organization that installs it gets an isolated runtime environment. Updates to the blueprint can be published and propagated to all installations.

Next steps

Start with any of the concept pages below, or jump directly to a feature area:

• Blueprints — the foundational application template
• Apps — installing and managing blueprint instances
• Actions — the universal execution interface
• Organizations and Spaces — multi-tenancy and access control
• Build-time vs. Runtime — understanding data separation