Catalyst Concepts

Catalyst is a durable execution platform for applications, workflows, agents, and MCP servers. It gives these workloads durable execution, verifiable execution, and a cryptographic identity with policy-based access, so they can 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.

An organization contains regions, and regions contain projectsUsers are managed once, at the organization level. Each region runs on its own cloud and holds its own projects.

→ 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.

A region holds projects

→ 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 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.

A project scopes its resources

→ Organizations, Regions & Projects concept · Manage projects

ID

An ID is a workload's identity in Catalyst. Every workload you run gets its own ID:

• An application: any service, API, or job.
• An agent: a durable AI agent.
• An MCP server: a tool or data server that an agent connects to.

The ID is what you set security boundaries around. Policies, component access and MCP access all name IDs: which workloads may invoke a target, which components a workload may use, and which agents may reach which MCP servers. Because the boundary is the identity rather than a network address or a shared secret, the same rules hold wherever the workload runs.

A workload authenticates to Catalyst with its ID's API token. Inside Catalyst, the Dapr Server that represents the workload carries a short-lived SPIFFE identity and uses it for mTLS on every downstream call.

Every workload gets an IDEach workload has its own ID. Policies attach to the ID, not to the code or a network address.

→ Identities concept · Security concept · Manage 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 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 · Workflows concept · Durable execution concept · Develop on Catalyst

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 · 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 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 · Develop with 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.

Identity relationship mapEach edge carries the live request rate and latency between two identities. The slow agent call and the failing MCP call stand out.

→ Observability concept · Topology · 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 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.

A workload reaches infrastructure through a component

→ Components concept · Manage 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.

Policies attach to a workload's ID

→ 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.

Your Dapr SDK talks to Catalyst through an ID

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.

→ Dapr APIs concept