← Pando

Amp’s decisions, out of the thread and into your notes

Amp and Pando, for decisions outside its threads.

A decision you reached with Amp last week, the retry policy or the name of a table, reaches this week’s new thread in one of two ways: you point the agent at last week’s thread, or somebody wrote the decision down. Amp is built for the first. Threads are stored on ampcode.com: "A thread is not tied to the device you started it on", and "The same thread opens in the web app, the CLI, and the Amp apps for iOS and macOS." Type @T- and a thread’s id in a prompt and the agent reads that thread and pulls out what matters for the task, or ask it to find threads by keyword, file or date. The second is where Amp stops: its agent writes no memory by itself.

Not by itself: Amp’s agent writes no memory of its own, though Amp stores your threads on ampcode.com, so a thread is not tied to the machine you started it on, and the agent reads an old one when you mention it or ask it to search. Connect Amp to Pando and have it write each decision into your outline, one line with its reason, where you read and correct it beside your own notes and where every other agent you allow reads it too.

Set it up

  1. In a terminal: amp mcp add pando https://pando.ink/mcp
  2. Start Amp in the terminal, and it opens the sign-in in your browser by itself. Approve it in Pando.

Amp’s docs say it starts the sign-in by itself for a server that offers automatic client registration, which Pando does: "When you start the Amp TUI after adding a URL entry to amp.mcpServers, Amp will automatically start the OAuth flow in your browser." That has not been run from Amp against Pando yet. If the sign-in does not finish, connect with a key instead, as further down. Amp’s docs recommend bundling MCP servers in skills for most uses, and name the CLI or the settings file for a server that "must be always available in the context window". A memory the agent should check before it assumes anything is that case.

Then give Amp the habit in one line of $HOME/.config/amp/AGENTS.md, on each machine that has the entry: before assuming, look in Pando, and when something is decided, write it there with the reason. Amp’s web app also keeps a Global AGENTS.md, under Settings, then Advanced, which is not tied to one machine. An orb does not have your machine’s entry, though, so put the line there only once Pando reaches your orbs as well, as further down.

Pando’s token has no expiry and no refresh token, so the sign-in holds until you revoke it. To stop Amp using Pando, revoke its key under Keys in Agents and API keys, and take the pando entry out of amp.mcpServers; amp config edit opens your user settings file, and amp config edit --workspace the repository’s .amp/settings.json. To connect again after a revoke, run amp mcp oauth logout pando, and add the entry again if you took it out; Amp opens the sign-in the next time it starts. That approval makes a new agent, which starts on your whole outline, so hold it to its branch again.

What you approve in Pando

Pando’s consent page offers two levels, “Read and write your outline” and “Read your outline only”. Either one starts Amp on your whole outline, and which one is selected when the page opens depends on what Amp asks for, so look before you allow it. A box beneath, ticked by default, makes a bullet under Home for Amp to remember in, named after whatever Amp calls itself when it registers, and Amp may write in that bullet even on read only. Untick it and Amp remembers nowhere until you give it a bullet under Agents and API keys.

Amp does not ask before it acts

Amp’s docs are plain about it: "By default, Amp does not ask for approval before running tools." Approved to read and write, then, Amp can change, move or delete anything in your outline without asking you first, unless you add a custom plugin that controls tool use, as Amp’s docs suggest. A delete takes the bullet and everything under it, though the Trash puts it back whole in one press; a line Amp rewrites has no undo button. Two things hold it back. A bullet you protect refuses every change Amp tries, and so does everything under it; a lock stops changes, not reading. And one press holds Amp to one branch: open that branch, open Agents and API keys in Settings, tap the row Amp’s sign-in made under Your agents, and press Let it reach only “…”, the bullet you are in, where the quotes hold that branch’s words. It then reads and writes that branch and what is under it, remembers there, and reaches nothing else in your outline, even if you approved it read only.

What Amp reads, its thread keeps

