Estratos

The review workflow

Shared memory is only safe if you control what reaches it. Estratos routes writes through a review workflow based on the writer's role — and it works identically whether a person typed the change in the app or their agent wrote it over MCP.

Who publishes, who proposes

  • Owners and Admins publish directly. Their creates, edits, and deletes reach the shared graph immediately.
  • Basic users propose. Their creates, edits, and deletes become proposals that an approver reviews first.

See roles and permissions for the full role model.

What "pending" means for visibility

A pending proposal is usable by you and your agent right now, but invisible to everyone else until it's approved.

Concretely: if you're a Basic user and you (or your agent) create or edit a memory, you'll see your proposed content in your own retrievals immediately — a pending create appears in your bundle, and a pending edit's content replaces the published body for you. Everyone else keeps seeing only published content until an approver signs off. This lets you keep working with what you just captured while the review happens, without exposing unreviewed content to the rest of the org.

Who approves what

Approvers see each proposal as a diff and can approve and publish, request changes, or reject, with an optional note back to the proposer.

  • Scoped proposals can be approved by any Admin or the Owner.
  • Tagged proposals are Owner-only, because a tagged memory affects every place its layer or value applies — a broader blast radius that warrants the Owner's sign-off.

Approvers work the queue on Govern › Review.

The proposer's side

Proposers track their own proposals on Memories › My proposals:

  • If an approver requests changes, you can edit and resubmit the proposal.
  • You can withdraw a proposal that's still pending — for a create, that removes it; for an edit or delete, that cancels the pending change. (Deleting your own still-pending delete over MCP withdraws it, too.)
  • Once approved, the proposal materializes into the published graph and shows up for everyone.

Over MCP

Your agent doesn't need to know any of this — it just calls remember, remember_tagged, or delete_memory. If you're a Basic user, the server queues a proposal and tells the agent it was queued for review (with a preview of the key it will get on approval); if you're a publisher, it's published immediately. The agent's write is attributed to the client it came through, so the review queue shows who proposed it and via which client. See the MCP reference for the exact responses.

Next steps