Glossary

Definitions for the Catalyst terms used throughout this documentation. Each entry includes a short definition and links to deeper concept and operational pages.

Activity

A named unit of work inside a workflow — a single function that Catalyst executes and retries independently. An activity is where your actual logic runs: calling an API, writing to a database, processing a file.

Agent

An autonomous software process that perceives inputs, makes decisions, and takes actions — often using an AI model as its reasoning core. In Catalyst, an agent is a durable process that can survive crashes, retry on failure, and resume mid-execution. Catalyst supports multiple agent frameworks such as CrewAI, LangGraph, Strands, OpenAI Agents, Google ADK, Pydantic AI, and the Microsoft Agent Framework.

Agent Framework

A third-party library that provides agent reasoning patterns — tool use, memory, multi-step planning, and model orchestration. Frameworks include CrewAI, LangGraph, Strands, OpenAI Agents, Google ADK, Pydantic AI, and the Microsoft Agent Framework. Applications built with any of these frameworks can run on Catalyst to gain durable execution, identity, and observability.

See also: /concepts/ai-agents · /develop/agents

API Token

A secret credential that an application uses to authenticate with the Catalyst control plane. Your app binds to its App ID at startup using an API token; once bound, runtime communication between services uses SPIFFE/mTLS identity automatically.

App Graph

A live topology view of the applications and agents registered in a project — which App IDs exist, how they connect through service-to-service calls, pub/sub, and workflows, and which backing infrastructure (components) they use. The app graph is built automatically from runtime interactions in the data plane and is visible in the Catalyst console; no manual configuration or instrumentation is required.

See also: /concepts/architecture · /operate/app-graphs

App ID

The verifiable identity that Catalyst assigns to each application or agent running on the platform. Every service that connects to Catalyst gets an App ID — a SPIFFE-based, cryptographically rooted identity that other services can trust, rotated automatically, with no code required to manage it.

Building Block

Dapr's term for a category of distributed-systems capability exposed through a stable API — state management, pub/sub messaging, service invocation, actors, secrets, bindings, and workflows. In Catalyst, these are called APIs: your code calls the Catalyst API, and the platform routes the call to the configured component.

See also: /concepts/dapr-apis · /concepts/components

Catalyst

A platform for running durable workflows and AI agents, based on the open-source Dapr runtime. Catalyst manages the runtime, infrastructure, identity, and observability so you can focus on application logic — without operating sidecars or a control plane yourself.

Component

A configuration resource that connects a Catalyst API to a concrete backing service — for example, wiring the state API to a specific Redis or Postgres instance. Changing the component YAML swaps the backing service without touching your application code.

Control Plane

The Catalyst-managed layer responsible for configuration, project boundaries, policy enforcement, and identity issuance. When you create a project, register an App ID, or define a policy, you are interacting with the control plane. Your application code does not run here.

See also: /concepts/architecture · /concepts/security

Dapr

The open-source, CNCF-graduated runtime for distributed applications that Catalyst is built on. Catalyst runs a hardened, managed fork of Dapr so you do not need to install or operate it yourself. The API surface (state, pub/sub, service invocation, bindings, secrets, workflows, actors), workload identity, mTLS, and component abstractions all originate from the Dapr project.

See also: /concepts/dapr-apis · /concepts/architecture

Dapr Agent

An agent built using the Dapr Agents framework — an open-source SDK that adds agentic reasoning patterns (tool use, memory, multi-step planning) on top of Dapr's durable execution primitives. Dapr agents run on Catalyst exactly like any other Dapr application: they get an App ID and benefit from Catalyst's reliability and security model.

See also: /concepts/ai-agents · /develop/agents

Data Plane

The runtime layer where Catalyst applications execute and connect to the backing infrastructure they depend on (state stores, pub/sub brokers, secret stores, workflow execution engines). In Catalyst Cloud, Diagrid operates the data plane; in self-hosted Catalyst Enterprise, the data plane runs in your Kubernetes cluster. Applications interact with the data plane through Catalyst APIs.

See also: /concepts/architecture

Determinism

The constraint that workflow code must produce the same sequence of activities on every replay given the same inputs. When a workflow resumes after a crash, it replays the activity sequence from the beginning using cached results. Non-deterministic operations (random numbers, current time, direct I/O) inside workflow orchestration code will cause replay divergence and must be avoided.

Managed Agent