There is a second reason to hold it to one branch. What Amp reads from your outline comes back to it as a tool call result, and Amp’s security page lists what a thread keeps on Amp’s servers: "user messages, LLM responses, snippets of or entire code files used as context for the LLM requests, tool call results, and attachments." Without a workspace, a new thread is private. But "In a workspace, threads in workspace-owned projects are shared with the workspace by default", so a note Amp read into such a thread is one every member can open, and a thread you share as Unlisted opens for anyone with the link. Held to one branch, Amp cannot read the rest of your outline into a thread at all.

On your other machines

The entry stays on the machine you added it on: Amp’s docs say "A URL entry is still local configuration, even when the URL points to another machine." Run the same command on each machine you use Amp on. If Amp asks you to sign in there as well, untick the memory box on that sign-in: the approval makes a second agent in your Agents list, and it starts on your whole outline, whatever you did with the first one. If you held the first one to a branch, open that branch, open Agents and API keys, tap the new agent’s row under Your agents, and press Let it reach only “…”, the bullet you are in; the second one then reaches and remembers where the first one does. If the first one still reaches your whole outline, open its memory bullet instead, open Agents and API keys, and on the new agent’s row press Remember in “…”, the bullet you are in.

Amp can also keep the server as a remote definition on ampcode.com, which is "available across Amp clients without a local settings file", orbs included. Its sign-in goes through ampcode.com, and that route has not been tried with Pando yet:

amp mcp remote --personal add Pando https://pando.ink/mcp --auth oauth

With a key instead

A key made this way never puts Amp on your whole outline: it reaches nothing until you hold it to one branch, and one key serves every machine you put it on, as one agent with one memory:

{
  "amp.mcpServers": {
    "pando": {
      "url": "https://pando.ink/mcp",
      "headers": { "Authorization": "Bearer ${PANDO_KEY}" }
    }
  }
}

Amp’s own example sends the word token in that header; Pando reads the key after Bearer.

Your machine’s settings file does not reach an orb. Amp’s docs say "MCP servers configured in the settings file on your machine are not available there", and "Browser-based OAuth flows are unavailable in orbs." For an orb, commit the same entry to the repository’s .amp/settings.json, which Amp asks you to approve inside the orb, and set PANDO_KEY as a secret in your personal settings, which "apply only to your orbs". The entry then reaches everyone who works in the repository, and the key does not. Set in the workspace’s or the project’s settings instead, it would reach every orb there, other members’ included. A remote definition reaches orbs without a file, and Amp’s docs show one taking a key with --auth bearer and --bearer-token-file, which keeps the key on ampcode.com; that route has not been tried with Pando yet either.

What each place is for

Amp’s own documentation, the 53 pages its llms.txt listed on 23 September 2026, describes no memory its agent writes by itself. What gets written down is an AGENTS.md. Supermemory’s plugin for Amp, which recalls at the start of a run and saves outcomes at the end, comes from a third party and is not part of Amp.

When Amp’s threads are enough

If Amp is the only agent you use, its threads, @T- mentions and AGENTS.md already carry your work from one machine to the next, and Pando adds a step you do not need. The same goes for a team that works in Amp together: the agent searches your workspace members’ shared threads as well as yours, and a workspace admin can give everyone one Global AGENTS.md. For a decision about code, Amp leaves a trail as well: "Commits the agent makes carry an Amp-Thread-ID trailer, so git log leads from a change back to the conversation that produced it." And a thread comes out as Markdown, with .md added to its URL or with amp threads markdown and its id, so an agent that can run commands where you use Amp can read one too.

An agent that reads a thread gets the whole conversation to dig through, though, not the decision. The outline earns its place in two cases. An agent that is not Amp has to find what Amp decided without being handed a thread: Claude Code, Codex and Cursor connect to the same address, so what Amp wrote there on Monday is what Codex reads on Tuesday. Or you want the decision itself, a line you can read and correct, rather than a thread the agent reads again each time to pull it out.

What it costs

Nothing, for 1,000 bullets, with every feature included and no payment card. On Amp’s side, its announcement of 13 September 2026 says "Amp is now free to use when you bring your own compute and model subscriptions/keys", and its pricing page otherwise offers a choice: "Choose a monthly tier for the best value, or pay for what you use at standard rates."

Deeper

Connect an agent, about two minutes · The twelve tools · Which note apps an agent can reach · Who runs this