Develop Agents
Build production-ready AI agents on Diagrid Catalyst by combining any of the supported agent frameworks below with Dapr for durable execution, pluggable memory, and swappable LLM providers. Each framework guide shows how to make existing agents crash-proof with durable workflows and how to expose tools over MCP servers. New to agents? Start with the AI agent quickstart to build and deploy your first durable agent in under 15 minutes, then come back here to wire up your preferred framework.
Catalyst works with the following agent frameworks.
Beyond the framework guides, Multi-agent orchestration shows how to coordinate specialist agents across frameworks over Catalyst pub/sub, and Deploy to Kubernetes covers taking any of them to a cluster.
Framework requirements
Every agent on Catalyst runs as a durable workflow, so every integration requires a workflow state store — the managed state store where Catalyst checkpoints and replays each reasoning step and tool call to enable durable execution. It is the one resource all frameworks share.
The Conversation API and a Dapr conversation component that proxies LLM calls are optional for most integrations: third-party frameworks call their LLM provider directly through their own SDK. There are two exceptions: Dapr Agents leads with the Conversation API as its LLM path, and the Microsoft Agent Framework integration routes LLM calls through a conversation component.
| Framework | Language | Package / repo | Required resource | Conversation API |
|---|---|---|---|---|
| Dapr Agents | Python | dapr/dapr-agents | Workflow state store | Recommended |
| LangGraph | Python | diagridio/python-ai — diagrid[langgraph] | Workflow state store | Optional |
| CrewAI | Python | diagridio/python-ai — diagrid[crewai] | Workflow state store | Optional |
| Strands | Python | diagridio/python-ai — diagrid[strands] | Workflow state store | Optional |
| Pydantic AI | Python | diagridio/python-ai — diagrid[pydantic_ai] | Workflow state store | Optional |
| OpenAI Agents | Python | diagridio/python-ai — diagrid[openai_agents] | Workflow state store | Optional |
| Google ADK | Python | diagridio/python-ai — diagrid[adk] | Workflow state store | Optional |
| Deep Agents | Python | diagridio/python-ai — diagrid[deepagents] | Workflow state store | Optional |
| Claude Agent SDK | Python | diagridio/python-ai — diagrid[claude_agents] | Workflow state store | Optional |
| HolmesGPT | Python | diagridio/python-ai — diagrid[holmesgpt] | Workflow state store | Optional |
| Mastra | TypeScript | diagridio/typescript-ai — @diagrid/agent-mastra | Workflow state store | Optional |
| Microsoft Agent Framework | .NET | diagridio/dotnet-ai — Diagrid.AI.Microsoft.AgentFramework | Workflow state store | Required |
| Spring AI | Java | diagridio/java-ai — io.diagrid:diagrid-spring-ai-starter | Workflow state store | Optional |
| LangChainGo | Go | diagridio/go-ai — adapters/langchaingo | Workflow state store | Optional |
| Eino | Go | diagridio/go-ai — adapters/eino | Workflow state store | Optional |
The workflow state store is the only resource the third-party wrappers need — they configure nothing else. Two integrations use more. Dapr Agents is agent-native, so a DurableAgent wires up its own memory, state, and registry stores plus a pub/sub for agent-to-agent messaging. Go agents register themselves into an agent-registry component on startup. These components come from two places: Catalyst creates some, and you create the rest.
Catalyst creates agent-registry, backed by the managed key-value store, when you create the first agent in a project, for example with diagrid agent create. The project's region must support the managed key-value store, which BYOC and private regions can too; otherwise Catalyst rejects the agent. Projects in a region group don't support agents yet. A DurableAgent resource that you create through the Catalyst API needs two more things: --enable-managed-workflow on the project, and a region that supports managed pub/sub. For it, Catalyst also creates managed-agent-workflow, managed-agent-memory, and managed-agent-pubsub. agent-registry and the managed-agent-* components are reserved names, so you can't create components with those names yourself. They don't appear in the project's component list and don't count towards the project's component limit.
You create agent-workflow, agent-memory, and agent-pubsub yourself. Your Dapr Agents code asks for them by name, and the Dapr Agents quickstarts ship them in their resources/ folder. They show in the component list and count towards the limit like any other component. If a project already has an agent-pubsub component when its first DurableAgent resource is created, Catalyst uses these three names for its durable agents instead of the managed-agent-* set.
Each integration is built on a language-specific durability package that wraps the framework's execution loop in Dapr Workflows: python-ai for the Python frameworks, dotnet-ai for .NET, java-ai for Java, go-ai for Go, and typescript-ai for TypeScript. Dapr Agents builds natively on the Dapr workflow runtime, so there is nothing to wrap.
In Go, you build the agent as a graph of nodes and go-ai runs it as a Dapr workflow, so each node becomes a checkpointed activity. The framework plugs in through node constructors — langchaingo.ModelNode or eino.ChatModelNode — which means swapping frameworks leaves your orchestration code untouched. See the Go AI guide and the runnable LangChainGo and Eino examples.
