AI agents

An AI agent on Catalyst is an LLM-driven program whose every step — reasoning, tool call, handoff — is durably checkpointed by a workflow, runs under an App ID, and is observable from the Catalyst console.

Two properties are non-negotiable: durability keeps an agent's progress safe across process crashes, deploys, and tool-call timeouts; identity ensures every call the agent makes is authenticated and authorized by policy, regardless of what the LLM decides to do. The rest of this page is about how Catalyst delivers both, what framework choice means in that context, and how to position an agent against a plain workflow or a stateless service.

Durable execution for agents

A plain LLM loop is fragile. If the process crashes between a tool call and the next reasoning step, the partial work is lost and a retry re-runs the entire conversation — re-billing every token and re-issuing every side effect.

Catalyst runs each agent as a durable workflow. The agent's reasoning loop is the orchestrator; every LLM call and every tool invocation is an activity — a unit of work whose input and output are recorded on completion. When a process restarts, the runtime replays the recorded history to reconstruct the agent's in-memory state, then resumes from the last completed activity. Completed LLM calls and tool calls are never re-issued, so tokens already spent are not re-billed and external side effects do not duplicate.

LLM calls are non-deterministic, so wrapping them as activities is a strict requirement, not an optimization. See AI agent patterns for replay-safe LLM calls, tool-call durability, and idempotency for external side effects.

Identity and policy

Every agent runs under an App ID — a project-scoped identity that Catalyst issues a SPIFFE-based X.509 certificate for. The App ID is what other services see on the wire; it is what policies are written against.

Through its App ID, an agent gets:

Service invocation policies — an allowlist of the other App IDs the agent can call. Calls to anything else are refused at the runtime, not at the application layer.
MCP server access (via service invocation ACLs). Control which MCP servers (App IDs) the agent can invoke. Fine-grained per-tool MCP access policies are coming soon.
Pub/sub topic scopes — restrictions on which topics the agent can publish to or subscribe from.
mTLS to every peer — automatic mutual TLS between the agent and any other Catalyst app, with no certificate management in your code.

This matters specifically for agents because the LLM is non-deterministic and is a known attack surface: prompt injection, jailbreaks, and confused-deputy patterns can all convince an agent to call tools it should not. The App ID's policies are the deterministic guardrail — the runtime ignores what the LLM tries to do and enforces what the operator allowed. See Application identities, Policies, and Security.

Framework agnosticism

Catalyst is not a new agent framework. It hosts agents built in Dapr Agents, CrewAI, LangGraph, Strands, Microsoft Agent Framework, Google ADK, OpenAI Agents, Pydantic AI, Deep Agents, HolmesGPT, and any framework you bring.

What is shared across every framework on Catalyst:

The durable execution model — workflow plus activities, with the same replay semantics.
The App ID identity and policy enforcement.
The observability surface in the console (per-run history, tool calls, token usage).

What is specific to each framework:

The programming model (graph-based, crew-based, ReAct loop, declarative agent profile).
The LLM provider integration and tool-registration syntax.
The way multi-agent topologies are expressed.

Two mechanisms keep framework choice from leaking into the runtime:

Native Dapr Workflow integration. Dapr Agents — Diagrid's open-source agent framework — is built directly on the workflow runtime. Each reasoning step is already an activity; there is nothing to wrap.
Durable-execution wrappers. The diagridio/python-ai package exposes runners — DaprWorkflowGraphRunner for LangGraph, DaprWorkflowAgentRunner for CrewAI, and equivalents for Strands, Microsoft Agent Framework, Google ADK, OpenAI Agents, Pydantic AI, Deep Agents, and HolmesGPT. The runner intercepts the framework's execution loop so each node or tool call becomes a durable activity, without rewriting the agent.

For per-framework setup and code, see Develop AI agents.

Agent lifecycle

An agent moves through three stages on Catalyst: register, execute, observe. None of them are agent-specific primitives — agents reuse the same App ID, workflow, and observability machinery as the rest of the platform.

