Swarm: a Swift 6.2 agent runtime where tool schemas are generated at compile time
Type-safe tools, on-device inference, multi-agent workflows, memory, and guardrails, in one Swift-native runtime
At a glance
- What is it?
- Swarm packages a type-safe tool layer, a pluggable inference provider, composable workflows and optional MCP and OpenTelemetry surfaces into one Swift package. The interesting part is the trait system that decides how much of it you actually compile.
- Who is it for?
- Adopt Swarm if your application is already Swift and you want tool schemas derived from Swift types at compile time rather than assembled from JSON at runtime, and if you can accept Swift 6.2 with iOS 26 or macOS 26 as your floor. Do not adopt it if you need a Python or TypeScript runtime, or if your deployment target is below the stated platform minimums, because the README does not describe a back-deployment path.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is schema drift between Swift types and model tool calls
Most agent frameworks treat a tool as a name, a description and a JSON schema that you maintain by hand. When the Swift function signature changes, the schema does not, and the failure appears at runtime as a malformed argument or a model calling a parameter that no longer exists. Swarm's answer is the @Tool macro, which the README says generates tool schemas from Swift types at compile time. The example declares a struct with an @Parameter-annotated property and an async execute method, and the schema follows from that declaration rather than from a separate document.
That design choice sets the audience. This is for Swift engineers building agents that ship inside an app, a CLI or a server process written in Swift, who would otherwise be writing a JSON schema by hand and keeping it in sync. The README frames the whole package around that: type-safe tools, on-device inference, workflows, memory and guardrails in one runtime, with the same agent loop across iOS, macOS and Linux. It is not aimed at teams who want to prototype an agent in a notebook and later rewrite it.
The macro is optional. The README states that FunctionTool is available when you do not want macros, and that a macro-free build is possible with traits: []. So the type-safety story has an escape hatch, which matters for build-time-sensitive projects.
One agent loop, a pluggable InferenceProvider, and workflows built from agents
The architecture visible in the README has three layers. At the bottom is InferenceProvider, a protocol every agent uses. The README lists Apple Foundation Models for on-device inference, Ollama or LM Studio for a local HTTP model, OpenAI, Azure or OpenRouter through an OpenAI-compatible API, and a custom provider for anything else. Because the provider is injected per agent, the agent loop does not change when the backend does. A process-wide default can be set once with await Swarm.configure(provider:), which the README shows as the way to avoid passing a provider to every agent.
Above that sits the agent itself, constructed with a system prompt, an optional configuration, an inference provider, and a trailing closure of tools. The README's finance example passes .default.name("Analyst") as configuration and PriceTool() in the closure, then calls try await agent.run("...") and reads result.output.
The third layer is Workflow, which composes agents rather than replacing them. The README shows .step(researcher).step(writer).run(...) for sequential execution, .parallel([bullAgent, bearAgent, analystAgent], merge: .structured) for fan-out, and .route { input in ... } for conditional dispatch based on the input string. The merge: .structured parameter on parallel is the only detail the README gives about how fan-out results are combined, and it does not explain what structured merging does when the parallel agents return incompatible shapes. That is a gap worth reading the guide for.
Streaming, memory, guardrails, checkpoint and resume, MCP and tracing are described as capabilities you add as the application grows, not as parts of the core loop. The README lists conversation, sliding-window, vector, summary and hybrid memory as the available strategies, and states that guardrails validate inputs, outputs and tool arguments before they reach your application.
Install is a Swift Package Manager dependency, and traits decide the surface
The package is added through Swift Package Manager with a version requirement of from: "0.6.2". The README is explicit that the default package is lean: core Swarm, Foundation Models and macros, resolving swift-syntax through the default-on Macros trait and swift-log. It states that the MCP Swift SDK and OpenTelemetry are not in that default resolve.
Optional surfaces come in through traits. traits: ["Integrations"] adds the durable graph, ContextCore/Wax memory, Membrane and web helpers. traits: ["MCP"] adds the MCP server adapter plus the MCP Swift SDK, and also enables Macros. traits: ["OpenTelemetry"] adds the SwarmOpenTelemetry wrappers and also enables Macros. The README warns that specifying traits replaces defaults, so a build that needs several surfaces must list them together, for example traits: ["Integrations", "MCP", "OpenTelemetry"].
Running an example does not require API keys. The README gives this command for deterministic demo mode:
cd Examples/OnDeviceChat swift run OnDeviceChat --demo
That is the fastest way to see the loop execute without an Apple Intelligence device or a cloud provider. The examples directory is listed with four entries: OnDeviceChat for tools, streaming and multi-turn conversation, MultiAgentPipeline for sequential and parallel workflows plus checkpoint and resume, WaxChat for durable memory and web search with Integrations, and CodeReviewer for a small CLI.
Requirements are Swift 6.2 or later, iOS, macOS or tvOS 26.0 or later, and Linux on Ubuntu 22.04 or later with Swift 6.2. The README states the default Swarm graph is CI-tested on Ubuntu with Swift 6.2, and that Apple-only features such as Foundation Models, SwiftData, OSLog and some built-in tool behaviour are unavailable or different on Linux, where you should use an OpenAI-compatible provider, inject a mock, or run the deterministic examples.
Strict concurrency is the constraint, not a feature bullet
The README says Swarm uses Swift 6.2 strict concurrency, so values crossing actor boundaries must pass compiler checks. Read that as a cost as much as a benefit. Adopting Swarm in an existing codebase means your tool implementations, your provider wrappers and anything you hand to an agent have to be sendable under the compiler's rules. If your app predates Swift 6 concurrency checking, the migration work lands on you, not on Swarm.
The platform floor is the second constraint. iOS and macOS 26.0 as a minimum excludes a large share of shipping devices at the time of writing, and the README does not describe any back-deployment path or an older-OS fallback for the core loop. Foundation Models in particular is described as Apple-only and unavailable on Linux, so a Linux server build cannot use the on-device path at all and must go through an OpenAI-compatible provider or a mock.
The third constraint is the trait model itself. Because specifying traits replaces defaults rather than adding to them, a team that adds traits: ["MCP"] without also listing Macros gets Macros back only because the README says MCP enables it. That coupling is convenient here but it means the trait list is load-bearing configuration, and a wrong list produces a build that compiles but lacks a surface you expected. Nothing in the supplied material describes a diagnostic for that case.
Finally, the README does not state what happens when a provider call fails mid-workflow. Retries and fallbacks are mentioned as capabilities you add, and checkpoint and resume is gated behind the Integrations trait, so durable execution is not part of a lean build.
Where Swarm is the wrong tool
If your team writes Python or TypeScript, Swarm is not a candidate. The package is Swift-native and the macro-based tool definition depends on Swift's compile-time facilities; there is no binding described in the README for another language.
If your product must run on OS versions below the stated minimums, the README offers no path. That is a hard boundary rather than a tuning problem, and it is the first thing to check against your deployment targets.
If you need a durable, resumable workflow out of the box, the lean package will not give it to you. The README places checkpoint and resume behind the Integrations trait, so a project that assumes durable execution is in the core dependency will discover the gap at integration time.
If your agent work is exploratory, the compile-time tool schema is overhead. A framework where you define tools as dictionaries lets you iterate on a prompt and a schema in the same edit. Swarm asks you to change a Swift type and rebuild. That trade is correct for a shipped app and wrong for a spike.
One more case: if you rely on a model backend that is not reachable through Foundation Models, an OpenAI-compatible API, or Ollama and LM Studio, you are writing a custom InferenceProvider. The README lists that as a supported path but gives no protocol details in the material available, so budget time to read the source.
Compared with LangChain, the difference is where the schema lives
The README's own topics list includes langchain, so the comparison is fair to make. LangChain's centre of gravity is Python and JavaScript, and its tool abstraction is a decorated function whose schema is derived or declared at runtime in a dynamically typed language. Swarm's centre of gravity is a compiled Swift binary, and its tool schema is generated at compile time by the @Tool macro from a struct's properties and an execute method.
The practical difference shows up in failure modes. In a dynamically typed runtime, a mismatch between a tool's declared schema and its implementation surfaces when the model calls the tool. In Swarm, a mismatch between the Swift type and what the model can express is a compile error or a schema that reflects the actual signature. The cost is that you cannot add a tool to a running process without rebuilding.
A second difference is deployment shape. LangChain assumes a server or a script with network access to a model API. Swarm's README puts on-device inference through Apple Foundation Models first, with local HTTP and cloud providers as alternatives, and states that the same agent loop works across iOS, macOS and Linux. That makes Swarm plausible for an app that must answer questions with no network at all, which is not the shape LangChain is built around.
This is not a claim that one is faster or better. It is a claim about where the type information lives and what that buys you at build time versus at run time.
Version cadence, licence, and what to read before adopting
The repository shows three releases in the weeks before this writing: 0.6.4 on 2026-08-29, 0.6.3 on 2026-08-28, and 0.6.2 on 2026-08-14. The README's install snippet pins from: "0.6.2", which is two patch releases behind the newest tag. On a pre-1.0 package, patch releases can still carry behaviour changes, so pinning to an exact version rather than a range is the safer default until you have read the release notes for 0.6.3 and 0.6.4. Nothing in the supplied material describes a deprecation policy or a stability guarantee for the 0.x line, and I cannot confirm from it whether the API is considered settled.
The licence is MIT, stated in the README badge and the repository metadata. MIT is permissive and permits commercial use and modification, but I am not giving legal advice: read the LICENSE file and your organisation's policy before shipping, particularly if you vendor the source or redistribute a binary. Note that the optional traits pull in third-party packages, including the MCP Swift SDK, which carry their own licences that the README does not enumerate.
Upgrade cost is dominated by the trait list and the platform floor. A package that starts lean and later adds Integrations changes its dependency graph, not just its imports, so the upgrade is a dependency-resolution event. The README's guidance to combine traits explicitly, for example traits: ["Integrations", "MCP", "OpenTelemetry"], is the thing to encode in your Package.swift from day one rather than discovering when a build loses a surface.
Before adopting, read three documents the README links but does not summarise: docs/guide/getting-started.md, docs/guide/remote-providers.md for provider configuration and the privacy details the README promises, and the MultiAgentPipeline example, which is where checkpoint and resume behaviour is actually demonstrated.
Editorial conclusion
Adopt Swarm if your application is already Swift and you want tool schemas derived from Swift types at compile time rather than assembled from JSON at runtime, and if you can accept Swift 6.2 with iOS 26 or macOS 26 as your floor. Do not adopt it if you need a Python or TypeScript runtime, or if your deployment target is below the stated platform minimums, because the README does not describe a back-deployment path. Verify two things before committing: that your target OS actually ships the Foundation Models path you intend to call, and which traits you need, since specifying traits replaces the defaults and a lean build excludes the MCP Swift SDK and OpenTelemetry entirely.
Community notes