Amp treats an agent as a model in a for loop with tool calls, so builders can change the model, tool descriptions, and iteration process.
2
Amp focuses on a small custom tool set and uses specialized subagents to find context, reason about difficult problems, access external documentation, and perform large refactors.
3
Amp is designed around the review bottleneck, with a custom diff viewer, editor integration, shared threads, and sponsored inference for its faster Rush agent.
Summary
Beyang Liu presents Amp as an opinionated coding agent built around a small set of architectural choices. Amp runs from the terminal and connects to editors such as Emacs, Neovim, JetBrains IDEs, VS Code, Cursor, and Windsurf. Its interface shows diffs and commands without exposing every model token, while its editor view helps developers review agent-written code. Liu says code review has become the main limit on running more agents, so Amp built a diff viewer with code navigation and a guided tour of changes. The agent uses specialized subagents, including Finder for codebase search, Oracle for difficult reasoning, Librarian for external library context, and Kraken for large code modifications. Liu argues that broad MCP tool collections can confuse agents and that tool calls consume context. Amp also offers Smart and Rush modes, shared threads, and ads that help pay for Rush inference. The talk closes with Amp's builder community and its deliberately strange identity.
Amp is built around the idea that coding agents are strange and still changing fast
Beyang Liu describes Amp as an "opinionated frontier agent" and says the team wants to embrace the "awe and absurdity" of agents writing more code. The booth's strange imagery, including a pied piper riding a floating golden fish, reflects that attitude. Liu compares current work with how developers worked a year earlier and says it feels completely different. Amp aims to operate like an agent research lab living one year in the future, exploring how software development changes as agents take on more coding tasks.
The terminal and editor interfaces show enough agent activity for review without flooding the user
Amp built its terminal UI framework from scratch to use modern terminal capabilities. The interface streams diffs and shows the CLI commands the agent runs, while avoiding every token of model explanation. Amp connects to editors including Emacs, Neovim, and JetBrains IDEs to collect diagnostics related to the task. Its editor integration works with VS Code and derivatives such as Cursor and Windsurf. Liu says he now writes much of his code through the agent panel rather than manually editing files.
Amp treats code review as the limit on how many agents a developer can run
Liu says the main bottleneck in his editor is reading agent output and reviewing the resulting code. That prevents him from running two or three times as many agents in parallel. Amp's review interface is intended to guide developers through what the agent wrote so they do not ship sloppy or spaghetti code. The custom diff viewer lets users choose any commit range, inspect file-level diffs, edit those diffs, and use code navigation such as go-to-definition and find-references. A change tour recommends which files to read first.
An agent is a model inside a for loop with tool calls, which gives builders a small set of powerful controls
Liu defines an agent's core as a for loop with tool calls and a model in the middle. He says builders can change the model, the tool descriptions, and how the model iterates with its tools. Those controls may sound limited, but he compares them with programming languages, where if statements and for loops can produce wide variation in behavior and complexity. The tool set is especially important because it determines how an agent finds and closes the feedback loops needed to complete a task.
Amp prefers a focused custom tool set because generic MCP tools can create context confusion
Liu argues that MCP servers cannot be tuned to an agent's specific task because the server creator does not know what the agent is trying to accomplish. Amp therefore puts most of its effort into a core custom tool set designed around the feedback loops its agents need to close. He also says every extra tool added to the context gives the agent more choices. When irrelevant tools are present, the agent has a harder time choosing what to use. Amp's position is that a refined tool set is more useful than a large collection of loosely relevant integrations.
Subagents prevent context exhaustion while giving Amp specialized ways to work
Tool descriptions are not the only source of context use. Tool calls also consume the context window, especially when a coding agent greps and reads many files before editing. Asking an agent to read less can create a doom loop, where it lacks enough information and retries the same action. Amp sends subtasks to separate subagent context windows and returns only relevant results to the main agent. Finder searches the codebase, Oracle handles difficult reasoning, Librarian fetches information about libraries and frameworks, and experimental Kraken writes codemods for large-scale refactors.
Amp chooses agent-oriented modes instead of exposing a long model selector
Amp has two top-level agents, Smart and Rush. Smart can use the specialized subagents and handle more complex instructions, while Rush is faster for targeted edits that keep the developer closely in the loop. Liu says developers generally use agents in two ways: they can start a task and review it later, or they can watch and review edits one by one. Amp chooses points on the speed and intelligence frontier that match those working styles. Liu says the team has optimized Smart for its chosen model rather than lightly customizing one harness for many models.
Amp uses ads to help make its faster inference available for more side projects
Liu says cost remains a major barrier to using coding agents fully, especially for students and people working on side projects. Amp's team considered placing ads in the terminal and eventually shipped a small ad network for developer tools. The ads appear in Amp's terminal and editor and are intended to stay subtle. Amp uses the ad revenue to sponsor inference for the Rush agent, making it possible for more people to try agent-assisted coding without paying the full cost of every request.
Amp's builder community is aimed at people willing to experiment with unusual ways of working
Liu says Amp is not intended for everyone yet and is targeting people who want to live a little in the future. He names Mitchell Hashimoto and Hamel Husain as users whose work fits that audience. Amp also supports a builders community run by Ryan Carson, whose earlier startup Treehouse taught more than a million people to code. Using Amp is not required. The group features interviews with people building or using agents in interesting ways and holds in-person events that mix practical discussions with broader questions about AI.
"We're trying to lean into that sense of awe and absurdity that I think we all experience right now living in this weird world we're living in where agents are writing an increasingly large amount of our code."00:39
Who should watch
You are building a coding agent and need a simple way to think about the controls available in an agent loop.
Your agent spends too much context searching files, or gets stuck after being told to read less.
You are deciding how an agent product should divide work between terminal use, editor review, specialized subagents, and model choice.
