DEV Community: Marc Duiker

10 LangGraph Alternatives for Building Agentic Workflows in 2026

Marc Duiker — Sat, 08 Aug 2026 11:00:00 +0000

LangGraph is a good answer when your agent naturally looks like a graph. It gets harder to defend when your team does not want that graph to become the shape of the whole application.

None of the alternatives below are LangGraph clones. Each one asks you to think about agents differently.

If you want a smaller abstraction

The OpenAI Agents SDK gives you agents, tools, handoffs, guardrails, sessions, and tracing, without asking you to draw an explicit graph for every application.
Pydantic AI is worth a look if you write typed Python services. You get structured outputs, validation, and dependency injection.
Strands Agents runs a model-driven loop with tools and keeps the developer experience short.

If you want multi-agent concepts first

CrewAI models role-based agents, tasks, and crews. When collaboration is the main thing you are describing, that can read better than wiring nodes together.
Microsoft Agent Framework deserves a place on the shortlist if your team is Microsoft-oriented and you are building agents and multi-agent workflows across .NET and Python.
Google ADK supports modular agents, tools, and composition, and it lines up with Google's models and cloud.

If you want distributed-systems primitives

Dapr Agents puts agent development on top of Dapr's state, messaging, service invocation, and workflow foundation.
Restate is not only an agent framework. It is a durable application runtime that can wrap your agent logic and your SDKs. Look at it when resilient execution matters more to you than taking on another high-level agent abstraction.

If you want long-horizon or provider-specific tooling

Deep Agents aims at longer and more complex work through planning, sub-agents, and context-management patterns.
The Claude Agent SDK fits teams building tool-rich agents around Claude's ecosystem and its coding-agent patterns.

Framework choice is not runtime choice

Some of these change how you author the agent. Others change how the agent survives failure. The two decisions are related, but they are not the same decision, and it is easy to shop for one while thinking you are solving the other.

If you like LangGraph's programming model and what you actually need is production durability, you may not have to replace LangGraph at all. Diagrid Catalyst, for example, ships a LangGraph runner as part of its bring-your-own-framework approach, and other durable runtimes integrate with agent SDKs too.

My short version:

stay on LangGraph when explicit state and graph control are the strengths you want
pick CrewAI when roles and collaboration match the problem
pick the OpenAI Agents SDK or Pydantic AI when you want fewer orchestration concepts
pick an ecosystem-native framework when organizational alignment matters
add a durable execution layer when the real problem is recovery rather than authoring

Pick the one whose mental model your team can still explain a few months after the demo has become a production service. That test tells you more than how new the framework is.

Inngest or Diagrid Catalyst: From a TypeScript AI Workflow to an Enterprise Agent Platform

Marc Duiker — Fri, 07 Aug 2026 09:00:00 +0000

A five-person team usually picks the infrastructure it never has to think about, and that is the right call. It stops being the right call on the day the first enterprise customer asks where the agent runs and who is allowed to authorize its tools.

At prototype stage, Inngest is easy to understand. You write functions in TypeScript, Python, or Go, split durable work into steps, and let the platform deal with state, retries, flow control, and observability. Its current durable-agent model uses step-level memoization, so completed LLM calls and tool invocations are not repeated during a replay. It can also wait for events and invoke sub-agents.

That suits a web team stretching background jobs into longer AI workflows. The agent stays next to the application code, and there is not much infrastructure to run.

When the decision changes

The architecture conversation usually shifts in stages.

First you ship the feature. A TypeScript workflow calls an LLM, enriches some data, and writes a result. Developer experience decides the winner.

Then you have to survive failure. Tool calls need to resume at the right step. Inngest and Catalyst both handle that, through different execution models.

Then a second and a third agent stack show up. A Python team picks LangGraph, a .NET team picks Microsoft Agent Framework, and another group uses Google ADK. Catalyst's bring-your-own-framework model starts to matter here, because the platform standard can sit below those framework choices instead of competing with them.

Then you go through enterprise review. Customers ask for workload identity, deny-by-default access, private deployment, MCP governance, and evidence of what each agent did. That is where Catalyst's wider governance model can justify running a larger platform.

