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.
→ Organizations, Regions & Projects concept · Manage organizations, users, and API keys
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.
→ Organizations, Regions & Projects concept · Manage regions
Project
A project is a logical isolation boundary inside a region. It scopes the Catalyst resources created within it, such as App IDs, 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.
→ Organizations, Regions & Projects concept · Manage projects
App ID
An App ID is a workload's identity in Catalyst. Every workload you run — an application, a workflow application, an agent, or an MCP server — is given an App ID. That identity is what lets you set security boundaries between workloads and attach policies to them. Catalyst issues each App ID a cryptographically verifiable, automatically rotated identity, so workloads authenticate one another with no shared secrets.
→ Application Identities concept · Security concept · Manage App 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 App ID and uses the Dapr APIs for state, pub/sub, service invocation, secrets, and more, without embedding infrastructure clients in your code.
→ Application Identities concept · Develop on Catalyst
Workflow application
A workflow application is an application that contains 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 them for business processes, fan-out/fan-in, durable timers, and human-in-the-loop approvals.
→ Workflow applications concept · Durable execution concept · Develop workflows
Agent
An agent is an LLM-driven program that runs on Catalyst as a durable agent backed by workflows, with its own App 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 App 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 · MCP concept · Develop agents
MCP server
An MCP server exposes tools and data to agents through the Model Context Protocol. On Catalyst, an MCP server is given an App ID and secured with access policies, so you control which agents and applications 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 · Develop with MCP
Identity relationship map
Every workload is represented by an App ID and carries an identity, and the Catalyst apps graph tracks the relationships between those identities — including the request rate, latency, and errors between them.
→ Observability concept · Apps Graph · Manage 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 an App ID accesses that infrastructure. Components are written as YAML, scoped to specific App IDs, and let teams swap infrastructure without changing application code. The full catalog of available components is in the Components reference.
→ Components concept · Manage components
Policy
A policy customizes runtime behavior for App IDs and is enforced by Catalyst — no application code changes required. Catalyst exposes the following policy types:
- Access policies — control which App IDs can invoke an application, agent, or MCP server.
- Workflow access policies — for applications that have workflows, control which App IDs can invoke a workflow or an activity. They apply only to workflow applications.
- Resiliency policies — configure how Catalyst handles failures on calls to other applications and to components, including retries, timeouts, and circuit breakers.
Policies are associated with App IDs.
→ Policies concept · Resiliency policies
Dapr
Catalyst is built on Dapr — 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.
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, app graphs, metrics, API logs), and an enterprise SLA.
For a side-by-side comparison of Dapr OSS and Catalyst, see Dapr OSS vs Catalyst.