Orbs, Explained

Here are some of the letters we received in the last weeks: “Orb? What’s an orb?” “Ralph, loops, graphs, and now orbs?” “What the fuck are orbs?” “You can’t call them orbs” “I hate it when people say ‘it’s orbin’ time’ - I hate it when people have fun!” Okay, that last one’s made-up, threw it in there as a joke. You gotta keep your humour when people get offended by names. And at the same time, it’s easy to laugh because we also get many letters like this one: Original But how do I make you go from angry to happy? I’d say: try orbs! Go to ampcode.com and try them! But it looks like the name’s the problem, so, let’s talk about names. Amp is the name of our company and our product: a coding agent and a development environment. Orbs are part of our product: they are remote agents — coding agents that run in a remote machine (i.e. not your local computer) — and you can remote control them from ampcode.com, from your phone, or from our CLI. Yes, they are VMs, or sandboxes, or whatever you want to call them. Remote machines that we spin up for you, put your code into, and start the Amp agent on. They come in different sizes. But with orbs you don’t really have to think about the “remote” or the “machine” parts. Here’s how you run an agent in an orb: Go to ampcode.com Click New thread and type in your prompt Submit An orb will spawn up, with your code on it, and the agent will start running. This is what it looks like, uncut: Once the agent is idle, the orb will go to sleep. When you send another prompt, it will wake up again and so too will the agent. (Orbs can sleep for as long as you want: we’ve had orbs asleep for weeks and then came back to them. Doesn’t cost anything. You only pay when the orb is running.) You can watch and control the orb from anywhere: on your phone,…

“That's not SOC 2 compliant”

We’ve been sharing more about how we work: building Amp with Amp, orbs, killing features, no pull requests. And the most common reaction isn’t about the AI workflows or whatever kind of loop graph engineering is flavor of the week. It’s this: Wait, you don’t use pull requests? You push to main? How? That’s not SOC 2 compliant. Except it is. Skipping pull requests was a deliberate choice from the first commit. It’s a big part of how we build and why we can ship continuously. So when we started working toward SOC 2, we took that question straight to our auditors: “you need PRs for that… right?” Controls SOC 2 doesn’t require pull requests. It requires that you think about your risks. That’s the real answer we came away with. Auditors, and SOC 2 itself, are more flexible than you might assume. Ours didn’t ask us for pull requests; they asked what our change process was, and worked with us on a set of controls that fit it. The Trust Services Criteria never mention git or pull requests. What they ask for is that changes are authorized, tested, approved, and recorded — and pull requests are just one way of doing that. Here are the controls we landed on: Restricted push access. Access to main follows business function: every engineer at Amp can push, and most of Amp is engineers. But the percentage of people with access matters less than being able to explain exactly who has it and why. Signed commits. Pushing already requires authentication, but commit authorship is just metadata. GitHub enforces verified signatures on main, which makes the author on every commit verifiable. Automated CI. Every change runs through the full validation pipeline: tests, infrastructure checks, security checks. Bad changes block main. An audit trail that’s as good as a PR’s. Commits link to the…

Pave The Road

There is a network of dirt roads running through every software organization in the world. These roads, once traversed by tractors and Model Ts, are now jammed with a fleet of exotic cars, each one faster, more capable, more expensive than the last. The people traveling these roads are very excited about their new cars. One loves his new Ferrari, another is showing off her new Porsche, and a third won’t stop talking about that new BMW concept. Meanwhile, each and every one of them, regardless of brand, is bouncing down these dirt roads, stuck in second gear, because the roads they’re traveling weren’t designed with these cars in mind. And in just the same way that our driver’s new Ferrari won’t get him down these dirt roads any faster than his old car, the latest frontier model won’t help the businesses using it reach their destination any faster than the model from three months ago (there are, of course, narrow exceptions related to downside risks like Project Glasswing). The tasks that companies feed these models today — ticket-shaped, sprint-sized, reviewable — were saturated a model generation ago, much in the same way that your morning commute can be handled by a used Toyota Camry. Sure, it’s a lot more fun to drive a Ferrari, but not as your daily driver, and even the most ardent car enthusiasts would advise against it. So when these companies complain about token cost, they are doing so for good reason: they are paying for intelligence that they don’t know how to handle, intelligence from which they are (at present) organizationally incapable of benefiting. After all, what good is it if the latest model completes a task in five minutes, but it takes another five days to get deployed? Those five days are what we call the “software development lifecycle”. I know,…

