Amp Code Guide: Setup, Modes, Skills, and Remote Agents

Amp changes so quickly that my original guide aged like milk.

The old npm installer is gone. The model lineup has changed several times. Toolboxes gave way to skills and plugins. Amp now runs on the web, on your phone, inside remote machines, and in orbs that keep working after your laptop closes. Even the old model-flavored modes were replaced by a simple dial from low to ultra.

That pace tells you almost everything about Amp’s philosophy. The team wants to stay on the frontier, and it is willing to delete yesterday’s workflow to get there.

Some people will find that refreshing. Others will find it infuriating. I enjoy it because Amp feels like a coding agent built by people who use coding agents all day and have strong opinions about what survives.

This guide covers the current product, how to install it, what the modes actually mean, and the Amp-specific features worth learning.

Updated for August 2026: This is a full rewrite. It covers the current installer, capability dial, automatic subagents, Oracle, skills, plugins, durable threads, web and mobile control, orbs, remote runners, and Puck.

What Is Amp Code?

Amp is a multi-model coding agent that works in the terminal, compatible editors, and the web.

The terminal loop will feel familiar if you have used Claude Code or another coding agent. Amp searches the repository, reads files, edits code, runs commands, uses tools, and keeps going until it believes the task is done.

Its personality comes from a few product decisions:

• Amp chooses the model stack. You choose how much capability the task deserves.

• Threads are durable objects you can share, reopen, and control from another device.

• Subagents are part of the default workflow instead of a feature you have to orchestrate manually.

• Skills and plugins extend the agent without dumping every instruction and tool into its context.

• Remote execution is a first-class experience. An agent can keep running in an orb or on a machine you control.

Amp calls itself opinionated, and that is accurate. You get fewer knobs over the underlying model provider than you do in a bring-your-own-model harness. In exchange, Amp continuously updates its routing, system prompts, tools, and specialist models.

The question is whether you trust those opinions.

Installing Amp

On macOS, Linux, or WSL, use the current installer:

curl -fsSL https://ampcode.com/install.sh | bash

Then open a project and run:

cd /path/to/your-project
amp

Amp asks you to sign in on the first run. It can connect to VS Code and VS Code-based editors, Neovim, and Zed. Open the command palette with Ctrl+O and choose ide connect if the editor connection does not happen automatically.

You can also use Amp on the web without installing anything. For repository work, I still prefer starting in the terminal because the agent gets the exact local environment, dependencies, Git state, and test commands I am already using.

The Five Shortcuts Worth Remembering

You do not need to memorize the whole keymap. Start with these:

• Ctrl+O opens the command palette.

• Ctrl+S switches the capability mode.

• Ctrl+G opens your current prompt in your editor.

• Ctrl+R searches prompt history.

• Ctrl+\ shows or hides the thread sidebar.

Use @ to mention a file when you know it matters. Let Amp search when you do not. Manually attaching half the repository usually wastes context and anchors the agent on your first guess.

Test It on a Real Bug

My favorite first test for any coding agent is a bug with an expected outcome and enough room for the agent to investigate.

Users are intermittently charged twice when the payment webhook is retried.

Trace the webhook flow and find the cause. Add a regression test that reproduces
the duplicate charge. Propose the smallest safe fix, implement it, and run the
relevant test suite. Explain any remaining race conditions.

That prompt tests repository search, causal reasoning, tool use, test design, and restraint. A beautiful one-shot landing page tells you very little about how an agent will behave in your production codebase.

Amp’s Capability Dial

Amp used to expose modes with names tied closely to particular models. That made the selection age badly. Models move fast, and users had to understand the current model lineup before choosing the right mode.

The current dial asks a more useful question: how hard is this task?

Low

Use low for narrow, obvious work:

• Rename a symbol across a small package

• Add a missing test case

• Fix a typo or update documentation

• Answer a focused question about one file

Low mode prioritizes speed and cost. A task with hidden architectural consequences will often need more help.

Medium

medium is the default for normal engineering work:

• Fix a bug that requires investigation

• Build a well-scoped feature

• Refactor a small subsystem

• Review a pull request

This is where I would start until a task proves it deserves more compute.

High

Use high when the problem is difficult and the route is uncertain:

• Debug a failure spanning several services

• Design a migration with compatibility constraints

• Review a security-sensitive change

• Untangle an unfamiliar architecture

High gives the main agent deeper reasoning and access to a strong second opinion through Oracle.

Ultra

ultra is for open-ended work with many unknowns:

• A framework migration across a monorepo

• A broad performance investigation

• A feature that crosses application, infrastructure, and data layers

• A project where the agent must discover the plan while working

The dial is not a quality setting you should leave at maximum. Overshooting spends more money and can make a simple task slower. Undershooting can be even more expensive when the agent makes a bad change, gets corrected, and tries again three times.

Choose the lowest mode that can plausibly solve the task in one clean run. Move up when the agent is missing relationships or repeatedly revising its plan.

Amp changes the exact models behind these modes as the frontier moves. That is part of the product contract. You select a capability budget, while Amp handles model routing.