A Catalyst-managed agent where Catalyst owns the runtime lifecycle: provisioning, scaling, crash recovery, and observability. You provide the agent logic; Catalyst operates it. Managed Agents are built on Dapr Agents under the hood — Catalyst manages them so you don't have to.

See also: /concepts/ai-agents

MCP (Model Context Protocol)

An open protocol that lets AI models and agents connect to external tools and data sources through a standardized interface. Catalyst supports MCP for agent tool integration and enforces authentication and authorization policies on MCP traffic.

See also: /concepts/mcp · /develop/mcp

Organization

The top-level account boundary in Catalyst — the entity that owns billing, users, and all projects within it. An organization maps to a company or a major business unit. You log in to Catalyst under an organization, and all resources (projects, regions, App IDs) belong to it.

Policy

A configuration resource that governs runtime behavior for one or more App IDs — controlling retries, access permissions, mTLS enforcement, and traffic routing — without requiring any code changes in the application. Policies are enforced by the Catalyst data plane.

See also: /concepts/policies · /references/policies

Project

The primary tenancy and isolation boundary within an organization. Each project has its own set of App IDs, components, policies, and — in self-hosted deployments — maps to its own Kubernetes namespace. Projects are how you separate environments (dev, staging, prod) or independent workloads.

Project-Scoped

A resource (App ID, component, policy, secret) whose configuration and access is confined to a single project, providing hard isolation between environments or workloads. Most resources in Catalyst are project-scoped. Examples of organization-scoped resources include billing, user accounts, organization-level API tokens, and organization-wide RBAC roles.

Region

A physically isolated deployment unit of the Catalyst data plane — a distinct infrastructure location where your workloads run. In Catalyst Cloud, regions are managed by Diagrid. In self-hosted Catalyst Enterprise, a region corresponds to a Kubernetes cluster you operate. Choosing a region controls data residency and latency.

Replay

The mechanism by which Catalyst resumes a workflow or agent after a crash by re-executing its activity sequence from the beginning, using previously recorded activity results instead of re-running the actual work. Replay is what makes durable execution possible: the platform reconstructs in-memory workflow state from the activity history log without re-executing side effects.

Sidecar

An architectural pattern used in Dapr OSS, where a runtime process runs alongside your application to handle distributed-systems concerns (mTLS, retries, service discovery, state access). In Catalyst, there are no sidecars for the user. Your application interacts with Catalyst APIs directly and gets the benefits of Dapr without operating a sidecar or a control plane yourself.

See also: /concepts/architecture · /concepts/dapr-apis

SPIFFE (Secure Production Identity Framework for Everyone)

The open standard that defines how software workloads prove their identity to each other in dynamic, cloud-native environments. Catalyst uses SPIFFE to issue every App ID a cryptographically verifiable identity (an X.509 SVID) at runtime. Because the identity is rooted in an open standard, it interoperates with any SPIFFE-aware infrastructure.

Worker

The long-running process that polls for and executes workflow activities. In Catalyst's workflow model, your application is the worker: it registers activity and workflow functions, listens for dispatch events, and executes the logic. Workers are stateless; Catalyst's runtime holds the durable state. You can run multiple worker instances for the same workflow type to achieve parallelism.

See also: /concepts/workflows · /develop/workflows

Workflow

The durable orchestration primitive in Catalyst — a function that coordinates a sequence of activities, survives crashes, retries failed steps, and resumes from where it left off without losing state. Workflow code must be deterministic; activity code (where side effects happen) does not need to be.

X.509 SVID (SPIFFE Verifiable Identity Document)

The cryptographic certificate that Catalyst issues to each App ID as its runtime identity credential. An X.509 SVID encodes the SPIFFE identity URI and is used to authenticate mTLS connections between services. Catalyst rotates SVIDs automatically; your application code never handles certificate lifecycle.

Activity​

Agent​

Agent Framework​

API Token​

App Graph​

App ID​

Building Block​

Catalyst​

Component​

Control Plane​

Dapr​

Dapr Agent​

Data Plane​

Determinism​

Managed Agent​

MCP (Model Context Protocol)​

Organization​

Policy​

Project​

Project-Scoped​

Region​

Replay​

Sidecar​

SPIFFE (Secure Production Identity Framework for Everyone)​

Worker​

Workflow​

X.509 SVID (SPIFFE Verifiable Identity Document)​