Open SWE: LangChain's Asynchronous Coding Agent for Full Software Factory Loops
An Open-Source Asynchronous Coding Agent
At a glance
- What is it?
- Open SWE is an open source, asynchronous coding agent from LangChain that turns engineering tasks into repeatable workflows across GitHub, Slack, Linear, and a dashboard. Built on Deep Agents and LangGraph, it aims to handle planning, implementation, review, and CI monitoring with persistent sandboxes.
- Who is it for?
- Adopt Open SWE if you are a team already invested in LangChain or LangGraph that needs an asynchronous coding agent to handle end-to-end tasks from issue to pull request while keeping state across follow-ups. Do not adopt it if you need a stable, production-ready tool today, given the README's explicit warning that APIs and surfaces are still evolving.
- 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 received new commits within the last day.
- What is it written in?
- Mainly Python, 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
What Open SWE Actually Solves
Open SWE addresses a specific operational gap: engineering work that is typically manual, sequential, and context-heavy. The README frames it as a 'software factory' that turns a code-change task from a dashboard, GitHub, Slack, or Linear into a repeatable system. The target user is not a solo developer running one-off prompts. It is a team that wants an agent to take a task, plan, implement in isolation, validate, deliver a pull request, then handle review feedback and CI failures on the same thread. The key value is continuity: each cloud coding thread is bound to its own persistent sandbox, so the agent can continue from prior work when you reply. That is a different model from stateless coding assistants that forget everything between turns. Open SWE is for teams that want coding work to run asynchronously, in parallel, and with a memory of what happened before.
The Software Factory Loop and Its Five Graphs
The README describes a loop: issues, conversations, pull requests, and schedules feed into a 'Plan and investigate' phase, then 'Implement in an isolated sandbox', then 'Validate and deliver a PR', and finally 'Review, CI, and feedback' which can loop back for follow-up work. This is not a single monolithic agent. Open SWE ships five graph entrypoints built on LangGraph: Agent for planning and implementing changes, Reviewer for read-only pull request reviews, Analyzer that learns a repository's review style from historical feedback, Chat for answering questions about a pull request without modifying code, and Scheduler for dispatching recurring tasks and CI monitoring. The separation matters because it lets each graph have a different permission level and resource profile. Read-only PR chat does not need a sandbox, while coding threads get one. The Scheduler graph handles deterministic automations, which means recurring work is not an afterthought but a first-class entrypoint.
Deep Agents as the Harness, LangGraph as the Runtime
Open SWE does not invent an agent framework from scratch. It composes the agent with Deep Agents, which provides planning, file operations, shell access, skills, state, and subagent primitives. Open SWE then adds the software-engineering-specific tools, prompts, middleware, integrations, authorization, and product surfaces. LangGraph provides durable execution and thread state, which is what allows a thread to persist across multiple interactions. This architecture has a clear benefit: Open SWE inherits improvements from the underlying LangChain agent stack without forking it. The trade-off is that you are tied to LangChain's ecosystem. If you prefer a different agent framework, Open SWE's value proposition weakens significantly. The README does not describe a way to swap out Deep Agents or LangGraph, so adopting Open SWE means committing to that stack.
Sandbox Isolation and the Fail-Safe Behaviour
Cloud tasks run in isolated Linux sandboxes with development tooling supplied by the configured environment or snapshot. Each sandbox persists with its thread, which is how follow-up messages route to the original context. The README makes an important safety point: an unreachable coding sandbox is not silently replaced. Open SWE fails safely rather than risk discarding uncommitted work. This is a deliberate design choice that prioritizes data integrity over availability. The downside is that a sandbox outage could stall a task until manual intervention. The default sandbox and tracing provider is LangSmith, but the README lists Modal, Daytona, Runloop, E2B, and local execution as supported providers, with a pluggable interface for additional ones. That flexibility is useful, but it also means you must verify which provider your infrastructure can support before relying on Open SWE.
Getting It Running: What the README Reveals
The README does not include a quickstart with installation commands. That is a notable gap for an open source project. It describes product surfaces: a dashboard, GitHub integration, Slack, Linear, and a desktop app. The desktop is experimental, and packaged releases currently target macOS; source builds support Windows and Linux, but only if you build them yourself. The README mentions that cloud tasks require a sandbox provider, and the default is LangSmith. To run Open SWE, you would need to set up a GitHub App for repository access, configure an organization or repository allowlist, and choose a sandbox provider. The README references 'acto' at the end of the control and safety section, but the sentence is truncated, so the full allowlist behaviour is unclear. Potential adopters should expect to dig into the repository's documentation or source to find concrete setup commands, because the README alone is not enough to get started.
Where It Falls Short: Missing Commands and Uncertain Boundaries
The most obvious limitation is the lack of a setup guide in the README. A project that requires multiple integrations, sandbox providers, and authorization layers cannot be evaluated without knowing the exact commands and configuration keys. The README also warns that Open SWE is under active development and that APIs, setup, and product surfaces may evolve. That is honest but a real risk for teams needing stability. Another limitation is the desktop support: packaged releases target macOS only, so Windows and Linux users must build from source. The README does not specify what 'source builds' entail, nor does it list system requirements. Finally, the safety section is truncated, so the full scope of allowlists and authorization boundaries is not clear. You cannot fully assess whether Open SWE fits your security posture without reading the source or asking the maintainers.
The Alternative: Building Your Own Agent on Deep Agents
The natural alternative to Open SWE is to build a custom coding agent directly on Deep Agents and LangGraph, which are both open source. The difference is in scope and effort. Open SWE provides the software-engineering tools, prompts, middleware, integrations, and product surfaces out of the box. If you build on Deep Agents directly, you control every component but must write the GitHub delivery logic, the review workflow, the scheduler, and the sandbox management yourself. Open SWE also includes an Analyzer that learns repository-specific review style, which is a sophisticated feature that would be time-consuming to replicate. The trade-off is that Open SWE's product decisions, like the specific set of curated tools and the five graph entrypoints, become your constraints. If you need a different workflow shape, building on Deep Agents gives you freedom but at the cost of engineering time.
Maintenance and Licensing Considerations
Open SWE is licensed under MIT, which is permissive and allows commercial use, modification, and redistribution without copyleft obligations. That is a low friction point for adoption. However, the project is under active development, with nightly desktop releases as recent as the date of the last push. That suggests a fast release cadence, which can mean frequent changes to APIs and configuration. The README explicitly warns about this. Maintenance cost will come from tracking upstream changes in Deep Agents and LangGraph, since Open SWE inherits improvements from those projects. You will also need to maintain your own sandbox provider integrations and GitHub App configuration. The nightly desktop releases indicate that the desktop surface is not yet stable, so teams relying on it should expect to update often.
Editorial conclusion
Adopt Open SWE if you are a team already invested in LangChain or LangGraph that needs an asynchronous coding agent to handle end-to-end tasks from issue to pull request while keeping state across follow-ups. Do not adopt it if you need a stable, production-ready tool today, given the README's explicit warning that APIs and surfaces are still evolving. Before adoption, verify your sandbox provider of choice is supported, confirm your GitHub App and OAuth setup matches your organization's allowlist requirements, and test the desktop build on your OS since packaged releases currently target macOS only.
Community notes