What I Want to Tell You About Orbs

If I were to tell you the ingredients of a meal - ground beef, salt, pepper, cheese, flour, water, yeast, sugar, butter, egg - would that make you hungry? If I were to spell out how I cook it — turn the beef into two loosely packed balls; heat up a flat-top griddle so long it makes you wonder whether it won’t defy the laws of physics and start to glow; drop the meat on the griddle and flatten it by smashing a metal spatula down with all the force you have; season; wait thirty seconds; scrape it off the griddle, flip, throw cheese on it, wait again; lift and transfer to a bun made out of flour, water, yeast, sugar, butter, and egg through a combination of mixing, kneading, resting, shaping, baking, splitting, toasting — would your mouth then start salivating? Would your stomach produce that low involuntary sound that actually makes you realize your mouth started salivating and that the animal part of your brain has been activated? Probably not. But suppose I tell you this: patties thin enough for their edges to turn dark and brittle while the insides remain juicy; patties with a crust that crackles when you bite through it; cheese that no longer lies on top of the meat but has melted into it, filling every crusty crevice; a buttered bun that’s been toasted to just the right color, right to the point before something black would show; the whole thing so hot that you have to breathe through your mouth after you take a bite, so greasy that you wipe your chin after the first bite but don’t do that anymore after the second one because who cares. Then you might think: god damn, I could go for a burger right now. Now. That’s the riddle I have to solve with orbs. How do I make you salivate? I can give you the ingredients: secure sandbox; scale to zero; ephemeral; durable agent…

Putting an Agent in an Orb

After releasing Agents in Orbs on Tuesday we’ve been asked: how do you check what the agent did in a remote machine, don’t you miss your local development environment for that? The answer is: sometimes, and less and less so. Not only is the current generation of frontier models incredibly good at checking their own work, even in a remote machine, but with some additional tooling and documentation, they can go a very long way. We’ve been continuously optimizing our Amp codebase to be more agent-friendly, and it’s now gotten to a point where if you had told me half a year ago that it would be possible for an agent to do that, on a headless remote machine, an orb, I wouldn’t have believed you. Here’s an example. I asked Amp to find a button in our amp repository and show me a screenshot of it in different configurations: After a couple of minutes, it came back with exactly what I had asked for: Here I asked it to do a full run-through of our core functionality: And, again, after a few minutes it came back with proof: Note that in both cases I didn’t specify how the agent should go about doing any of that. I didn’t specify how to start the dev server, how to login, how to use the CLI, how to take screenshots. It figured it out by itself. It’s all in the codebase, the tooling, the documentation, and the orb. Let’s start with the orb. What’s in an Orb? Every orb runs Debian 12 and comes with a lot of tools already: authenticated gh (the GitHub CLI) and amp, PostgreSQL and Redis, tmux, ffmpeg, ImageMagick, ripgrep, Bun and Node.js, npm and pnpm, agent-browser, and a few other things. You can find the complete list here. In the Amp system prompt, we tell the agent that it’s running inside an orb and how to get more tools. Nearly everything is an apt-get install away. That’s…

Migrating a Mainframe... For Fun

The last time the COBOL programming language was meaningfully updated was in 2002 — I was 12 months old. The only time I have ever seen a real mainframe computer is in a museum. But I recently developed a fascination for these fossils and the programming languages that run on them. Why do so many legacy organizations still run their mission critical software on mainframes? We are seeing coding agents write 90%+- of code on more complex projects. Yet, if you are a technology leader at a bank, airline or insurer, it seems like your only path to modernization is to hire armies of consultants to place their stamp of approval on the project. Could it really be all that complex? Or is the complexity just a cover to sell more billable hours? I decided to find out for myself. So I opened up my terminal and set off with the following goal: Run an end-to-end mainframe to cloud migration writing 100% of code with agents How Does COBOL Work? Before getting my hands dirty, I needed to take a quick look at how the COBOL programming language actually works. As an example, I used a demo credit card management application. The app contains 30 programs, each of which manages a different part of the app lifecycle (managing accounts, paying bills, issuing new cards, etc…) Each program has deep interdependencies with the others, and business logic is entangled with UI navigation. When a user signs in, the login program writes their identity into a shared memory block; the runtime then calls downstream programs with that buffer. Programs don’t declare their dependencies. They just receive bytes in a buffer that everyone trusts were set correctly. This is a pretty significant departure from modern web app architecture. The challenge: Collapse each interactive terminal program into a single…

