Amp's Orbs move the agent off the laptop

We love Amp. We love the product’s nerve, the speed at which it changes and the team’s willingness to remove a workflow when the models have made a better one possible. Amp describes that policy without hedging: it goes where the models take it, with no promise of backward compatibility and no obligation to preserve legacy features. That can make the tool demanding to follow. It is also why Amp keeps producing ideas worth following.

Orbs are the clearest recent example. Amp defines them simply: “machines in which an agent can run without supervision.” Start a thread in an Orb and Amp creates a remote machine for it, clones the project, applies its configuration, runs the repository’s committed setup and starts the agent there. Close the laptop and the work can continue. Open Amp from another device and the same thread is still the place where the work lives.

Remote coding agents are not a new category. The important part is how little Orbs ask the user to treat remote work as a separate product. The thread, machine, repository, terminal, file review and return path are joined. The agent leaves the laptop without making the work feel distant.

A thread becomes a place

An ordinary agent thread contains messages, context and tool calls. It can be saved, shared, searched and referenced from another thread. Put that thread in an Orb and it gains a filesystem and a machine that persist beyond the device from which the prompt was sent.

For a project-backed Orb, Amp starts from a fresh clone. Project settings supply configuration, secrets and the repository connection. A No Project Orb starts with an empty workspace. The current environment is Debian 12 and includes the tools expected in a working development machine: Git, SSH, gh, amp, tmux, ripgrep, Node.js, Bun, package managers, Python, browser automation, ffmpeg and ImageMagick among them.

That list matters less as inventory than as intent. An Orb is not a queue that accepts one prompt and returns one patch. It is a development environment. The user can open the Terminal pane into the same filesystem and working copy as the agent, inspect a process, install a dependency, edit a file or run a test. The terminal uses a tmux session shared with the agent, so its output and changes remain part of the same working place.

This is the design decision we find most compelling. Amp has not hidden the remote machine behind a narrow task interface. It has made the machine available without making machine management the main job.

Remote and local are one path

The shortest Orb workflow starts from the CLI:

amp -ox "Investigate why the latest CI run on main failed"

Amp creates the Orb, prepares the repository and starts the thread remotely. The user can leave it running, inspect its changed files in the web interface and enter its terminal when direct control is useful. If the work belongs in a local checkout, one command brings it back:

amp sync <thread-id>

amp sync mirrors the Orb thread’s changes into the local working tree while the agent continues remotely. The handoff is not a zip file, a pasted diff or an early commit made only to move state between machines. It is a synchronization path from the thread’s working copy to the developer’s own checkout.

That continuity changes what remote execution is good for. A long investigation does not need to occupy the laptop. Several independent questions do not need to compete for one local working tree. A setup can run while the user moves to another device. None of this proves that the resulting code is correct or that parallel work is always faster. It removes one physical constraint and keeps the review path open.

Amp’s launch note is careful about the boundary. The team says easier remote creation changed how it works and argues that agents without local resource conflicts make parallel investigations and long-running experiments more practical. It also says, “How exactly this will play out we don’t know,” and expects some code to remain local, under close supervision and with substantial back and forth. That uncertainty makes the argument stronger. Orbs do not require every coding task to become remote. They make remote execution available at the point where the task earns it.

The environment can belong to the repository

The durable part of any remote-agent system is not the machine image Amp chooses today. It is whether a repository can say how its environment should work.

Orbs support .agents/setup, an executable repository setup script, and .agents/resume, a fast and idempotent hook for a machine returning from pause. Long-running development processes can be declared in .amp/services.yaml, allowing Amp to supervise them across CLI updates and Orb pause and resume. Portal manifests can expose those services through authenticated browser links.

Portals close another loop. Ask the agent to start the application, open its Portal from the thread and review the running result without first moving the repository home. Access follows thread visibility: only people who can view the thread can access its Portals. A request to a Portal can wake a paused Orb, restart its services and resume billing.

The same environment model extends into identity. Secrets and environment variables can be scoped personally, by project or by workspace. An Orb can also mint a short-lived OIDC token identifying its workspace, project, user and thread, which gives infrastructure teams a route to cloud access without storing a long-lived credential in project settings.

These features move Orbs beyond disposable compute. Setup, resumption, services, previews and workload identity are the parts that let remote execution become an operating practice rather than a demo.

Unsupervised does not mean ungoverned

Amp’s definition is exact and easy to overread. An agent can run without supervision. That does not mean its work no longer requires review, its tools are harmless or its environment is free.

Orbs are billed by the minute. The current manual lists four sizes from one CPU and 2 GB of memory at $0.08 per hour to 16 CPUs and 32 GB at $1.32 per hour, with the largest size as the default. A paused Orb costs nothing and Amp automatically pauses one after 15 minutes without activity. Portal traffic can wake it and restart the bill. Enterprise workspace rates are 50 percent higher. The June launch note described every Orb with the largest specification; the current manual’s size table is the better record of the product as it exists now.

The security model also needs deliberate work. Amp does not ask for approval before tool execution by default. A remote environment can contain repository credentials, project secrets and network access. Workspace-level values apply broadly. Thread visibility determines who can reach a Portal. Private repositories outside GitHub need credentials configured through the environment. OAuth-authenticated MCP servers are not yet supported in Orbs.

Webhooks make the boundary sharper. A plugin in an Amp-managed Orb can expose a public endpoint, receive an event, wake the machine and run a handler. Delivery is at least once, Amp does not verify an external service’s signature automatically and the webhook URL must be treated as a password. The handler must authenticate what it receives, reject untrusted instructions and tolerate duplicate delivery. Remote execution increases the value of explicit permissions, short-lived identity, idempotency and visible logs. It does not remove them.

These are not reasons to avoid Orbs. They are the engineering facts that keep enthusiasm useful. Move compute away from the laptop and resource contention falls. Move credentials and execution into a remote machine and a new operating boundary appears. Good infrastructure makes both sides visible.

What Amp is cooking

Amp’s wider product explains why Orbs feel coherent. The team treats the thread as the unit that carries context and tool history. It uses subagents when independent work benefits from separate context windows. It offers the Oracle as a slower, more expensive second opinion for hard reasoning. It lets threads move through the CLI, editor and web rather than forcing one interface to own the work. Orbs extend that same idea from context into execution.

Our reading is that an Orb is the harness around a thread made concrete. The model reasons, but the machine gives it a repository, tools, identity, services and time. The thread records what was asked and what happened. The terminal gives the user a direct way in. File review and amp sync give the work a way back. Each part is ordinary on its own. Their continuity is the product.

That is what we love about what the Amp team is cooking. Orbs do not pretend that autonomy eliminates engineering. They make room for an agent to keep working, then preserve the surfaces where a developer can inspect, intervene and take ownership. The laptop stops being the boundary of the agent without ceasing to be the place where the developer controls the result.