Swiftide: typed task graphs and streaming RAG pipelines in Rust

The problem Swiftide addresses in a Rust codebase

Most LLM application frameworks assume Python. A Rust service that wants retrieval, an agent loop with tools, and a place to pause for human approval has to either call out to a Python process or hand-roll the orchestration. Swiftide is aimed at the second path. The README describes it as an opinionated framework that gives you an agent harness, typed task graphs for orchestration, and streaming, composable indexing and query pipelines for RAG. The audience is a Rust engineer building an LLM feature inside an existing service, not a data scientist prototyping in a notebook. The framework's own primitives are split three ways: pipelines for data flows, agents for tool loops, and tasks for graphs of typed hand-offs. That split is the organising idea of the project, and it is also the first thing to evaluate, because it means you choose one of three mental models depending on whether your problem is ingestion, conversation, or workflow.

How the agent harness loops over completions and tools

The harness owns message history, calls the model, invokes tools, runs hooks, and decides when to stop. In the README example, an agent is built with an LLM, a single tool, an on_new_message hook that prints each message, and limit(8), then queried with a string. The documentation states that by default all agents have a tool to stop the loop, and that this can be customised. Tools come in three forms: functions annotated with the swiftide::tool macro, derived tools, or manual implementations of the Tool trait. The macro takes a description and named parameters, and the function receives a context plus the parameter values. That context, AgentContext, abstracts message history and is in-memory by default, while a ToolExecutor gives tools access to the outside world, local by default, with a separate docker executor linked from the README. Hooks exist before and after completions, tools, messages, streaming chunks, start, and stop. Human-in-the-loop approval is expressed through ApprovalRequired with feedback-aware contexts, and MCP toolboxes can load tools at runtime. The design keeps tools as pure functions and pushes side effects into the executor, which is a clean boundary but also means anything your tool touches has to be routed through that abstraction.

Typed task graphs and what build-time checking buys you

Tasks are the orchestration layer. A task is a typed graph of TaskNode steps, and each node carries an input type, an output type, and an error type, with transitions deciding where the output goes next. The README states that tasks are strongly typed at build time, which lets you compose agents, other Swiftide components, and plain functions into automations. The example in the README builds a Task<Prompt, String>, registers a prompt model node, registers a briefing agent, and continues with a render node. The types flow through the graph, so a mismatch between one node's output and the next node's input is a compile error rather than a runtime surprise. The README also lists fan-out into parallel branches that join typed results back into one task output, and pause and resume for human approval, external callbacks, or persisted state. That combination is the strongest argument for the framework over a dynamic-language equivalent. The cost is that the graph has to be expressible in Rust's type system, and any step whose shape is only known at runtime needs a wrapper type you write yourself.

Getting a first agent running with cargo and one environment variable

The quick start is three cargo commands. Add the framework with the agent and OpenAI features enabled, add anyhow, and add tokio with the macros and rt-multi-thread features. The README then says to set OPENAI_API_KEY for the OpenAI-compatible integration. The example constructs an OpenAI integration through a builder, sets default_prompt_model("gpt-4o-mini"), builds an agent with that LLM, the tool, the message hook, and limit(8), and calls query. Note that the README describes Swiftide as keeping default dependencies light and tells you to add the integrations your application needs, so the feature flags are the real configuration surface here. The project also points at examples/hello_agents.rs as the starting file, with further examples for human approval, MCP, streaming, resume, and structured output. There is no server, no config file, and no daemon: Swiftide is a library you compile into your own binary, and the only runtime configuration shown is the API key.

Limits, failure modes, and where Swiftide is the wrong tool

The material is thin on operational detail. There is no discussion of rate limiting, retry policy, token accounting, or cost control, and the only bound shown on an agent run is limit(8), a turn count rather than a budget. If your agent needs to run unattended against a paid model, you will be building the guardrails yourself. The in-memory default for message history is convenient for a demo and insufficient for a long-running service, so persistence becomes your problem unless the resume example covers your case. The OpenAI-compatible integration is the only model path shown in the README, which suggests that other providers require either an OpenAI-compatible endpoint or work you do yourself. The typed graph is also a constraint, not just a benefit: a workflow whose branches depend on runtime data has to be modelled with types that accommodate that, and the README does not show how. Finally, the framework is opinionated by its own description, so if your architecture already has an orchestration layer, adopting Swiftide means either replacing it or running two models of control flow side by side.

How Swiftide differs from LangChain-style Python frameworks

The obvious alternative for a Rust team is a Python framework such as LangChain, driven from a sidecar or a queue. The difference is not features, it is where errors surface. A Python chain assembles at runtime, so a mismatched output shape appears when the request runs, in production, against a live model. Swiftide's task nodes declare input, output and error types, so that class of mistake is caught when you compile. The second difference is deployment shape. A Python framework usually means a second process, a second dependency set, and a serialisation boundary between your Rust service and the LLM logic. Swiftide compiles into the same binary, which removes that boundary but also means every integration you add is a Rust crate in your dependency tree. The third difference is the streaming model: the README describes pipelines as streaming through loaders, transformers, embedders, caches and storage backends, which is a dataflow design rather than a request-response one. If your team is fluent in Python and not in Rust, none of these advantages outweigh the cost of learning the language, and the honest answer is to stay where you are.

Maintenance, release cadence and the MIT licence

The repository is active, not archived, with a last push in September 2026 and releases at v0.31.3, v0.32.0 and v0.32.1 across October and November 2025. The version numbers are still in the 0.x range, which in Rust crate convention signals that breaking changes are expected between minor versions. A team adopting Swiftide should plan for upgrade work on each 0.x bump rather than assuming patch-only churn, and should pin the exact version in Cargo.toml. The licence is MIT, which is permissive and compatible with commercial and closed-source use, but this is a description of the licence identifier and not legal advice; check the LICENSE file and your own obligations. The README lists a core team and points to a Discord for support, so the maintenance model is a small team plus community rather than a vendor with a support contract. Observability is handled through tracing and metrics with Langfuse support, which means you inherit whatever tracing setup your service already has instead of a bespoke dashboard.

Editorial conclusion

Adopt Swiftide if your application is already Rust and you want agent loops, tool calls and RAG indexing expressed as typed nodes the compiler can check, with a turn limit and stop tool configured from the start. Do not adopt it if your team writes Python, or if you need a managed ingestion service rather than a library you assemble yourself. Before committing, verify the feature flags your build actually needs with cargo add swiftide --features swiftide-agents,openai, confirm whether the OpenAI-compatible integration is the only model path you require, and read the examples for human approval and resume if your workflow pauses for a person.

Frequently asked questions

Official sources

1. bosun-ai/swiftide on GitHub
2. License: MIT
3. Project website
4. README
5. Releases