Feedback Loopable

To see my workflow for this project, I've made the following threads publicly visible: Setting up a playground to render the simulation as a static image. Building experiments with URL-driven velocity to make the bug repeatable. Making the inner loop fast with a headless CLI simulation. Agents are most powerful when they can validate their work against reality. When they have feedback loops. The problem is, some work is hard to organize in a way that an agent can easily get feedback. The software we build and the tools we use are built for humans. Humans with eyeballs and hands and fingers. This article is about how to make those problems easier for agents. It's a way to create an environment for your agents so that they can solve problems on their own, and so that you (the human) can intuitively guide them without getting in the way. This process of building something for humans using methods built for agents is what I call: making it feedback loopable. Built for Humans, Built by Agents # Here's the problem: The digital world has been built for humans. It's made of browsers that render pixels for our squishy eyeballs, and buttons that we click on with our gangly fingers. So much of the web and software are visual, or dynamic, or audible, or some other medium that's excellent for human consumption. But not for agents (at least not yet...). Even our software development tools have been built for (human) software engineers, and so are mainly visual. Think about the Chrome Developer Inspector, or the React Chrome extension - both wonders of human-focused tooling, but neither are something an Agent can make much use of without torturous workarounds. Agents like text. Lots of text. And, in a pinch, an image. But, really, they just really really love text. Making a problem…

How to Pair With an Agent

The gap between folks who use agents effectively and those who don’t is widening. Most people start their journey like a drunken sailor, reacting to whatever the machine spits out next, staggering through prompts without a clear destination. They end up effectively in the same place they started. The difference between those who go far and those who don’t is vision. Without it, you are simply reacting to events as they happen. If you’re an AI-maxi and are running Amp in 10 parallel tmux sessions, this might just confirm what you already know. But if you’re just getting started with coding agents, or if you’ve tried them and bounced off, this one is for you. We are reaching a point where agents can solve nearly anything you can specify. Consequently, the primary failure mode is under-specification. When you give an agent an unrestricted prompt, you get unrestricted results, which are almost never what you want. The more you can specify, the better. We spend a lot of time taking customers on this journey, and we want to distill it into a path to get you to that “oh shit” moment a little faster. We’re going to work through real examples together. By the end, you’ll have a mental model that actually works. The “Sitting Next to Me” Test You’ve been handed a bug. The back button isn’t working on the settings page. Your first instinct might be to treat your agent like a glorified search bar. Try this instead: imagine a capable peer sitting next to you. They’ve never seen your codebase, but they move at more than 10x your speed. Their only limiting factors are the tools they can access, the feedback loops they can see, and your ability to lead them. Vague prompt: Why isn't the back button working? Give them direction, not a question. Specified prompt: The back button on the…

A Codebase by an Agent for an Agent

When I’m coding there are many decisions I have to make that affect my ability to navigate the codebase: what’s a good name for this function? Should I make a new file for this type or should it be in an existing file? What should the file be called? Should I create a new directory for this? Not only do I have to decide these things, but I have to remember them. Every time I open Neovim I have to think about what past-Tim would’ve called this. Where would he have put it? I get hit with cognitive overhead on each side of the decision. The good thing is that now I can offload nearly all of this to an agent. Yes, I know, one shouldn’t, but hear me out. I did exactly that when I created the TUI framework behind the Amp CLI. The framework is a port of my Zig TUI library into TypeScript and it’s 90% written by Amp. And, as Thorsten and many others on the team, have said: Amp rips when working with this framework on the CLI. It plows through most anything you can throw at it. So much so that the question of “why is Amp so good at working on our CLI?” has come up multiple times. I think I have the answer. I think the answer is that I offloaded decisions to the agent. The thing is — I do care about the names of things and how the codebase is structured. Early on in the process of writing the framework I would often stop the agent — irritated by a change it made — and tell it to rename a function, move a file to a different directory, or put some class into its own file. I don’t enjoy making these decisions, but I still wanted to make them. There’s just some satisfaction from having things look nice in your codebase — so I would stop the agent and tell it “I know better”. But I don’t. I am not absolutely right, it turns out. Let me give you an example. The Amp TUI framework uses…

200k Tokens Is Plenty