Register. Declare the agent as an App ID in your Catalyst project and attach the policies it needs — service invocation, MCP access, pub/sub scopes. Registration is identical to registering any other Catalyst app.
Execute. Your agent process connects to Catalyst at startup. Each invocation — a chat session, a triage request, a scheduled run — starts a workflow instance. The framework's reasoning loop runs inside that workflow, with every LLM and tool call recorded as an activity. Concurrent sessions are isolated by workflow instance ID.
Observe. Per-run history, tool calls, and LLM token usage surface alongside the raw service-invocation and MCP traffic surfaces in API logs. The App Graph shows the topology of multi-agent systems and how they connect to the rest of your project.

Agent vs. workflow vs. plain service

An agent is a workflow whose next step is chosen by an LLM instead of by code. That single difference drives when to reach for each option.

Property	Plain service	Workflow	Agent
Control flow	Request / response	Code-defined orchestration	LLM-decided next step
State durability	None	Per-instance, replayed on restart	Per-session, replayed on restart
Recovery from crash	Caller retries	Resumes from last activity	Resumes from last activity
LLM in the loop	No	Optional (as an activity)	Yes (drives the loop)
Typical use case	CRUD API, internal RPC	Order processing, data pipeline, long-running approval	Research, triage, copilot, autonomous task execution

Rules of thumb: if the orchestration is fully code-defined, prefer a workflow. If the call is a single request/response with no state to recover, prefer a plain service. Reach for an agent only when the LLM needs to decide what to do next based on intermediate results.

LLM token and cost accounting

Token usage is recorded per LLM activity within the workflow instance. Two consequences follow:

Replay does not re-bill completed calls. When the runtime replays a workflow after a crash, it reads each completed LLM activity's recorded result from history rather than calling the model again. Tokens already spent are not re-spent.
Only new branches incur new tokens. If replay reaches a point where the orchestrator schedules an LLM call that has no recorded result — a new code path, an uncached input, a fresh branch — that call hits the model and is billed normally.

Per-call token counts appear in API logs. For a deeper treatment of when costs recur and how to budget against replay, see Cost implications of replay.

When to use which framework

Framework choice is a developer-experience decision. The durability and identity guarantees are identical across every framework Catalyst supports, so this section is about matching the programming model to your team, not unlocking different runtime behaviour.

Framework group	Choose when	Where to start
Dapr Agents	Building a new agent and you want the tightest integration with the durable runtime and the fewest moving parts. Python-native, supports single-agent and multi-agent orchestration, ReAct loops, and MCP tools out of the box.	Develop with Dapr Agents
LangGraph, CrewAI, Strands, Pydantic AI	You are already invested in a popular OSS agent framework and want to add durability without rewriting. Use the matching `diagridio/python-ai` runner to wrap the existing agent.	Develop with LangGraph, CrewAI, Strands, Pydantic AI
OpenAI Agents, Microsoft Agent Framework, Google ADK	You are committed to a vendor's agent ecosystem and want Catalyst's reliability and identity layer underneath it. Supported via the same durable-execution wrappers.	Develop with OpenAI Agents, Microsoft Agent Framework, Google ADK
Deep Agents	Long-horizon planning agents that decompose tasks into nested sub-agent calls. Supported the same way as the other third-party frameworks.	Develop with Deep Agents
HolmesGPT	SRE and on-call use cases — alert triage, log analysis, and incident investigation across your Kubernetes and observability stack. Same durable-execution wrapper model as the other third-party frameworks.	Develop AI agents

If you have no prior framework investment, start with Dapr Agents — it has the tightest integration with the durable runtime and the fewest moving parts.

Durable execution for agents​

Identity and policy​

Framework agnosticism​

Agent lifecycle​

Agent vs. workflow vs. plain service​

LLM token and cost accounting​

When to use which framework​

See also​