Open SWE: LangChain's Open-Source Coding Agent Framework

TL;DR

Open SWE is LangChain’s new open-source framework for building internal coding agents. Key highlights:

MIT license: Fully open-source, 6,200+ GitHub stars in less than a week
Enterprise patterns: Captures architecture from Stripe (Minions), Ramp (Inspect), and Coinbase (Cloudbot)
Built on Deep Agents + LangGraph: Composed, not forked — customize without maintaining a fork
Pluggable sandboxes: Modal, Daytona, Runloop, or LangSmith — each task runs in isolation
~15 curated tools: Shell execution, file ops, HTTP requests, PR creation, Slack/Linear integration
Multiple invocation surfaces: Trigger from Slack, Linear, or GitHub comments

Install with:

git clone https://github.com/langchain-ai/open-swe.git
cd open-swe
pip install -e .

What is Open SWE?

Something interesting happened in the enterprise coding agent space. Over the past year, three of the most engineering-driven companies in fintech — Stripe, Ramp, and Coinbase — each independently built internal coding agents. They had no shared codebase, no coordination, and no common framework. Yet they all converged on remarkably similar architectures.

Open SWE is what happens when you extract those patterns and open-source them.

Released on March 17, 2026, by LangChain, Open SWE is an MIT-licensed framework for building your own internal coding agent. It’s not a product you deploy and use out of the box. It’s a composable starting point — a set of proven architectural decisions that you customize for your codebase, your workflows, and your team.

The framework is built on two LangChain primitives: Deep Agents (an agent harness for complex, long-running tasks) and LangGraph (the orchestration layer). Together, they provide the skeleton that Stripe’s Minions, Ramp’s Inspect, and Coinbase’s Cloudbot all independently discovered was necessary.

And the community has noticed. Open SWE crossed 6,200 GitHub stars within days of release. DevOps.com covered it as the first open-source framework to codify enterprise coding agent patterns. It’s clearly hitting a nerve.

Why This Matters: The Convergence Pattern

Before diving into architecture, it’s worth understanding why Open SWE exists.

In early 2026, LangChain published a series of deep-dive blog posts examining the coding agents built at Stripe, Ramp, and Coinbase. The findings were striking: despite building independently, all three companies made nearly identical architectural decisions.

Every one of them:

Wrapped an existing agent harness rather than building from scratch
Ran each task in an isolated cloud sandbox with full shell access
Curated a specific toolset rather than giving the agent unlimited access
Invested heavily in context engineering — feeding the agent the right information before it starts coding
Used subagent orchestration to break complex tasks into smaller, focused units
Integrated with existing workflows — Slack threads, Linear issues, GitHub PRs

This convergence isn’t coincidence. These are the patterns that survive contact with production. Open SWE packages them so you don’t have to rediscover them yourself.

Architecture Deep Dive

Open SWE’s architecture maps directly to the six patterns above. Here’s how each one works.

1. Agent Harness: Composed on Deep Agents

The core of Open SWE is a Deep Agents instance — not a fork, but a composition. This is a deliberate choice. Forking an agent harness (as Stripe did with Goose for Minions) means you own all future maintenance. Composing on top of one means you get upstream improvements for free.

The default model is Claude Opus 4.6, though you can swap in any model supported by LangGraph. The system prompt is constructed dynamically based on:

The repository’s AGENTS.md file (coding conventions, architecture notes, common patterns)
The source context (the Linear issue, Slack thread, or GitHub PR that triggered the agent)
Tool descriptions and constraints

Here’s the actual agent creation pattern from the Open SWE codebase:

create_deep_agent(
    model="anthropic:claude-opus-4-6",
    system_prompt=construct_system_prompt(repo_dir, ...),
    tools=[
        http_request,
        fetch_url,
        commit_and_open_pr,
        linear_comment,
        slack_thread_reply
    ],
    backend=sandbox_backend,
    middleware=[
        ToolErrorMiddleware(),
        check_message_queue_before_model,
        ...
    ],
)

This is the entire agent definition. Everything else — the sandbox, the tools, the middleware, the invocation surface — is pluggable.

2. Isolated Cloud Sandboxes

Every task Open SWE handles runs in its own isolated sandbox. This is non-negotiable for production coding agents: you need full shell access for running tests, installing dependencies, and checking build output, but you also need errors contained so one bad task can’t affect another.

Open SWE supports multiple sandbox backends out of the box:

