Has the team considered Rust for DeerFlow's core runtime?

[superbuzzy]

I've been following DeerFlow for a while and really like where the project is heading. One thing I've been wondering about is its long-term direction: does the team see DeerFlow primarily as a framework for experimenting with new agent architectures, or is the goal to turn it into something that can reliably run production workloads at scale?

I'm asking because DeepSeek's recent [Super-agent architecture exploration](https://github.com/deepseek-ai/dsh-superagent-prototype) (https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg) got me thinking about DeerFlow's underlying runtime.

Personally, I'd love to see DeerFlow move toward a Rust-based core runtime, while keeping Python and TypeScript for the higher-level application and agent ecosystem.

Here's why.

Where LangGraph starts to feel limiting

LangGraph does a great job with agent orchestration, checkpointing, and durable execution. But its abstractions are fundamentally centered around graphs, threads, and state transitions within an agent workflow.

The challenges look quite different when agents start running continuously, handling multiple tasks, spawning workers, and reacting to external events.

For example, what happens when an agent is cancelled while a tool is still running? Who takes over when a worker disappears? How do we recover after a restart without repeating operations that have already affected external systems?

LangGraph can certainly be part of a production solution, but these problems require additional infrastructure for task ownership, execution supervision, cancellation, and recovery.

My concern is that as DeerFlow becomes more capable, more of this infrastructure will have to be built around LangGraph. At some point, it might make more sense to treat the execution runtime as a separate systems-level component.

Why Rust seems like a good fit

What caught my attention in DeepSeek's Super-agent design was the combination of Router/Worker separation, asynchronous ReAct loops, event-driven execution, decoupled execution environments, and independent watchdogs.

These are increasingly systems engineering problems, and I think several aspects of Rust fit them particularly well.

1. Ownership and worker lifecycle management

In a Router/Worker architecture, the runtime needs to manage concurrent workers, task handles, shared state, message channels, and execution resources, often over long periods.

Rust's ownership model, borrow checker, and Send/Sync constraints make resource ownership and thread-safety requirements explicit at compile time.

This becomes especially valuable when workers are frequently created, cancelled, restarted, or destroyed. The compiler can catch entire classes of memory-safety and data-race bugs before they reach production.

Of course, ownership across distributed processes still requires leases and coordination protocols. But having strong guarantees within each runtime process is already a significant advantage.

2. Async execution and cancellation safety

DeepSeek's asynchronous ReAct loop allows agents to keep responding to new events while background tasks are still running.

That introduces some tricky lifecycle problems. A task might be cancelled while waiting for a tool, holding a resource, or processing an event. Simply stopping the agent loop doesn't necessarily stop the underlying operation.

Rust's Future model, Tokio, RAII, and explicit cancellation-safety considerations provide a solid foundation for dealing with these cases.

What I find valuable here is how Rust encourages developers to think carefully about who owns a task, what happens when it is dropped, and which resources must be cleaned up.

It doesn't automatically solve cancellation of remote processes or external side effects, but it provides a disciplined way to build those mechanisms.

3. Type-safe execution control

Another interesting part of DeepSeek's design is the Fast Path / Slow Path separation: deterministic operations are handled directly by the runtime, while semantic decisions go through the model.

As more responsibility moves into the deterministic path, the runtime needs to enforce increasingly complex rules around task states, events, permissions, and valid transitions.

Rust's enums, exhaustive pattern matching, newtypes, and typestate patterns are particularly useful for this.

Instead of relying entirely on runtime checks, some invalid states and operations can be made unrepresentable or caught during compilation.

I think this distinction matters a lot for production agents: the model can be flexible and probabilistic, but the execution runtime should be as predictable and constrained as possible.

4. A standalone runtime for long-running agents

DeepSeek's separation of computation, persistent state, and execution environments also suggests that the core runtime should eventually be independent of any particular agent framework.

Rust seems well suited for that role. Memory safety, deterministic resource cleanup, no garbage collector, and native systems programming capabilities are all useful for services that need to run continuously and interact with real system resources.

More importantly, a Rust core could expose stable interfaces to multiple agent frameworks without being tied to their internal execution models.

That feels like a good long-term foundation for a project like DeerFlow.

Rust for the core, not necessarily the whole stack

To be clear, I'm not suggesting rewriting everything in Rust.

I'd be much more interested in moving the core execution runtime to Rust first, covering things like task scheduling, event handling, worker lifecycle management, tool execution supervision, and recovery.

Python could continue handling model integrations, agent logic, Skills, and existing LangGraph-based functionality. TypeScript could remain responsible for the UI, CLI, and application interfaces.

That would preserve the flexibility of the existing ecosystem while allowing the execution core to evolve independently.

And while Rust won't magically solve distributed consistency, idempotency, or fault recovery, I think its language-level guarantees would provide a stronger foundation for building and maintaining a reliable runtime.

Curious about DeerFlow's long-term plans

This brings me back to my original question.

Is the long-term goal for DeerFlow to remain a platform for exploring agent capabilities, or does the team plan to develop it into a production-grade Agent infrastructure that enterprises can deploy and rely on?

Both directions make sense, but I imagine the architectural priorities would be quite different.

If production deployment is a major goal, I think the runtime itself deserves more attention, especially as agents become more autonomous and long-running.

And in that context, I'd really like to see Rust considered for DeerFlow's next-generation core runtime.

Has the team discussed this possibility internally? Would a Rust-based core, with Python and TypeScript remaining at the application layer, be something you'd consider for DeerFlow's future?

I'd be very interested to hear the maintainers' thoughts on both the long-term product direction and the runtime architecture.

Would love to hear your thoughts on this, @MagicCube and @WillemJiang , especially regarding DeerFlow's long-term direction and the possibility of adopting Rust for the core runtime.

Reference: [DeepSeek Super-agent Prototype](https://github.com/deepseek-ai/dsh-superagent-prototype)(https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg)