Amp Code: The Coding Agent Spun Out of Sourcegraph, Explained

Amp, at ampcode.com, is a coding agent and development environment made by an independent company of the same name. Sourcegraph launched it in 2025 and spun it out as a separate company that December. You give Amp a task in a thread; it reads your code, edits files, runs commands and tests, and keeps going until the work is done. It runs in the web app on a remote machine Amp calls an orb, in a terminal CLI that can connect to VS Code, Cursor, Windsurf, Zed or Neovim, and in apps for Mac, iPhone and iPad. You pick a mode rather than a model, Amp mixes models from several labs behind it, threads can be shared with your team or anyone with the link, and it reads AGENTS.md and connects to MCP servers. One thing to know before anything else: Amp does not ask for approval before it runs tools.

Who makes Amp now

On December 2, 2025, Sourcegraph announced that Sourcegraph and Amp were becoming independent companies↗ (opens in a new tab). Sourcegraph kept code search and code understanding under a new CEO, Dan Adler, while co-founders Quinn Slack and Beyang Liu founded Amp Inc. with the Amp team. Amp’s own site now describes the company as an independent agent research lab, and its terms of service name the company Amp Frontier Corporation. So older articles that say “Sourcegraph Amp” or “Sourcegraph’s Amp” describe the same product under its first owner; Sourcegraph’s own code search, and its MCP server, are a separate thing.

Where it runs

• Web and orbs: start a thread at ampcode.com and Amp works in an orb, a fresh, isolated machine it creates for that thread with your code and tools set up. You can close your laptop; the orb sleeps when the agent is done and wakes with its files and services when you send the next message.
• CLI: amp starts an interactive session on your own machine, amp -x "prompt" runs one prompt and exits, and amp --executor orb sends the thread to an orb instead. It runs on macOS, Linux and Windows through WSL.
• Editors: the current docs describe connecting the CLI to your editor rather than a separate editor agent. Run amp in the editor’s terminal and choose ide connect; Amp then sees the open file and selection, and edits through the editor with undo.
• Apps and Puck: the Mac and iOS apps add notifications and dictation, and Puck is a personal assistant that starts, watches and messages your agents, including from Slack.

Modes and models

Amp calls its mode picker the Dial: low for small, well-defined tasks, medium as the default, high for hard work where a subtle miss is expensive, and ultra for open-ended migrations and cross-cutting changes. A thread keeps the mode it started with; to change mode, you start a new thread. Each mode bundles a main agent model, reasoning effort, a system prompt, tools, and an oracle, a second model the agent can consult for a second opinion.

The models behind each mode change as better ones arrive, and Amp publishes the current routing on its Modes page. When this was written it mixed models from Anthropic, OpenAI and Google, plus GLM models, across the main agents, oracles and helpers. You can pin a model per role in Settings, bring your own API key, or link a ChatGPT subscription so OpenAI usage bills there; Amp’s Modes and Models page↗ (opens in a new tab) also notes that Claude Fable models on your own Anthropic key need a workspace with data retention turned on.

Threads, and how Amp shares them

A thread is one conversation with the agent: your prompts, its replies, every tool call and every changed file, at a URL that opens on the web, in the CLI and in the apps. You can continue it from another device, point a new thread at an old one with @T-…, and the agent’s commits carry an Amp-Thread-ID trailer, so git log leads back to the conversation that produced a change. Adding .md to a thread URL returns it as Markdown.

Sharing is set per thread. Amp’s threads documentation↗ (opens in a new tab) lists four levels: Private (you, plus workspace admins), Workspace, Group (Enterprise only), and Unlisted, which lets anyone on the internet with the link open it. Without a workspace, new threads are private. In a workspace, threads in workspace-owned projects are shared with the workspace by default, and admins can turn off sharing outside it. Workspace and group members can also be given Contribute access, which turns on multiplayer so they can prompt the same agent. Check a thread’s visibility before you paste anything sensitive into it.

AGENTS.md