Oracle and Automatic Subagents

Amp has two different ways to get another model involved.

Oracle

Oracle is a second-opinion specialist for difficult reasoning and analysis. The main agent can call it during a debugging session or review. You can also ask explicitly:

Use Oracle to challenge your diagnosis before changing any code. Ask it to look
for a simpler explanation and any failure modes your proposed fix misses.

I use this when the cost of a wrong theory is high. It is especially useful after the main agent has gathered repository context, because Oracle can critique a concrete diagnosis instead of starting another blind investigation.

Do not summon Oracle for every task. A second expensive model agreeing that a variable should be renamed is performance art.

Subagents

Amp automatically spawns subagents when a task benefits from isolated or parallel work. Each subagent gets its own context window and tools, then returns a result to the main agent.

This works well for:

• Searching a large repository for all callers of an old interface

• Running independent review passes for security, correctness, and tests

• Investigating separate hypotheses for a bug

• Researching a dependency while the main agent works on local code

The isolation is both the benefit and the limitation. A subagent does not inherit every nuance of the main conversation, and you cannot guide it through a long task in the same way. The main agent also has to reconcile the results.

For review, Amp can launch a separate subagent for each check. This is a good use of parallelism because the reviews are independently useful and their outputs can be combined at the end.

For implementation, define boundaries first. Two agents editing adjacent parts of an undocumented interface can produce two internally reasonable halves that do not fit together.

Setting Up Project Context

Amp reads AGENTS.md for repository instructions. If you already maintain one for Codex or Factory, you can use the same file.

Ask Amp to inspect the repository and draft the first version, then edit it yourself. Include commands, architecture, conventions, and dangerous operations the agent should avoid.

# Repository instructions

## Commands

- Install dependencies: `pnpm install`
- Run development server: `pnpm dev`
- Run unit tests: `pnpm test --run`
- Run typecheck: `pnpm typecheck`
- Build: `pnpm build`

## Architecture

- Keep business logic in `packages/core`
- API routes should validate input and call the core package
- Database access belongs in `packages/db`

## Working rules

- Read the nearest tests before changing behavior
- Add a regression test for every bug fix
- Prefer existing abstractions over new dependencies
- Never modify an applied database migration
- Do not push or deploy unless the prompt explicitly requests it

The file should contain stable facts. Temporary task details belong in the thread. A specialized workflow belongs in a skill.

For large repositories, place additional AGENTS.md files inside packages with different commands or conventions. This gives Amp specific guidance when it enters that part of the tree without making the root instructions enormous.

This is the foundation of good context engineering. The prompt starts the task. The repository’s context system teaches the agent how your team works.

Skills, Plugins, and MCP

The extension story is the biggest practical change since my original Amp guide.

Skills

Skills package instructions and resources for a repeatable task. Project skills live in .agents/skills/. User-wide skills can live under ~/.config/agents/skills/ or ~/.agents/skills/.

A skill might teach Amp how to:

• Deploy this application and verify the release

• Create a database migration using your team’s conventions

• Run a security review against an internal checklist

• Produce a changelog from merged pull requests

• Build a slide deck using a company template

Skills are cleaner than placing every possible workflow in AGENTS.md. Amp discovers and loads them when the task matches. I explain the broader pattern in my Claude Skills guide and the governance problem in my enterprise skills guide.

MCP Inside Skills

A skill can include an mcp.json file that starts the MCP servers required for that workflow. Their tools stay hidden until the skill loads.

That is a much better default than connecting every MCP server globally. A large tool list consumes context and makes selection harder. It also gives the agent capabilities that have nothing to do with the current task.

For example, a browser-testing skill could load a browser MCP server and expose only navigation, screenshot, click, and form tools. A Linear triage skill could load the Linear server and expose only issue-search and issue-update actions.

If you are new to the protocol, start with my MCP guide. The short version is that MCP gives the agent a standard way to discover and call external tools.

Plugins

Plugins can add tools, commands, and agent modes. Amp uses model-mode plugins to experiment with new models without redesigning the core interface.

For example, Amp exposes an optional Kimi K3 mode as a plugin:

amp plugins add --auto-update @amp/kimi-k3-mode

That is an interesting way to try the open-weight Kimi K3 model inside a mature coding harness. The model gets Amp’s tools and workflow while the plugin keeps experimental choices outside the default mode dial.

Treat third-party plugins and skills as code. Read them before installation, especially when they include scripts, MCP servers, or broad tool permissions.

Permissions and the Trust Boundary

Amp’s default tool behavior is aggressive. It runs tools without asking for approval each time. That keeps the loop fast, and it means you need to think about the environment before you start.

A coding agent can read untrusted repository instructions, web pages, tool output, issue descriptions, and MCP responses. Any of those can contain instructions that try to redirect the agent. Permission prompts provide one layer of defense. Removing them makes isolation more important.

My baseline:

• Use Git and begin significant work on a branch.

• Keep secrets out of files the agent can read whenever possible.

• Run unfamiliar repositories in a disposable development environment.