What I would compare

Retries and dashboards are the least interesting part of this comparison. I would look at:

which languages and agent frameworks are supported
what happens to completed steps and side effects during recovery
who operates the workers, the state, and the execution plane
how agent-to-tool access is authenticated and authorized
which self-hosted, private, or air-gapped topologies exist
how several teams share one platform without sharing permissions

Inngest can stay the best choice for developer-first durable functions, background jobs, and AI workflows, as long as its language and deployment model fit the team. Catalyst fits better once the requirement has grown from "make this function durable" into "run and govern many kinds of agents across the enterprise."

Both mistakes are common, and they are the same mistake pointed in opposite directions: buying the stage-four platform while you are still at stage one, and refusing to reopen a stage-one decision after the organization around it has changed. Let the architecture follow the risk you are actually carrying.

Official sources

Restate or Diagrid Catalyst for Durable Tool Calls?

Marc Duiker — Thu, 06 Aug 2026 08:00:00 +0000

"Retry the tool call" sounds harmless until the tool issues a refund. Then durability, identity, and evidence stop being three concerns owned by three different teams and turn into one incident.

Take a support system built out of several agents. A triage agent classifies the ticket. An account agent retrieves customer state. A policy agent decides whether a refund is allowed. A human approves the recommendation. An action agent calls the refund tool. Then the process loses its connection before the response is recorded.

Retrying is the easy part. What matters is whether the platform and your own code can work out what already happened, without sending a second refund.

Restate: durable code and journaled steps

Restate is a runtime that sits in front of your services and records execution in a journal. Its AI documentation shows LLM calls and tool executions wrapped as durable steps. After a crash, completed results are replayed from the journal and execution continues from the first step that never finished. Restate supports services, virtual objects, and workflows, and runs through Restate Cloud or a server you host yourself.

That is a good model if you want resilient functions and services with built-in state, reliable communication, and durable execution written into ordinary code. It also integrates with agent SDKs rather than asking you to adopt one agent framework.

Catalyst: durable agents plus a shared trust layer

Catalyst also persists workflow activity results and resumes failed executions. Around that it adds App ID-based workload identity, access policies, mTLS-backed communication, MCP governance, and a single operational surface for agents and applications. Diagrid positions verifiable execution, meaning history, lineage, signing, and attestation, as an additional trust layer.

Once money is involved, a security review will want more than proof that the run recovered:

Which workload identity invoked the refund tool?
Which policy authorized the call?
Can you show that the execution history was not altered?
Can you revoke access without editing the agent prompt?
Does the same control apply across cloud, on-premises, and isolated deployments?

Where each one fits

Restate is the better fit when what you need is a lightweight durable runtime for services, stateful entities, workflows, and agents, and you want to express resilience directly in normal application code.

Catalyst is the better fit when durable execution has to arrive together with organization-wide agent identity, policy-controlled tool access, verifiable evidence, and governance across several frameworks and deployment environments.

Neither one takes your application off the hook once the outcome is unknown. A payment or refund integration still needs idempotency keys, reconciliation, and explicit compensation logic. Durable execution preserves progress. It cannot tell you whether an external system committed a request when the response was lost.

So run the test you would rather skip. Fail the action at the worst possible moment, then check whether it recovered, whether you can prove who did what, and whether the same refund can go out twice.

Official sources

Kestra or Diagrid Catalyst for AI Workflow Orchestration?

Marc Duiker — Wed, 05 Aug 2026 09:00:00 +0000

"One orchestrator for everything" sounds like a clean platform strategy. It also packs three different execution problems into one word. A data pipeline, an infrastructure rollout, and an AI agent all have steps in them. That does not mean they want the same authoring model, the same recovery semantics, or the same governance boundary.

That gap is what to look at when you compare Kestra and Diagrid Catalyst. Kestra is a declarative orchestration platform that covers data, infrastructure, business, and AI workflows. Catalyst is a durable execution and governance platform for applications, workflows, agents, and MCP servers, built on Dapr. They overlap, and they start from different places.

Start with the shape of the workload

