Open SWE Packages What Stripe, Ramp, and Coinbase Already Built

LangChain's Open SWE is not a product you deploy in an afternoon. It is a framework that reverse-engineers the internal coding agents three fintech companies built independently-and found they'd made nearly identical choices.

Three engineering teams-at Stripe, Ramp, and Coinbase-each spent months building an internal coding agent. Stripe developed Minions, Ramp built Inspect, and Coinbase created Cloudbot. They didn't coordinate. Despite building independently, all three companies made nearly identical architectural decisions.

They converged on isolated cloud sandboxes, curated toolsets, subagent orchestration, and tight integration with developer workflows.

That convergence is the whole justification for Open SWE, which LangChain released on March 17, 2026. It is an MIT-licensed framework for building your own internal coding agent-not a product you deploy out of the box, but a composable starting point with proven architectural decisions you customize for your codebase and team.

What it actually does

Open SWE lets organizations deploy AI coding agents invocable through Slack, Linear, or GitHub. Agents run in isolated cloud sandboxes-Modal, Daytona, and Runloop are supported-where they access repositories, execute commands, run tests, and automatically create pull requests. The system ships with roughly 15 focused tools rather than accumulating hundreds, and supports spawning subagents for parallel work.

The invocation surface matters here. Many teams converge on Slack as a primary invocation surface, and Open SWE follows that pattern: you mention the bot in any thread, specify a repository, and the agent replies in-thread with status updates and PR links.

On Linear, you comment @openswe on any issue; the agent reads the full issue context and posts results back as comments.

Context engineering is handled through two explicit channels. An AGENTS.md file at the repository root encodes team conventions and architectural decisions, while full Linear issue or Slack thread history is assembled before the agent begins work. This is deliberate: the agent gets all relevant context before it touches a file, rather than discovering it through repeated tool calls mid-run.

Each task runs in an isolated Linux environment. The repository gets cloned in, the agent receives complete permissions within that boundary, and errors remain contained. Multiple tasks can run in parallel, each in separate sandboxes. The isolation-first design solves a real problem: you want the agent to act without approval prompts on every shell command, but you can't afford a runaway agent touching production infrastructure.

The agent is instructed to run linters, formatters, and tests before committing. An open_pr_if_needed middleware acts as a backstop-if the agent finishes without opening a PR, the middleware handles it automatically. That last piece is a small thing that will save a lot of debugging: deterministic middleware steps run around the agent loop so the critical plumbing always happens, even when the model misses it.

A teammate like Beagle living in Slack already gives the agent its natural invocation surface-you can @-mention it in a thread the way you'd mention any other collaborator, and Open SWE will route that into the task queue.

What is genuinely new

Open SWE represents a bet on a specific trajectory for AI-assisted development: autonomous, long-running agents that integrate with existing developer workflows rather than requiring new interfaces. This differs from the short, synchronous, in-IDE copilot model that dominated earlier AI coding tools.

That framing is accurate, not hype. The copilot model asks you to stay in the loop constantly. The agent model asks you to review a PR. They are solving different problems. Not every task needs an autonomous agent-LangChain itself acknowledges that for small one-liner bug fixes or simple style updates, this architecture is not optimal.

What is new is the packaging. The architectural patterns existed before-inside private repositories at Stripe and Ramp. Open SWE formalizes these convergent patterns into a reusable framework. Instead of reinventing the wheel internally, any engineering team can now start from this foundation and adapt it to their specific needs.

Where the hype outruns the reality

Open SWE was days old at the time of the initial coverage. The community was enthusiastic, but it had not been battle-tested at scale outside LangChain's own usage. Expect rough edges, breaking changes, and rapid iteration.

The tooling gap is also real. 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.

Open SWE is not turnkey. You cannot install it and have a working coding agent in ten minutes. You need to set up a sandbox provider, configure GitHub, Slack, and Linear integrations, write your AGENTS.md, and likely add custom tools.

None of this is a reason to ignore it. It is a reason to set your timeline accurately. The value is in the architectural decisions already embedded in the framework-sandboxing strategy, context injection, deterministic middleware, subagent delegation. Those took production teams months to discover. Open SWE hands them to you on day one.

For the broader ecosystem, the direction this points toward is important: instead of capability being concentrated in a handful of well-funded teams, agentic coding can become a widely accessible practice. The same logic applies here. The patterns for running a reliable internal coding agent no longer require a Stripe-sized engineering team to discover. They are in a public repository, with an MIT license, waiting for your AGENTS.md.