• Give MCP servers the narrowest useful tools and credentials.

• Review the diff and the commands that ran before pushing.

• Keep deployment credentials away from ordinary coding sessions.

Amp supports policy plugins for stricter environments. Teams should define these centrally instead of asking every developer to invent a personal safety model.

The goal is not to make the agent incapable of action. Tool use is the whole point. Give it a workspace where mistakes are visible, reversible, and contained.

Threads: Amp’s Real Unit of Work

Amp calls conversations threads. That sounds cosmetic until you use them across devices and machines.

A thread records the prompt, model work, tool calls, outputs, and changes associated with a task. You can share it with a teammate, reopen it later, or move between the terminal and web interface.

Use one thread per task. A thread that begins with an authentication bug, drifts into a landing-page rewrite, and ends with a deployment carries a lot of irrelevant history. Start a fresh thread when the objective changes.

Good shared threads are more useful than screenshots of a final diff because they show how the agent reached the result. A teammate can see the prompt, the evidence, the dead ends, and the validation.

There is a privacy tradeoff. Review the thread before sharing it. Tool output can contain internal paths, logs, issue content, or other information that never appears in the final answer.

Orbs and Remote Agents

Amp has grown from a terminal program into a distributed agent system.

Orbs

Orbs are remote machines managed for Amp. A thread can run there after your laptop closes, and you can watch or steer it from the web or your phone.

They make sense for long builds, large test suites, repository migrations, and tasks you do not want consuming your local machine. They also create a clean execution boundary for agent work.

Your Own Remote Machine

Amp can also accept remotely created threads on a machine you control. Enable remote creation in settings, or ask Amp to enable it. Run the client in headless runner mode:

amp --no-tui

That runner waits for new threads in its working directory. You can start work from ampcode.com and choose the machine and project where it should run.

This is useful for a home server, cloud development box, or a machine already configured for a particular repository. The security boundary matters again. A remote runner exposes the capabilities of its user account and working directory to tasks you can start from the web.

Use a dedicated account, narrow credentials, and an isolated project directory. Do not turn your daily-driver shell account into a general-purpose remote agent host.

Puck

Puck is Amp’s meta-agent for navigating projects, threads, and context. Once you have several agents running in several places, finding the right thread and understanding what is active becomes a coordination problem of its own. Puck sits above individual coding tasks and helps manage that surface.

This points toward Amp’s broader bet: developers will supervise a collection of ongoing agent threads instead of living inside one terminal conversation.

A Practical Amp Workflow

Here is the workflow I would use for a meaningful feature.

1. Start With Repository Evidence

Investigate how team invitations currently work. Identify the API route,
authorization checks, database records, email flow, and tests. Explain the
current behavior and likely extension points. Do not change files.

Correct misunderstandings before implementation.

2. Ask for a Plan

Plan support for expiring invitations after seven days. Include the data
migration, API behavior, resend flow, UI states, background cleanup, and tests.
Call out assumptions and decisions that need my input. Do not implement yet.

Amp does not need a special planning mode. A clear instruction works.

3. Choose the Mode From the Plan

If the change is local and obvious, stay on medium. Move to high if the plan reveals tricky compatibility or data concerns. Use ultra when several packages or systems need coordinated changes.

4. Implement in a Fresh Thread

Keep the approved plan in a temporary file or another durable project artifact, then begin implementation with clean context.

Implement the approved plan in docs/invitation-expiry-plan.md. Work in small
commits. Run focused tests after each layer and the full relevant suite at the
end. Stop and ask if the code contradicts the plan.

5. Run Independent Review

Review the completed diff. Use separate subagents for correctness, security,
database migration safety, and missing tests. Reconcile their findings and fix
confirmed issues. Do not make stylistic changes unrelated to this feature.

6. Verify the Actual User Flow

Tests are evidence, not the whole experience. Run the application and verify the path a user takes. For UI work, check the relevant viewport sizes and error states. For API work, exercise success, failure, retry, and authorization cases.

This general workflow also appears in my AI coding playbook. Amp’s modes, subagents, and durable threads make it easier to execute, but the discipline still comes from you.

Where Amp Fits

Amp is a good fit if you want:

• Strong model routing without managing several provider accounts yourself

• A fast terminal agent with automatic subagents and a second-opinion model

• Skills and plugins that load capabilities on demand

• Threads you can share and continue across terminal, web, and mobile

• Remote agents that run in managed or self-hosted environments

• A product that changes quickly as models and agent patterns improve

That final point is also the catch. Amp will remove workflows it no longer believes in. Teams that need a frozen interface, long deprecation windows, or precise control over the underlying provider may prefer a different tool.

The cost can also climb when you use high or ultra mode, Oracle, and several subagents on every request. Capability routing works best when you exercise judgment instead of turning every dial to eleven.

I still love Amp’s vibes. More importantly, the product now has a coherent idea behind them. Threads are durable, models are interchangeable components, extensions load when needed, and agents can run wherever the work lives.

That makes Amp one of the most interesting coding agents to watch, and a very fun one to use.