For scheduled ETL, infrastructure automation, or a business flow that crosses several tools, a declarative control plane is an advantage rather than a tax. Kestra defines workflows in YAML, has a large plugin ecosystem, and manages flows through a UI and Git. Its documentation now also covers AI workflows and AI Agent tasks that can use memory and tools and pick actions at runtime.

The calculation changes when the agent already exists. If it is written in LangGraph, CrewAI, Microsoft Agent Framework, Google ADK, or another supported framework, then rewriting it as a platform-specific flow is a rewrite nobody asked for. Catalyst's pitch is that you keep the framework and wrap durable workflow execution, identity, policy, and observability around it.

"Does it support AI" is the wrong row in the table

Both products support AI use cases, so the answer is yes twice so this question does not bring you closer to the perfect product fit. These questions separate them better:

Is the agent authored inside the orchestration platform, or does it arrive from an external framework?
What is the durable unit: a task, a workflow activity, an agent step, or a tool call?
How does a dynamic decision get reconstructed after a failure?
How are agent-to-tool permissions enforced?
Who runs the control plane, the data plane, the workers, and the state stores?

Those answers shape the developer experience and your Day-2 operations far more than an AI checkbox does.

One platform strategy, more than one abstraction

Kestra is the better fit when teams want declarative orchestration across data, scripts, APIs, and infrastructure, with a central catalog of flows and plugins to look at.

Catalyst is the better fit when the agent frameworks in use are a deliberate developer choice, and the platform team wants durability, identity, and governance to come from one layer without replacing those frameworks.

Running both is a legitimate answer. A general-purpose orchestrator can trigger a durable agent as a bounded service, or a Catalyst workflow can call an external data pipeline. Draw that boundary where ownership and failure semantics put it, and ignore where a vendor would prefer it.

The feature table does not decide this. Ask which execution model makes each of your workloads easier to build, recover, secure, and explain.

Official sources

Orkes Conductor or Diagrid Catalyst for Multi-Agent Workflows?

Marc Duiker — Tue, 04 Aug 2026 12:25:58 +0000

A multi-agent support flow is still a distributed system. You can make it sound less scary by giving the components friendlier names but the timeouts and the duplicate calls remain part of the system, and so does the question of who owned the handoff that failed.

For example; A triage agent reads a ticket, an account agent fetches customer context, a policy agent checks entitlements, and an action agent calls the order service. Somewhere between the policy decision and the refund API, a worker dies.

At 2 a.m. I care about a couple of things: which step completed, whether the refund can safely repeat, who owned the failed handoff, what an operator can do next, and whether the agent was allowed to make that call at all.

Orkes Conductor's operating model

Orkes Conductor coordinates tasks and workers through workflow definitions stored as JSON, and you can author those definitions in code, through the API, or in a visual builder. The documentation covers static and dynamic workflows, human tasks, event-driven flows, AI tasks, agentic orchestration, and MCP exposure. Orkes also positions Conductor as a platform where existing agents and workflows can invoke one another.

If your platform is already organized around microservice workers and explicit task definitions, that model makes sense. The workflow is a visible coordinator, workers can stay polyglot, and retries and state are handled centrally.

Catalyst's operating model

Catalyst builds on Dapr and treats workflows, agents, MCP servers, and services as workloads on one execution and governance plane. Agents can stay in the frameworks they already run in, while durable runners turn reasoning and tool operations into workflow activities. App identities and policies control which workloads may call other applications or MCP servers.

The interesting part is not the diagram. It is what ends up inside a single runtime boundary: recovery, communication, identity, policy, and operational inspection work the same way for agent and non-agent components.

Walk the failure, not the feature list

Run the same scenario on both platforms.

Complete triage and account lookup.
Let the policy agent approve a refund.
Kill the action worker during the refund call.
Restore service and watch what recovers.
Inspect the execution record and the authorization path.

Then ask whether completed steps replay or re-execute, how the refund call is made idempotent, how an operator retries or terminates the run, and how credentials are scoped. A product page that says "durable" will not answer any of that.

Where each may fit

Orkes is a strong candidate if you want Conductor's task-and-worker model stretched across microservices, APIs, humans, and AI, with workflows managed visually and as JSON.

