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 |
| Microsoft Agent Framework | .NET | diagridio/dotnet-ai — Diagrid.AI.Microsoft.AgentFramework | Workflow state store | Required |
| Spring AI | Java | diagridio/java-ai — io.diagrid.dapr:dapr-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 (agent-workflow, agent-memory, agent-registry, agent-pubsub in the quickstart). Go agents register themselves into an agent-registry component on startup. In both cases diagrid project create|update <project> --enable-agent-infrastructure provisions the whole set — pub/sub, key-value, workflow, and agent registry — in one step.
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, and go-ai for Go. 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 README and the runnable LangChainGo and Eino examples.