Amp’s project instructions live in AGENTS.md, read from several places. Its AGENTS.md guide↗ (opens in a new tab) says files in the working directory and every parent up to your home folder are always included, files in subfolders are added when the agent reads a file there, and personal guidance can live in ~/.config/amp/AGENTS.md. Workspace admins can set a Global AGENTS.md for every member, and organizations can deploy a system-wide file. Where a directory has no AGENTS.md but has AGENT.md or CLAUDE.md, Amp reads that instead.

Two features go beyond most tools: an AGENTS.md can @-mention other files, including globs, and a mentioned file can carry globs in its front matter so its rules load only when the agent touches matching files, such as TypeScript conventions for **/*.ts. How other agents resolve their files is in AI context files compared, and a starting file is in AGENTS.md examples.

MCP servers

Amp is an MCP client for local and remote servers. Its MCP page↗ (opens in a new tab) recommends bundling a server inside a skill where you can, so its tools load only when needed, and otherwise adding it with the CLI or under amp.mcpServers in your settings file. Many remote servers sign you in with OAuth automatically. Remote definitions can also be stored by Amp for yourself, a workspace or one project with amp mcp remote, and amp.mcpPermissions allows or rejects servers by URL or command.

amp mcp add fenbs https://fenbs.ai/api/mcp

Subagents

Amp hands focused work to specialist subagents, each with its own context window: Search for fast codebase retrieval, the Oracle for hard reasoning and planning, the Librarian for research across external codebases, and Read Thread for summarizing other threads, plus general task workers for splitting independent work. They run in isolation, cannot talk to each other or be steered mid-task, and return only a final summary to the main agent. Plugins can define custom modes and custom subagents, for example a reviewer with your team’s instructions. Claude Code’s version of the same idea is covered in Claude Code subagent examples.

Permissions: Amp does not ask first

This is the biggest practical difference from most agents. Amp’s tools page↗ (opens in a new tab) says plainly that it does not ask for approval before running tools. To limit what it can do, you write a plugin that controls tool use, which workspace admins can publish for everyone, and you can disable specific tools by name with amp.tools.disable in settings. Enterprise workspaces add an MCP registry allowlist, thread visibility controls and per-user usage quotas. In practice, an orb is the safer place for open-ended work, because the agent has its own machine rather than yours, and any MCP server you connect should hold only the permissions you are happy for it to use unprompted.

Amp vs Claude Code, briefly

• Maker and models: Claude Code is Anthropic’s and runs Claude models. Amp is independent and routes each mode to models from several labs, Claude among them.
• Approvals: Claude Code asks before edits and commands by default, with permission modes and allow, ask and deny rules to change that. Amp runs tools without asking, and control comes from plugins and settings.
• Where the agent works: both run in a terminal on your machine and in the cloud. Amp’s orbs are central to its web app; Claude Code also has IDE extensions, a desktop app and the web.
• Instructions: Claude Code reads CLAUDE.md, and AGENTS.md only when there is no CLAUDE.md. Amp reads AGENTS.md first and falls back to CLAUDE.md.
• Threads and subagents: both delegate to subagents with their own context. Amp also treats the thread as a team object, shared, searched and referenced by URL, with commits pointing back to it.

Neither is better in general. Amp suits teams that want an opinionated agent, remote machines per task and shared threads; Claude Code suits people who want Claude models, approvals by default and a local-first loop. Other options are mapped in Claude Code alternatives and the best AI coding agents.

Keep the task list outside the thread

Amp’s threads hold the conversation for one task, which is exactly why the list of tasks belongs somewhere else. fenbs keeps it on a board every agent can reach over MCP: tasks in To Do, Next Up, In Progress and Completed, each with a note, a plan and a test status, and History recording which assistant changed what. An Amp thread can pick up a task, put its thread URL in the note, and move the task along; a Claude Code session can pick up the next one from the same board. Because Amp will not stop to ask before calling fenbs tools, connect it with a hand-issued token that has a name, only the scopes it needs and an expiry, which you can revoke on its own under Settings.