Modal — Serverless containers, great for burst workloads
Daytona — Development environment management
Runloop — Focused on agent sandboxing specifically
LangSmith — LangChain’s own platform

Each sandbox gets a full clone of your repo, shell access, and a clean environment. When the task is done, the sandbox is torn down. This isolation model is what makes it safe to give the agent execute (shell) access — the blast radius is bounded.

3. Curated Toolset (~15 Tools)

One of the most interesting design decisions in Open SWE is tool curation. Stripe’s Minions has roughly 500 tools. Open SWE ships with about 15.

This is intentional. The framework provides the tools that every coding agent needs:

Deep Agents built-ins (core file operations):

read_file — Read file contents
write_file — Write entire files
edit_file — Make targeted edits
ls — List directory contents
glob — Pattern-based file search
grep — Search file contents
write_todos — Track work items
task — Spawn subagents

Open SWE additions (workflow integration):

execute — Run shell commands in the sandbox
fetch_url — Retrieve web content
http_request — Make arbitrary HTTP calls
commit_and_open_pr — Commit changes and create a pull request
linear_comment — Reply to Linear issues
slack_thread_reply — Reply in Slack threads

The philosophy is clear: ship the minimum viable toolset, then let teams add their own. Need a tool that queries your internal API? Add it. Need one that runs your specific test framework? Add it. The 15 tools are the foundation, not the ceiling.

4. Context Engineering

“Context engineering” is what separates a coding agent that works from one that hallucinates confidently. Open SWE addresses this through two mechanisms:

AGENTS.md: A convention file (similar to CLAUDE.md or CODEX.md) that lives in your repository root. It describes your coding conventions, architecture, common patterns, and anything else the agent should know before touching your code. Open SWE reads this file and injects it into the system prompt.

Source Context: When the agent is triggered from a Slack thread, it gets the full thread context. From a Linear issue, it gets the issue description, comments, and linked items. From a GitHub PR, it gets the PR description, diff, and review comments. This source context is what turns a generic coding agent into one that understands what you’re actually asking for.

This is the same pattern Stripe uses with “rule files + pre-hydration” and Coinbase uses with “Linear-first + MCPs.” Open SWE just makes it a first-class framework feature.

5. Subagent Orchestration

Complex tasks get broken down. Open SWE uses the task tool from Deep Agents to spawn child agents, each with their own isolated context and sandbox.

For example, if a Linear issue says “refactor the authentication module and update the tests,” the main agent might:

Spawn a subagent to analyze the current auth module structure
Spawn another to refactor the core logic
Spawn a third to update the test suite
Coordinate the results and create a single PR

Each subagent runs independently with focused context, reducing the chance of the agent losing track in a complex task. This is the same principle behind Stripe’s “Blueprints” and Coinbase’s “three modes” — breaking work into manageable units that can be reasoned about independently.

6. Middleware Layer

Open SWE includes a middleware system that wraps agent execution with safety nets and workflow automation:

ToolErrorMiddleware — Catches tool errors gracefully, preventing the agent from crashing on a failed shell command or API call
check_message_queue_before_model — Checks for new messages (e.g., user corrections in a Slack thread) before each model call, allowing the agent to course-correct mid-task
open_pr_if_needed — Automatically opens a pull request when the agent has made changes, ensuring work isn’t lost in a sandbox

This middleware pattern is what makes the difference between a demo and a production system. It handles the edge cases that you only discover after running a coding agent on real work for a few weeks.

Invocation Surfaces

One of Open SWE’s practical strengths is how it integrates with existing workflows. You don’t need a new UI or a new workflow — you mention the agent where you already work:

Slack

Tag @openswe in any Slack thread. The agent picks up the thread context, understands what’s being discussed, clones the relevant repo, and gets to work. When it’s done, it replies in the same thread with a link to the PR.

Linear

Tag @openswe in a Linear issue comment. The agent reads the issue, understands the task, and starts working. Progress updates go back to the Linear issue as comments.

GitHub

Tag @openswe in a PR comment. The agent reads the PR, understands the review feedback, and pushes fixes. This turns code review into a conversation with the agent.

This multi-surface approach means adoption doesn’t require changing how your team works. Engineers can try the agent from the tools they already use daily.

How Open SWE Compares to Enterprise Coding Agents

The most useful way to understand Open SWE is to compare it against the enterprise systems it was modeled on:

Decision	Open SWE	Stripe (Minions)	Ramp (Inspect)	Coinbase (Cloudbot)
Harness	Deep Agents/LangGraph	Forked (Goose)	Composed (OpenCode)	Built from scratch
Sandbox	Pluggable (Modal, Daytona, etc.)	AWS EC2 devboxes	Modal containers	In-house
Tools	~15, curated	~500, curated	OpenCode SDK + ext	MCPs + Skills
Context	AGENTS.md + issue/thread	Rule files + pre-hydration	OpenCode built-in	Linear-first + MCPs
Orchestration	Subagents + middleware	Blueprints	Sessions + child sessions	Three modes
Invocation	Slack, Linear, GitHub	Slack + buttons	Slack + web + Chrome ext	Slack-native
Validation	Prompt-driven + PR safety	3-layer + CI + retry	Visual DOM verification	Agent councils + auto-merge

A few things stand out:

Open SWE is leaner by design. Stripe’s 500 tools reflect years of internal iteration. Open SWE’s 15 tools reflect a framework that expects you to add your own. This is a feature, not a limitation — it means less to understand on day one.

Sandbox pluggability is unique. Stripe is locked to AWS EC2, Ramp to Modal, Coinbase to their in-house system. Open SWE lets you choose — and switch — without changing agent code.

Validation is the weakest layer. Stripe has three layers of validation plus CI plus automatic retry. Coinbase has agent councils. Open SWE relies on prompt-driven linting/testing and the open_pr_if_needed middleware. For production use, you’ll likely want to add more here.

Getting Started

Installation

# Clone the repository
git clone https://github.com/langchain-ai/open-swe.git
cd open-swe

# Install in development mode
pip install -e .

Basic Configuration

After installation, you’ll need to configure:

Model API keys — Set your Anthropic API key (or whichever model provider you’re using)
Sandbox backend — Choose and configure Modal, Daytona, Runloop, or LangSmith
Integration credentials — GitHub App for PR creation, Slack bot token for thread replies, Linear API key for issue comments

Creating Your First Agent

The simplest way to get started is to customize the default agent:

from open_swe import create_deep_agent, construct_system_prompt
from open_swe.tools import (
    http_request,
    fetch_url,
    commit_and_open_pr,
    execute,
)
from open_swe.middleware import ToolErrorMiddleware
from open_swe.sandbox import ModalBackend

# Configure sandbox
sandbox_backend = ModalBackend(
    image="python:3.12",
    timeout=600,
)

# Create the agent
agent = create_deep_agent(
    model="anthropic:claude-opus-4-6",
    system_prompt=construct_system_prompt(
        repo_dir="/path/to/your/repo",
        agents_md="AGENTS.md",
    ),
    tools=[
        execute,
        http_request,
        fetch_url,
        commit_and_open_pr,
    ],
    backend=sandbox_backend,
    middleware=[
        ToolErrorMiddleware(),
    ],
)

Adding the AGENTS.md File

Create an AGENTS.md file in your repository root:

# AGENTS.md

## Project Overview
This is a Python web application using FastAPI and PostgreSQL.

## Coding Conventions
- Use type hints for all function parameters and return types
- Write docstrings for all public functions
- Tests go in tests/ directory, mirroring the src/ structure

## Common Patterns
- Database access through SQLAlchemy ORM
- API routes in src/routes/
- Business logic in src/services/
- Shared utilities in src/utils/

## Before Submitting
- Run `pytest` and ensure all tests pass
- Run `ruff check .` for linting
- Run `ruff format .` for formatting

This file is your primary lever for controlling agent behavior. The more specific and accurate it is, the better the agent’s output will be.

Limitations: The Honest Take

Open SWE is impressive, but it’s important to be clear about what it is and isn’t:

It’s days old. Released March 17, 2026. The community is enthusiastic (6,200+ stars), but this hasn’t been battle-tested at scale outside of LangChain’s own usage. Expect rough edges, breaking changes, and rapid iteration.

It’s not turnkey. You can’t install Open SWE and have a working coding agent in 10 minutes. You need to set up a sandbox provider, configure GitHub/Slack/Linear integrations, write your AGENTS.md, and likely add custom tools. This is a framework, not a product.

15 tools vs. 500. Stripe’s Minions has roughly 500 curated tools built over months of internal use. Open SWE ships with 15. The gap is by design — you’re expected to add tools for your specific workflows — but it means significant work before you match enterprise-grade coverage.

Deep Agents is also new. Open SWE’s foundation — the Deep Agents framework — is itself relatively new. You’re building on two layers of recent software, which multiplies the risk of breaking changes.

