# Catalyst Concepts

Catalyst is a multi-cloud orchestration and management layer for applications, workflows, agents, and MCP servers. It gives these workloads the reliability, security, and scale they need to run in production across clouds, regions, and environments.

This page maps the building blocks you compose to run AI agents and workflows on Catalyst — whether you operate the platform or develop on it. Each section is a short orientation; follow the links for the full explanation and for how to manage it.

## Organization

An **organization** is the top-level boundary in Catalyst. It gives you one place to manage regions across different clouds, manage users, and control which projects those users can access.

Organizations contain regions, and regions contain projects. Admins use this structure to separate environments, teams, or workloads while managing access from a single place.

```mermaid
flowchart LR
  subgraph ORG[Organization]
    direction LR
    USERS(Users)
    subgraph R1["Region AWS"]
      direction LR
      P1(Project dev) ~~~ P2(Project test) ~~~ P3(Project prod)
    end
    subgraph R2["Region Azure"]
      direction LR
      P4(Project)
    end
    subgraph R3["Region GCP"]
      direction LR
      P5(Project)
    end
    USERS ~~~ R1
    R1 ~~~ R2
    R2 ~~~ R3
  end
```

→ [Organizations, Regions & Projects concept](https://docs.diagrid.io/concepts/organisations-and-projects) · [Manage organizations, users, and API keys](https://docs.diagrid.io/operate/platform-operations/identity-and-access)

## Region

A **region** is the strongest isolation boundary inside an organization. An organization can contain one or more regions, which may be separated by cloud provider, geography, environment, or physical infrastructure.

Behind the scenes, each region is represented by its own Kubernetes cluster. Workloads and resources in one region are isolated from those in another.

Inside a region, you create projects for different purposes, such as separating teams, applications, agents, MCP servers, or environments.

```mermaid
flowchart LR
  subgraph REGION["Region"]
    direction LR
    PDEV(Project dev) ~~~ PTEST(Project test) ~~~ PPROD(Project prod)
  end
```

→ [Organizations, Regions & Projects concept](https://docs.diagrid.io/concepts/organisations-and-projects) · [Manage regions](https://docs.diagrid.io/operate/platform-operations/regions)

## Project

A **project** is a logical isolation boundary inside a region. It scopes the Catalyst resources created within it, such as apps, components, configurations, and policies.

A project works similarly to a Kubernetes namespace: names are scoped to the project, resources are grouped together, and access can be controlled at the project level. Admins can give users different permissions in different projects, making each project a security and ownership boundary.

Use projects to divide a region by purpose, such as environments, teams, applications, agents, MCP servers, or business domains.

```mermaid
flowchart LR
  subgraph PROJECT[Project]
    direction LR
    ID(Workloads) ~~~ COMP(Components) ~~~ POL(Policies)
  end
```

→ [Organizations, Regions & Projects concept](https://docs.diagrid.io/concepts/organisations-and-projects) · [Manage projects](https://docs.diagrid.io/operate/platform-operations/projects)

## ID

An **ID** is a **workload's identity** in Catalyst. Every workload you run — an **application**, an **agent**, or an **MCP server** — is given an ID. That identity is what lets you set **security boundaries** between workloads and attach policies to them. Catalyst issues each workload a cryptographically verifiable, automatically rotated identity, so workloads authenticate one another with no shared secrets.

```mermaid
flowchart LR
  subgraph CODE["Your code"]
    direction TB
    APP(Application)
    AGENT(Agent)
    MCP(MCP server)
  end
  subgraph CAT["Catalyst"]
    direction TB
    ID1(ID) -..-> POL1(Policy)
    ID2(ID) -..-> POL2(Policy)
    ID3(ID) -..-> POL3(Policy)
  end
  APP --> ID1
  AGENT --> ID2
  MCP --> ID3
  style CODE stroke-dasharray: 0
```

→ [Identities concept](https://docs.diagrid.io/concepts/identities) · [Security concept](https://docs.diagrid.io/concepts/security) · [Manage IDs](https://docs.diagrid.io/operate/project-operations/ids)

## Application

An **application** is any piece of code you have — a microservice, a monolithic application, an API, or a batch job. It connects to Catalyst through its ID and uses the [Dapr APIs](https://docs.diagrid.io/concepts/dapr-apis) for state, pub/sub, service invocation, secrets, and more, without embedding infrastructure clients in your code.

An application can also contain **workflow** code — durable, long-running orchestrations whose every step is persisted, so they resume from the exact point of failure instead of restarting from scratch. Use workflows for business processes, fan-out/fan-in, durable timers, and human-in-the-loop approvals.

→ [Application Identities concept](https://docs.diagrid.io/concepts/identities) · [Workflows concept](https://docs.diagrid.io/concepts/workflows) · [Durable execution concept](https://docs.diagrid.io/concepts/durable-execution) · [Develop on Catalyst](https://docs.diagrid.io/develop)

## Agent

An **agent** is an LLM-driven program that runs on Catalyst as a durable agent backed by workflows, with its own ID. Two properties make it production-grade: **durability** — every step (reasoning, tool call, handoff) is stored in the state store, so it resumes from the last completed step after a crash instead of restarting and re-spending tokens; and **identity** — its ID carries policy guardrails the LLM cannot reason its way around, governing which services and **MCP servers** it may reach. Catalyst is framework agnostic, working with Dapr Agents, CrewAI, LangGraph, Strands, and more.

→ [AI agents concept](https://docs.diagrid.io/concepts/ai-agents) · [MCP concept](https://docs.diagrid.io/concepts/mcp) · [Develop agents](https://docs.diagrid.io/develop/agents)

## MCP server

An **MCP server** exposes tools and data to agents through the [Model Context Protocol](https://modelcontextprotocol.io/). On Catalyst, an MCP server is given an ID and secured with access policies, so you control which agents may call it. You can secure an existing MCP server with access policies, or enable a new one from the **MCP catalog** of predefined templates.

→ [MCP concept](https://docs.diagrid.io/concepts/mcp) · [Develop with MCP](https://docs.diagrid.io/develop/mcp)

## Identity relationship map

Every workload carries an identity (its ID), and the Catalyst **Topology** view tracks the relationships between those identities — including the request rate, latency, and errors between them.

```mermaid
flowchart LR
  subgraph EX["Example topology"]
    direction LR
    APP1(Application 1)
    APP2(Application 2)
    STATE[(State store)]
    AGENT(Agent)
    MCP(MCP server)
    APP1 -."220 rps · 40 ms".-> APP2
    APP2 -."440 rps · 6 ms".-> STATE
    APP1 -."40 rps · 2.4 s".-> AGENT
    AGENT -."60 rps · 5% errors".-> MCP
  end
  linkStyle 2 stroke:#d69e2e,stroke-width:2px
  linkStyle 3 stroke:#e53e3e,stroke-width:2px
```

→ [Observability concept](https://docs.diagrid.io/concepts/observability) · [Topology](https://docs.diagrid.io/operate/project-operations/observability/topology) · [Manage observability](https://docs.diagrid.io/operate/project-operations/observability)

## Component

A **component** abstracts the backing infrastructure your workload needs — for example, the database for state or the message broker for pub/sub. It is how a workload accesses that infrastructure. Components are written as YAML, scoped to specific IDs, and let teams swap infrastructure without changing code. The full catalog of available components is in the [Components reference](https://docs.diagrid.io/references/catalyst/components-reference/intro).

```mermaid
flowchart LR
  subgraph CODE["Your code"]
    WL(Workload)
  end
  subgraph Catalyst
    ID(ID)
    COMP(Component
    YAML spec)
  end
  STORE[(Postgres / Redis / S3)]
  WL-->ID
  ID-->COMP
  COMP-->STORE
  style CODE stroke-dasharray: 0
```

→ [Components concept](https://docs.diagrid.io/concepts/components) · [Manage components](https://docs.diagrid.io/operate/project-operations/components)

## Policy

A **policy** customizes runtime behavior for apps and is enforced by Catalyst — no code changes required. Catalyst exposes the following policy types:

- **Access policies** — control which workloads can invoke an application, agent, or MCP server.
- **Workflow access policies** — for applications that have workflows, control which apps, agents, or MCP servers can invoke a workflow or an activity. They apply only to workflow applications.
- **Resiliency policies** — configure how Catalyst handles failures on calls to other workloads and to components, including retries, timeouts, and circuit breakers.

Policies are associated with apps.

```mermaid
flowchart LR
  subgraph CODE["Your code"]
    WL(Workload)
  end
  subgraph Catalyst
    ID(ID)
    ACCESS(Access
    policy)
    WAP(Workflow access
    policy)
    RES(Resiliency
    policy)
  end
  WL-->ID
  ID-.-ACCESS
  ID-.-WAP
  ID-.-RES
  style CODE stroke-dasharray: 0
```

→ [Policies concept](https://docs.diagrid.io/concepts/policies) · [Resiliency policies](https://docs.diagrid.io/concepts/policies/resiliency)

## Dapr

Catalyst is built on [Dapr](https://dapr.io/) — the open-source distributed application runtime. Your applications use the same Dapr SDKs and building-block APIs they would use against a self-hosted sidecar (state, pub/sub, service invocation, bindings, secrets, workflows, actors, and more). Catalyst manages the runtime, infrastructure, and upgrades so you don't have to.

```mermaid
flowchart LR
  subgraph CODE["Your code"]
    APP(Dapr SDK)
  end
  subgraph Catalyst
    ID(ID)
  end
  APP --> ID
  style CODE stroke-dasharray: 0
```

Beyond the managed runtime, Catalyst adds enterprise capabilities that Dapr OSS does not provide: a multi-cloud control plane, project and organization isolation, SPIFFE-based workload identity, RBAC, the Catalyst console (workflow management and visualization, agent registry, resources topology, metrics, API logs), and an enterprise SLA.

For a side-by-side comparison of Dapr OSS and Catalyst, see [Dapr OSS vs Catalyst](https://docs.diagrid.io/dapr-open-source/dapr-vs-catalyst).

→ [Dapr APIs concept](https://docs.diagrid.io/concepts/dapr-apis)