Catalyst is worth evaluating if you already run Dapr, or several agent frameworks, and you want workload identity, policy-controlled communication, durable execution, and deployment governance to come from one platform.

Do not pick on the number of built-in tasks. Pick on the failure contract and the operating contract, because what saves you at 2 a.m. is an on-call engineer who can repair the run without guessing which agent did what.

Official sources

Camunda or Diagrid Catalyst for AI Workflows With Human Approval?

Marc Duiker — Mon, 03 Aug 2026 12:42:17 +0000

In a regulated workflow, "the agent made a reasonable decision" does not count as an audit trail. Someone still has to show who authorized the action, which controls applied, and where a human could have stepped in.

So Camunda and Diagrid Catalyst are not two versions of the same workflow product, and comparing them that way leads to the wrong choice. Camunda starts from end-to-end process orchestration and BPMN. Catalyst starts from durable, governed execution for applications, workflows, agents, and MCP servers. Both address AI now, but they enter the problem at different control boundaries.

Different approaches

Take an insurance claim. Deterministic steps validate coverage and fetch policy data. An AI agent summarizes the evidence and flags anomalies. A human approves or rejects the recommendation. Then a payment service does something that changes state.

Camunda is strong at making that whole process explicit. Its agentic orchestration documentation describes AI agents inside BPMN workflows, next to human tasks, deterministic rules, and AI-driven decisions. That is worth a lot when business and technology teams need one process model they both work from.

Catalyst treats agents as durable workflows and puts the weight on recovery, identity, policy, and observability in the execution layer. That fits better when the AI part is not one boxed task but an agent that may call tools, delegate to other agents, or run in a different environment.

Four questions that decide the fit

Who owns the process model? If business analysts and process owners have to see and change an end-to-end BPMN model, Camunda has the natural advantage. If developers own the agent code in frameworks they already use, a runtime that preserves those frameworks probably fits better.

Where does the non-determinism live? A bounded AI task inside a stable process is a different design problem from an agent that chooses its next step at runtime. Settle that question before you pick the orchestration layer.

What do you have to prove? An audit may want more than a diagram and some logs. It may want execution history, identity, the authorization decisions that were made, lineage, and evidence that the records were not altered afterwards. Diagrid's verifiable execution positioning is worth checking against the specific compliance requirement in front of you rather than accepting it as a generic checkbox.

Where does it have to run? Camunda and Catalyst both offer deployment choices, but the real constraint is which topology your organization has already approved: SaaS, your own infrastructure, private connectivity, or a fully isolated environment. Confirm the exact edition and who is responsible for what.

You may not have to pick one

An enterprise does not always need a single product to own every layer. Camunda can coordinate the formal business process while a durable agent runtime executes a complicated AI task behind a service boundary. It works the other way too. Catalyst workflows can model human approval without bringing BPMN into it, when the process is mostly owned by developers.

Choose Camunda when BPMN, human work, and process transparency are the center of the design. Evaluate Catalyst when agent durability, framework choice, workload identity, tool policy, and governance across environments are what you spend your time on.

Whichever you pick, the useful test is whether the control boundary is obvious afterwards: an auditor can find the evidence, an operator knows what can be resumed, a developer knows where side effects belong, and everyone knows the point at which the machine is allowed to act on its own.

Official sources

Durable Execution, Now Built for Agents

Marc Duiker — Tue, 28 Jul 2026 15:38:38 +0000

Durable execution has become an expectation for agent workloads. If the process dies halfway through a refund, the run resumes at the last completed step instead of re-issuing it. What it does not give you is proof. Replaying a run is not the same as proving what ran.

The missing piece is verifiability

Verifiable execution is a record of what ran, in what order, and what it produced, where every LLM call, tool call and decision is cryptographically signed and traceable to its source. Durability keeps work alive. Verifiability makes it checkable by someone who was not there.

More autonomy, less reproducibility

In a deterministic workflow the steps live in your code. You can diff them and point at the line that made a decision. As you hand control to the model, that structure moves out of the code and into the run itself. The model picks which tools to call and in what order, so two runs on the same input can take different paths, and nothing in your repository records which path a given run took.

Most teams make that trade on purpose. The flexibility is what lets an agent settle a messy dispute that no if-statement anticipated. The cost arrives later, when someone asks why a particular refund was denied. A stack trace tells you what your code did. It cannot tell you why the model chose one tool over another, and re-running the agent produces a fresh set of decisions rather than the ones you need to account for.

So the structure you take out of your code has to reappear underneath it, as a record rather than as more branching logic: every call the agent made, in order, with the inputs and outputs that led to the next step, each entry signed so it can be verified later.

What Catalyst is built for

Declarative workflow engines, where the flow lives outside your code, do not integrate natively with agent frameworks. Code-first engines integrate, but leave the run unverifiable, so you can resume it without being able to prove it. Agentic durable execution takes a third route: keep the framework you already use and make its execution durable and verifiable.

That is what Diagrid Catalyst is built for. Add a package to LangGraph, Microsoft Agent Framework, Google ADK, AWS Strands, OpenAI Agents SDK or CrewAI, and you get durable and verifiable execution through workflows, attestation, cryptographic signing, and SPIFFE-based workload identity.

Durable execution is becoming table stakes for agents. Verifiable execution is what makes them trusted.

Read the full post on diagrid.io to learn more.

Durable execution for LangGraph agents: resuming from the exact failed step

Marc Duiker — Tue, 28 Jul 2026 13:30:22 +0000

LangGraph checkpointing lets an agent resume from saved state. In production that leaves a gap: when a model call times out or a tool fails mid-run, something has to notice, decide where to restart, and finish the run. That is usually code you wrote.

Where checkpointing stops

A checkpoint records what the graph completed before the failure. It does not retry the failed step, know which side effects already ran, or restart a process that died. That logic becomes your own layer of retry wrappers and status flags.

What durable execution adds

Diagrid Catalyst records each step durably, so the runtime owns recovery:

the run resumes at the failed step, not at the start of the graph
completed steps are not re-executed, so you skip repeat model calls
every step lands in a signed record you can audit
one reliability layer covers cloud, edge, and on-prem

What the webinar covers

On Aug 11 we take a working LangGraph agent, force a failure mid-run, then add Catalyst and trigger the same failure. This time it resumes and finishes.

Save your seat at www.diagrid.io/webinars/durable-langgraph-agents

Temporal vs. Diagrid Catalyst: Which Durable Execution Approach Fits a Long-Running AI Research Agent?

Marc Duiker — Tue, 28 Jul 2026 12:59:17 +0000

Getting a research agent to call three tools in a demo is easy. The hard part starts when the seventh tool call times out and the first six have already spent money and changed state somewhere.

So this is a question about recovery, not about AI frameworks. Temporal and Diagrid Catalyst both do durable execution, and both position themselves for AI workloads. What separates them is what each one asks you to build and operate around your agent.

Start with the failure contract

Say your agent searches internal documents, calls an external research API, asks an LLM to synthesize the evidence, and then waits for a human to approve the result. Before that design goes to production, you need answers to four questions:

Which completed steps will not run again after a crash?
How do you stop non-idempotent tool calls from firing twice?
Can the agent wait for hours without holding a process open?
Can an operator reconstruct what the agent did, and why?

Temporal treats failure-prone work as activities, coordinated by durable workflows. It persists workflow state and rebuilds it by replaying history. You can self-host Temporal or use Temporal Cloud, and Temporal's current materials cover agentic applications and framework integrations directly.

Catalyst builds on Dapr Workflows. Your agent runs as a durable workflow, and Catalyst ships runners for established agent frameworks. Diagrid's documentation describes a shared runtime layer that handles durability, workload identity, policy enforcement, and operational visibility across agents, workflows, MCP servers, and applications.

Where the approaches diverge

Temporal fits when you want your application logic written in its workflow-and-activity model. The conceptual model is mature, language support is broad, and there is a large body of distributed-systems guidance to learn from. The cost is fluency. Someone on your team has to understand Temporal's execution semantics well enough to reason about replay, and you still decide separately where agent identity, access policy, and platform governance live.

