Coinbase's Forge, originally two engineers' side project, now handles 5% of all merged PRs and cut the company's median PR cycle time from 150 hours to 15. Stripe's Minions merges over 1,000 agent-written PRs a week. Ramp's Inspect - built on top of OpenCode with Modal containers - now accounts for more than 50% of their merged pull requests. None of these teams copied each other. They built independently, and they landed on the same architecture anyway.
That convergence is what makes Open SWE, LangChain's March 17, 2026 release, worth understanding in depth. It isn't a new coding assistant. It's an open-source, MIT-licensed distillation of the architectural patterns three production engineering organizations discovered the hard way - working independently, they arrived at similar architectural decisions, and LangChain noticed the convergence and open-sourced the pattern.
Why three companies independently built the same thing
While these systems were built independently, they converged on similar architectural patterns: isolated cloud sandboxes, curated toolsets, subagent orchestration, and integration with developer workflows. That convergence suggests some common requirements for deploying AI agents in production engineering environments.
The four shared decisions, stated plainly:
Isolated cloud sandbox. Tasks run in dedicated cloud sandboxes with full permissions inside strict boundaries. This isolates the blast radius of any mistake from production systems while allowing agents to execute commands without approval prompts for each action. Stripe pre-warms theirs to a 10-second spin-up. Stripe uses forked Goose with AWS EC2 devboxes and three-layer validation; Ramp composed on OpenCode with Modal containers and visual DOM verification; Coinbase built from scratch with agent councils and auto-merge capabilities.
Curated toolset. According to Stripe's engineering team, their agents have access to around 500 tools, but these are carefully selected and maintained rather than accumulated over time. Tool curation appears to matter more than tool quantity. Open SWE ships about 15 by default. The insight from Stripe's experience is that more tools create more surface area for the model to get confused - a 500-tool suite that's actively maintained beats a 2,000-tool dump that nobody audits.
Slack-first invocation. All three systems integrate with Slack as a primary interface, meeting developers in their existing communication workflows rather than requiring context switches to new applications. This is not a UX nicety. It changes adoption entirely: an engineer never has to open a new tool or change how they file work.
Rich context injection. The full Linear issue (title, description, comments) or Slack thread history is assembled and passed to the agent, so it starts with rich context rather than discovering everything through tool calls. An agent that has to ask for context wastes tokens and frustrates reviewers. Starting with assembled context is a forcing function that also improves output quality.
What Open SWE actually ships
Open SWE, released March 17, is an open-source framework built on LangChain's Deep Agents and LangGraph that provides the core architectural components for internal coding agents. The project is MIT-licensed and crossed 6,200 GitHub stars within days of release.
Rather than forking an existing agent or building from scratch, Open SWE composes on the Deep Agents framework - similar to how Ramp built on top of OpenCode. This gives you an upgrade path (pull in upstream improvements) while letting you customize the orchestration, tools, and middleware for your org.
Every major component is pluggable:
| Component | Open SWE default | What you can swap in |
|---|---|---|
| Sandbox | LangSmith | Modal, Daytona, Runloop, or your own |
| Model | Claude Opus 4 | Any LLM provider; different models per subtask |
| Triggers | Slack, Linear, GitHub comments | Email, webhooks, custom UIs |
| Observability | None (optional) | Datadog, LangSmith (encrypted at rest) |
| Tool scope | ~15 curated tools | Internal APIs, deploy systems, test runners |
The AGENTS.md pattern is worth calling out.
If the repo contains an AGENTS.md file at the root, it's read from the sandbox and injected into the system prompt. This is your repo-level equivalent of Stripe's rule files: encoding conventions, testing requirements, and architectural decisions that every agent run should follow.
It's a lightweight way to give every task access to institutional knowledge without bloating every system prompt manually.
The Deep Agents framework natively supports spawning child agents via the task tool. The main agent can fan out independent subtasks to isolated subagents - each with its own middleware stack, todo list, and file operations. This is similar to Ramp's child sessions for parallel work.
Beagle in action#engineering, 10:22amWhere Open SWE still trails the enterprise versions
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 most teams starting out, that's fine - you'll add validation layers as you learn where the agent makes errors in your specific codebase. But don't ship Open SWE straight to auto-merge.
The framework represents LangChain's 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 distinction matters for how you evaluate it. Open SWE is not a better Copilot. It's a different category: not every task needs an autonomous agent. LangChain acknowledges this: "For small one-liner bug fixes or simple style updates, this architecture is not optimal." The sweet spot is multi-step tasks - tickets that need code written, tests run, edge cases found, a PR opened, and a Linear comment posted. Work that would take an engineer 45 minutes to 3 hours.
Is this build-or-buy, really?
The framing of "build vs. buy" undersells what's actually happening here. While Cursor and Claude Code target individual developers with proprietary IDEs, Open SWE gives engineering organizations a customizable, self-hosted solution. No per-seat licensing. No vendor lock-in. You own the infrastructure and adapt it to your workflows.
The cost equation is also different. Commercial coding agents charge per seat or per task against a closed model API. An internal agent built on Open SWE routes task cost to whichever inference provider you configure - you can use Claude, GPT-5.6, or an open-weight model running on your own hardware. For teams running dozens of agentic tasks a day, that pricing flexibility matters. (See AI Inference Cost Per Task Is the Number That Actually Matters for how to think through that math.)
The honest caveat: use it as a starting point for building your own production coding agent, and expect to invest engineering time in customization, testing, and hardening. The gap between "I deployed Open SWE" and "I run Stripe-quality Minions" is measured in months of tooling work, not days. Stripe Minions merges over 1,000 PRs per week with no human-written code - but human review is required. That review pipeline, the three-layer validation, the curated 500-tool suite - none of that comes free with the framework. It's built by people who understand the codebase.
The point of Open SWE is not to replace that work. It's to make sure you're not also reinventing the scaffold.
Internal coding agent framework: common questions
What is Open SWE?
Open SWE is an MIT-licensed open-source framework from LangChain for building internal coding agents. Released March 17, 2026, it codifies the shared architecture that Stripe (Minions), Ramp (Inspect), and Coinbase (Cloudbot) independently developed: isolated sandboxes, curated toolsets, Slack-first invocation, and subagent orchestration.
How is an internal coding agent different from GitHub Copilot or Claude Code?
Commercial coding assistants are synchronous and IDE-embedded - you write, they suggest. Internal coding agents are async and long-running: they receive a task from Slack or a Linear ticket, spin up an isolated environment, write and test code over minutes or hours, and open a PR without the engineer staying involved.
Why do all the production internal coding agents use Slack as the trigger surface?
Slack-first invocation means engineers file tasks in the same channel where work is already discussed. There is no context switch, no new tool to learn, and no separate queue to check. The agent's PR and status updates come back to the same thread, keeping visibility where the team already lives.
What is the main risk when deploying Open SWE?
Validation depth. The three enterprise versions have multi-layer validation, CI gates, and in Coinbase's case, agent councils that review agent output before merge. Open SWE's default relies on prompt-driven linting. Teams should plan to add their own validation layers before allowing auto-merge, especially in critical services.
How does Open SWE handle internal tools and APIs that commercial agents can't access?
You add tools as plain Python functions. Because every task runs in an isolated cloud sandbox authenticated with your own credentials, the agent can call internal deployment APIs, run proprietary test suites, or query internal observability platforms - anything a human engineer with the right tokens could reach.