No benchmarks yet. There are no published comparisons against Codex, Claude Code, or other coding agents. We don’t yet know how Open SWE’s architecture performs on standard benchmarks like SWE-bench.

Infrastructure overhead. Running Open SWE in production means managing sandbox infrastructure, API keys for multiple services, a GitHub App, and potentially Slack/Linear integrations. This is non-trivial operational overhead.

None of this means you shouldn’t use Open SWE. It means you should use it with realistic expectations: as a well-architected starting point for building your own coding agent, not as a finished product.

Who Should Use Open SWE?

Open SWE makes the most sense for:

Engineering teams at 50+ person companies that want an internal coding agent but don’t want to design the architecture from scratch
Platform teams that are already building developer tooling and want to add AI-assisted coding
Teams already using LangChain/LangGraph that want to extend their AI stack to coding tasks
Companies that need customization — specific tools, specific sandbox providers, specific workflow integrations

It makes less sense for:

Individual developers looking for a personal AI coding assistant (use Claude Code, Codex, or Cursor instead)
Teams that want zero-config — if you don’t want to set up infrastructure, this isn’t for you
Organizations without Python expertise — the framework is Python-first

The Bigger Picture

Open SWE represents a shift in how the industry thinks about coding agents. For the past two years, the conversation has been about products — Copilot, Cursor, Codex, Claude Code. Tools you sign up for, plug in, and use.

Open SWE is about patterns. It says: here’s how Stripe, Ramp, and Coinbase — companies that write some of the most demanding production code in the world — built their coding agents. Here are the architectural decisions that survived production. Here’s the code to implement them yourself.

The fact that three companies independently converged on the same architecture tells you something important. These patterns aren’t arbitrary — they’re the natural solution to the problem of “how do you let an AI agent safely write code in a production environment.”

Making those patterns open-source under MIT means that the next company building a coding agent doesn’t need to spend months rediscovering them. They can start from Open SWE and customize from there.

That’s genuinely valuable, even with all the caveats about maturity and missing features.

FAQ

How is Open SWE different from Claude Code or GitHub Copilot?

Open SWE is a framework for building your own coding agent, not a product you use directly. Claude Code and Copilot are end-user tools. Open SWE is what you’d use if you want to build something like Claude Code, customized for your company’s specific codebase, workflows, and tools. Think of it as the difference between using Gmail and building your own email system.

Can I use models other than Claude Opus 4.6?

Yes. Claude Opus 4.6 is the default, but Open SWE is built on LangGraph, which supports any model with a compatible API. You can swap in GPT-5, Gemini, or any other supported model by changing the model parameter in create_deep_agent. Performance may vary — the prompts and tool descriptions are optimized for Claude, but the framework doesn’t lock you in.

Do I need all three integration surfaces (Slack, Linear, GitHub)?

No. You can start with just one. The most common starting point is GitHub — tag @openswe in PR comments to get automated code fixes. Slack and Linear integrations can be added later. Each surface is independent and optional.

How does Open SWE handle security and code access?

Every task runs in an isolated sandbox with no access to other tasks or your production environment. The agent can only access the repositories you explicitly grant it. The sandbox is destroyed after each task. For additional security, you can configure the middleware layer to block specific shell commands, limit file access, or require human approval for PR merges.

Is Open SWE production-ready?

Not yet, in the traditional sense. It’s a well-architected framework based on proven patterns, but it was released days ago and hasn’t been battle-tested at the scale of Stripe’s Minions or Coinbase’s Cloudbot. Use it as a starting point for building your own production coding agent, and expect to invest engineering time in customization, testing, and hardening.

What’s the relationship between Open SWE and Deep Agents?

Deep Agents is LangChain’s framework for building complex, long-running AI agents. Open SWE is built on top of Deep Agents — it composes the Deep Agents harness with coding-specific tools, sandbox backends, and workflow integrations. You get Deep Agents’ built-in file operations and task management, plus Open SWE’s coding-specific additions. Updates to Deep Agents flow through to Open SWE automatically since it’s composed, not forked.

Bottom Line

Open SWE isn’t going to replace your team’s coding workflow tomorrow. But it’s the first open-source framework that captures how the best engineering teams in the world are actually building coding agents.

If you’re an engineering or platform team thinking about building an internal coding agent, Open SWE should be your starting point. Not because it’s complete — it’s not — but because the architecture is right. The patterns are proven. And the MIT license means you own your customizations completely.

The enterprise coding agent pattern is no longer a secret. It’s an open-source Python package with 6,200 stars and growing.

Links: