Core Concepts
Catalyst gives every workload — application or agent — verifiable identity, durable execution, and policy-driven access, all without writing security or infrastructure code in your application. These are the concepts platform teams compose to run AI agents and workflows on Catalyst. Each section is a short orientation; for setup and operational detail, follow the link to the relevant Manage page.
Organization
An organization is the top-level access boundary in Catalyst, grouping users, regions, and projects. Both users and API keys use role-based access control, with project-scoped roles ranging from viewer to admin — letting platform teams give granular access across teams and environments.
→ Manage organizations, users, and API keys
Region
A region is a physically isolated unit of the Catalyst data plane — a Kubernetes cluster that hosts a fully managed Dapr deployment, the backing infrastructure (key-value store, pub/sub, registry), and optionally the applications and agents that run on it. An organization can contain multiple regions — typically separated by cloud provider, geography, or environment (for example, a region for dev/test isolated from production).
Project
A project defines a boundary for security, naming, and resource scope in Catalyst, grouping App IDs, components, policies, and managed services. Projects are isolated from one another, so resources in one project cannot be accessed from another project. A region contains multiple projects, typically used to separate environments (dev, staging, production) or teams. Each project maps directly to a Kubernetes namespace, so when configuring resources such as Configurations or Workflow Access policies, the namespace field equates to the project name. Each project has its own HTTP and gRPC endpoint, used to interact with all App IDs in that project.
App ID
An App ID is your workload's (application or agent) identity inside a Catalyst project. Catalyst issues each App ID a SPIFFE-based, cryptographically verifiable identity — a short-lived X.509 SVID, automatically rotated — used by the data plane to mutually authenticate every call between workloads and to backing infrastructure, with no shared secrets. An application binds to its App ID using an API token, but the SPIFFE identity is what secures runtime communication. At the App ID level you control access and resiliency policies, configurations, and which components and managed services the workload can use.
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 catalogue of available components is in the Components reference.
Policy
A policy customizes runtime behavior for App IDs and is enforced by the Catalyst data plane — no application code changes required. Catalyst exposes three policy types:
- Resiliency policies — Configure how the data plane handles failures on outbound calls to other applications and to backing infrastructure (components), including retries, timeouts, and circuit breakers.
- Configurations — Configure runtime settings on an application via its App ID, such as tracing, mTLS, and service invocation access policies.
- Workflow access policies (coming soon) — Control which App IDs can invoke a workflow or an activity.
Policies are associated with App IDs.
→ Resiliency policies and configurations
Workflow
A workflow is a long-running, stateful orchestration written in code. Catalyst persists every step, so workflows resume from the exact point of failure instead of restarting from scratch — saving latency, compute, and tokens during failures. Use workflows for business processes, AI agent execution, fan-out/fan-in, durable timers, and human-in-the-loop approvals.
Catalyst also provides advanced workflow visualization, where you can inspect every step of an execution and interact with running workloads and agents — start, stop, run, rerun, and suspend.
Agent
An agent is a durable AI agent that runs on Catalyst as a workflow with an App ID. Agents inherit the same identity, durability, and policy enforcement as any other workload — so a failed tool call resumes from the failed step instead of restarting the whole task. Catalyst is agent framework agnostic and can be used with Dapr Agents, CrewAI, LangGraph, Strands, Microsoft Agent Framework, Google ADK, OpenAI Agents, Pydantic AI, Deep Agents and more.
Catalyst maintains an agent registry where every agent is discoverable and inspectable.
Apps graph
The apps graph visualizes your application, agent, and backing infrastructure topology, including every call across your project, including agent-to-agent and app-to-app interactions. Use it to trace requests end-to-end, uncover failures and metric hotspots.
Managed service
A managed service is infrastructure Diagrid operates inside your project boundary so teams can skip provisioning their own backing stores. Catalyst currently offers a managed KV store (state) and managed Pub/Sub. Each managed service is consumed through a component, scoped to App IDs the same way as bring-your-own infrastructure. Managed services are intended for development and testing; production workloads should bring their own backing infrastructure.