Catalyst fits when your agents already exist in LangGraph, CrewAI, Microsoft Agent Framework, Google ADK, OpenAI Agents, or another supported framework, and you want to keep that choice. It sits underneath those frameworks as a shared execution and governance layer rather than replacing them.

That difference grows with the number of agent teams you have. A single research-agent project can standardize on a workflow SDK and be done. A platform team supporting Python, .NET, and TypeScript agents at the same time will care more about a framework-agnostic layer and policies it can set in one place.

What I would take to architecture review

Pick Temporal if workflow-as-code is the application model you actually want, you are willing to build around its abstractions, and its ecosystem and operating model match your platform strategy.

Select Catalyst if keeping your agent-framework choice matters, if you need workload identity and policy applied to tool calls, or if you have to govern agents across several deployment environments.

Neither choice saves you from designing idempotent side effects or deciding when a human gets pulled in. Durable execution changes what happens after a failure. It does not make a dangerous tool call safe.

Then run an experiment with either platform. Kill the agent after an expensive model call but before a state-changing tool call, and look at what resumes, what runs twice, and what evidence is left behind. Whichever platform makes that behavior easiest to explain to your developers, your operators, and your security reviewers is the one to pick.

Official sources

A free, open-source Dev Dashboard for local Dapr development

Marc Duiker — Mon, 20 Jul 2026 15:25:25 +0000

Developing Dapr applications means you're dealing with multiple apps and sidecars, looking at several terminals for log output and component files. There is now a free, open-source Dev Dashboard that brings it together in one live view. It runs as a single binary and auto-discovers apps started with dapr run, .NET Aspire, Docker Compose, or Testcontainers.

See everything Dapr at a glance

The dashboard shows your running apps with health, ports, and process IDs, plus their loaded components, actor types, and pub/sub subscriptions. You can also tail sidecar and application logs in the same window, with level coloring and keyword highlighting.

Debug workflows without guesswork

For Dapr Workflows you can list executions across your apps, inspect event history and input/output per step, and terminate or purge instances. The data is read straight from your local state store, so you see the real state rather than a copy.

Build components and policies in a UI

Two guided builders generate Dapr component and resiliency YAML from the full catalog, so you can skip hand-editing files.

Download & Install

You can view the project on GitHub: https://github.com/diagridio/dev-dashboard

You can install the dashboard directly via the terminal:

Install (macOS / Linux)

curl -sSL https://raw.githubusercontent.com/diagridio/dev-dashboard/main/scripts/install.sh | sh

Install (Windows, PowerShell)

iwr -useb https://raw.githubusercontent.com/diagridio/dev-dashboard/main/scripts/install.ps1 | iex

Give it a try when you're developing and testing your Dapr applications. Once you have it running, come share how it works for you in the Dapr Discord. If you hit a bug or have an idea to make it better, open an issue on the dev-dashboard repository.

Making Microsoft Agent Framework agents durable with Dapr Workflow

Marc Duiker — Tue, 07 Jul 2026 15:48:50 +0000

LLM calls are slow, costly, and non-deterministic, so a multi-agent app that crashes halfway through wastes time and money re-running everything. Dapr Workflow turns a set of MAF agents into a durable, fault-tolerant app that resumes from saved state and replays completed agent calls instead of hitting the LLM again.

There's a new free Dapr University track uses PrDigest, a .NET Aspire app that triages open Dapr PRs. You'll inspect the AppHost configuration, MAF agent registration, and the agent orchestration.

Try the track here.

Keep your Dapr Agent's answers current with a Tavily web search tool

Marc Duiker — Tue, 16 Jun 2026 13:46:15 +0000

LLMs are frozen at training time, so they return confident answers that may already be out of date. This free, self-paced Dapr University track shows you how to close that gap in Python by giving an agent access to the live web.

You'll build an expert agent with Dapr Agents that calls a Tavily search tool to fetch current information, then reasons over those results through the provider-agnostic Dapr Conversation API. Combining tool calls with agent reasoning keeps answers grounded in today's data.

This university track requires an OpenAI API key and a free Tavily key.

Start the free track here!