[sstriker]

Summary

The README and the reference stack described the memory server as the system. The memory server is one part. The sandbox, the egress and the tools also keep the system safe. The README did not name the sandbox, and the reference stack did not name the sandbox or the egress.

This change does these things:

1. The README's "What it is" section is now a list of the parts: the memory server, the launcher and its sandbox, the egress, the tools and the perimeter. It says that no one part is the safety boundary on its own.
2. The README says which calls the egress carries:
   • It carries the memory server's MCP to the harness.
   • It forwards the harness's model calls, and meters them.
   • It tunnels some model calls, and does not meter them. Copilot, Codex's ChatGPT login, Grok Build and Antigravity use tunnels.
3. The README says where each tool runs: in the amem process, on a tool server, or in the owner's browser.
4. The README defines a ceiling where it first uses the word.
5. The README says what a harness on amem serve keeps and loses, and how amem launch --unconfined is different.
6. The reference stack has two new rows, "Launcher and sandbox" and "Egress". The memory server row no longer says "ceiling check per outbound call", because the egress makes that check.
7. A new paragraph in the reference stack says which part makes which check. Sections 4, 6 and 7 name the launcher, the sandbox and the egress.

Reader test

This change touches only Markdown outside crates/ and taps/, so make check does not apply. In place of the adversarial pass, two fresh agents tested the text: a reader, and a check against the code. The procedure is in a separate PR.

I wrote these questions first:

1. A harness started with amem tries to connect to a website. Which part stops it? Which part decides whether a model call may go out?
2. You point a harness at amem serve over stdio. What protection do you keep, and what do you lose?
3. During a confined session, where are the API credentials? Does the harness hold them?
4. In the Foundation's deployment, is the egress a container in the shared stack? Where does it run?
5. Which parts enforce the grants, and what does each part enforce?

The reader read only the two changed files and the diff. The results for each round:

• Round 1: three answers were correct. The answers to questions 3 and 5 had gaps. The check against the code found six errors. The worst error: the text said that the egress forwards tool calls. The egress forwards only the harness's model calls.
• Round 2: all five answers were correct. The check found four errors that round 1 did not find. The egress does not meter a tunnelled call. A browser tool does not use the egress. The list of what the sandbox mounts was not complete. A harness on amem serve still uses an egress for a hosted tool.
• Round 3: all five answers were correct. The reader found five sentences with two possible meanings. The check found two lists that were not complete.
• Round 4: the reader answered all questions correctly in round 3, so only the check ran, on the changed lines. It found one more item for the sandbox list: the egress socket. I read the code and added the socket and the device nodes.

The reader also found problems in text that this change does not touch. Examples: "the compose file above" refers to no compose file, and the crate table in the reference stack names binaries that do not exist. These stay open.

Posted by Claude on behalf of @sstriker

[Copilot]

🟢 Approval recommended

The change is a self-consistent, documentation-only edit with preserved diagram alignment, intact table formatting, and no factual or grammatical issues.

No open issues 🎉

What changed in this PR

This PR updates prose and diagrams in README.md and docs/reference-stack.md to name the sandbox and the egress as distinct safety parts alongside the memory server, rather than describing the memory server as the whole safety boundary. It clarifies that no single component is the safety boundary, and that the memory server and the egress enforce the same grants while the sandbox confines the harness's network. The change is documentation-only and does not touch any crate code.

Changes:

• README: reworks the "What it is" paragraph to name the sandbox, label the diagram's confined box as "sandbox", and add a note explaining what "unconfined" stdio use means.
• reference-stack.md: adds "Launcher and sandbox" and "Egress" rows to the stack table, moves the per-call ceiling check from the memory server to the egress, and adds a paragraph describing which part does which check.
• reference-stack.md: names the launcher, sandbox and egress in sections 4, 6 and 7, including two new crate-table rows.

File	Description
README.md	Names the sandbox as a safety part, relabels the diagram box, clarifies unconfined stdio semantics.
docs/​reference-stack.md	Adds launcher/sandbox and egress rows, relocates the ceiling check to egress, and names these parts across sections 4, 6, 7.

I verified the ASCII diagram alignment is preserved (the old label "confined harness, no network" and the new "sandbox: harness, no network" are the same length, so the box borders still align), the markdown table rows keep the correct column counts, and the relocated "ceiling check per outbound call" claim is consistent between the README prose, the reference-stack table, and the new explanatory paragraph. No code is touched, consistent with the docs-only claim.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

It is a documentation-only change whose architectural claims I verified as accurate against the code, with no functional risk.

No open issues 🎉

_{Review effort: Balanced}