Archived This note was written in December 2025 for an older model and context-window era. Now, auto-compaction makes longer threads work well, and it's fine and productive to go beyond 200k tokens. Opus 4.5 came out a few weeks ago and quickly became not only Amp’s main model, but also universally respected as the best model for coding — while having a context window of roughly 200k tokens. In the winter of 2025, that’s not a lot. A lot of people view this as a downside. But here’s the thing — 200k is enough for me, it’s plenty. I love short threads. I do all my work with short threads. So does the rest of the team. In fact, I took a look at a feature I just shipped for Amp, adding a thread: send to support command to the Amp CLI command palette. Here’s what it looks like as a cluster of interconnected threads: Feature: Add Thread Support Command Look at all those tiny threads! Look at the token counts, and the number of user messages sent. The biggest thread is 151k output tokens and four user messages. The average thread is around 80k tokens. Now think of the time when we had a 1 million token context window. I wouldn’t run a thread that long… But hey, there are 13 threads in that feature. Probably more, as these are only the threads connected by thread mentions. Add up all those and you’re close to one jam-packed 1 million token context window. So why not pile those all into one mega-thread and be done with it? Why bother with the tedium and drudgery of spinning up thread after thread with those puny, embarrassingly small contexts? Short Threads Are Best On the Amp team, we’ve known this for a while. The best threads are short, they do one thing, and they have just the right amount of context to do it. We’ve written about this in our guide on context management:…

How We Think About Permissions

In our experience, agents work best when they can get feedback about the changes they are making. For example, when they’re able to run tests and see the results of the test run. Taking tools away, like preventing the agent from reading certain files, makes the agent look for an alternative, like running a Bash command instead to access file contents. Most people do not worry about file edits anymore, because Git makes the cost of a wrong edit negligible. Restrictions aren’t necessary for tools like this with an easy undo action. Alternatively, you can set up rules for what the agent is allowed to do with and without asking you. This means Amp will interrupt you more frequently, but in exchange you can examine what Amp is about to do before it triggers a deploy, or accesses the production database. Amp’s Permission System allows for both modes of operation. “I don't want the agent to run npm exec.” You already rely on many sources of feedback, some of them very subtle, to develop software successfully. It’s the little red squiggles under a typo, the errors produced by the compiler, the failures you get when running your test suite. While state-of-the-art models are better than most humans at generating working code in one try without feedback, they still need feedback just like you to work effectively in real-world projects. This feedback allows them to iterate, finally converging on a solution that meets all the constraints imposed by the project, and your task at hand. Only through running external tools like the type checker and your test suite can the model learn about any mistakes it has made. With precise instructions like “Use npm test to run the test suite”, you’ll find the model doing just that when it’s time to run the tests. “AI just dropped my production…

Agents for the Agent

Amp now has subagents. Here’s what they look like in action: But chances are that the first sentence and even that screenshot didn’t cause your facial expression to change. After all: who even knows what a subagent is? So let’s start there. What’s a subagent? If you’ve read How to Build an Agent you know that we define an agent as “an LLM with access to tools, giving it the ability to modify something outside the context window.” Subagents are tools, too. They are agents that can be started by the main agent, the one you’re interacting with when you use Amp. Just like the main agent can invoke tools to edit files or run terminal commands, it can now also decide to spawn another agent when it thinks (“thinks” in airquotes) that’ll help. When it does, it passes a prompt to the spawning subagent and tells it what it should do. Just like we do, when we spawn an agent. It ain’t new Okay, that first sentence wasn’t entirely truthful. You might even say it was a lie, because subagents aren’t new to Amp. We’ve had one from the start and you very likely have seen it being invoked too: the search agent. It’s an agent that has access to read-only tools and that’s prompted to search your codebase. If the main agent has to answer a question such as “where in the codebase is the auth logic?”, it can spawn the search agent and ask it to “Find out where the auth logic is”. The search agent will then go, search, find the auth logic, and return what it found back up to the main agent. Like this: Over the past few months, we’ve also experimented with other types of subagents. Each type would have a different system prompt or a different set of tools, but they never turned out to be useful. Either their job was already covered by the search agent and it wasn’t even clear to us humans when…

Amp is now available.

Archived This note was written in May 2025 for a much older version of Amp. It isn't how Thorsten uses Amp anymore, but we're keeping it here for posterity. As of today, Amp, the frontier agent, is available to everyone. The waitlist is gone — go, go and sign up and use it! For the past 10 weeks, Amp has been the main tool with which I develop software and — putting yet another exclamation mark behind the fact that the tools we use end up changing us — it has fundamentally changed how I develop software. So I thought I’d use the occasion to write up how I personally use Amp. In VS Code You can use Amp in Visual Studio Code as an extension or as a CLI. I mainly use it in VS Code, constantly open on the right sidebar, constantly mashing ⌘I and ⌘L. If you’d told me four months ago that I would use VS Code as my main editor, I wouldn’t have believed you. But here we are. The only explanation I have is this: which text editor I use just doesn’t feel that important to me anymore. I don’t have exact numbers, but my guess is that Amp now writes 70-80% of the code I commit. That’s right — I barely write code by hand anymore. If I type code, it counts. Paint-by-numbers programming I think of coding with agents as paint-by-numbers programming: I put in the numbers and the lines and the agent then goes and puts in the colors. The agent doesn’t make architectural decisions for me, it doesn’t write critical code without close supervision, it doesn’t introduce a completely new structure to the codebase. That’s what I do. But once I know what that should look like, I put everything I know — architecture, possible edge cases, constraints, which tests to add and extend and run — into a prompt and send the agent on its way. Small Threads In general — and I’ll give you some exceptions…

FIF

Frequently Ignored Feedback Our responses to common feedback that we intentionally do not act on. “Make it so the user can switch models.” A model selector asks you to know which model is best for a task. The dial asks one question: how hard is this task? Its agent modes trade capability against cost. Amp chooses the models, prompts, tools, and reasoning effort behind each mode, and changes that wiring as models improve. The dial removes knobs from the default experience, not from Amp. Agent mode plugins let you define custom modes with your model, your prompt, and your tools, and they show up alongside Amp’s built-in modes. “I don't want it to edit files directly.” Requiring edit-by-edit approval traps you in a local maximum by impeding the agentic feedback loop. You’re not giving the agent a chance to iterate on its first draft through review, diagnostics, compiler output, and test execution. If you find that the agent rarely produces good enough code on its own, instead of trying to “micro-manage” it, we recommend writing more detailed prompts and improving your AGENTS.md files. “Make it so I can make my new threads private (not shared) by default.” Shared by default is the right default for workspaces. It results in more threads being shared, reduces the expectation that every thread must be “perfect” or “not dumb,” and makes collaboration feel more like sharing Google Docs edit history or Git branches. Thread visibility is configurable. Workspace admins can choose the default for new threads, and CLI users can configure defaults globally or per repository. Outside a workspace, threads are private by default. See Thread Visibility. “Add more safety controls or configurability over shell commands that it runs.” Amp does not try to protect against a malicious actor…

How to Build an Agent

It’s not that hard to build a fully functioning, code-editing agent. It seems like it would be. When you look at an agent editing files, running commands, wriggling itself out of errors, retrying different strategies - it seems like there has to be a secret behind it. There isn’t. It’s an LLM, a loop, and enough tokens. It’s what we’ve been saying on the podcast from the start. The rest, the stuff that makes Amp so addictive and impressive? Elbow grease. But building a small and yet highly impressive agent doesn’t even require that. You can do it in less than 400 lines of code, most of which is boilerplate. I’m going to show you how, right now. We’re going to write some code together and go from zero lines of code to “oh wow, this is… a game changer.” I urge you to follow along. No, really. You might think you can just read this and that you don’t have to type out the code, but it’s less than 400 lines of code. I need you to feel how little code it is and I want you to see this with your own eyes in your own terminal in your own folders. Here’s what we need: Go Anthropic API key that you set as an environment variable, ANTHROPICAPIKEY Pencils out! Let’s dive right in and get ourselves a new Go project set up in four easy commands: mkdir code-editing-agent cd code-editing-agent go mod init agent touch main.go Now, let’s open main.go and, as a first step, put a skeleton of things we need in it: package main import ( "bufio" "context" "fmt" "os" "github.com/anthropics/anthropic-sdk-go" ) func main() { client := anthropic.NewClient() scanner := bufio.NewScanner(os.Stdin) getUserMessage := func() (string, bool) { if !scanner.Scan() { return "", false } return scanner.Text(), true } agent := NewAgent(&client, getUserMessage) err := agent.Run(context.TODO()) if err != nil {…