AgentCore vs MemoryRouter: Branch History or a Shared Vault?

A user edits an earlier message. Your agent now has two possible conversation paths. Which path should the next prompt follow?

That is a history-reconstruction question. Asking what the same user decided in another assistant is a different request.

Amazon Bedrock AgentCore Memory has explicit event branching. MemoryRouter's documented MCP tools search a selected vault; they do not expose a conversation-branch selector. If your application needs an editable conversation tree, keep that requirement in the event store. If your work needs saved context in another supported AI tool, evaluate MemoryRouter's shared vault.

AgentCore can name the path through a conversation

AWS's CreateEvent guide describes branching for edited messages and alternative conversation paths. An event belongs to an actor and a session. To start a branch, supply its name and the rootEventId it starts from.

Reading the branch is a separate choice. The BranchFilter contract requires a branch name and accepts includeParentBranches. Set it explicitly when deciding whether the lookup should include parent branches. The API reference does not state a default for that field.

For example, this is a request-body fragment for ListEvents, not a complete authenticated request:

{
  "filter": {
    "branch": {
      "name": "edited-plan",
      "includeParentBranches": true
    }
  },
  "includePayloads": true,
  "maxResults": 100
}

The request URL still identifies the memory resource and actor, plus the session. Follow nextToken until there are no more pages; one response is not proof that you retrieved the entire history. maxResults is capped at 100.

AgentCore already has cross-session memory

Branch lookup is not the limit of AgentCore's memory system. AWS also documents long-term strategies that extract durable knowledge for semantic retrieval in later sessions.

Its current harness memory guide says the harness derives retrieval configuration from active memory strategies and injects relevant long-term memories before reasoning. An explicit retrieval configuration overrides that automatic derivation.

The same guide documents attaching existing memory when multiple harnesses need to share one memory resource.

So "AgentCore only remembers the current session" would be wrong. Check whether the requirement is already satisfied by its long-term retrieval before adding another service. A missing event in a branch listing and a missing fact in semantic retrieval need different investigations.

MemoryRouter searches a vault, not an event ancestry

MemoryRouter keeps saved conversational context outside the active chat, where compaction cannot erase it. The MemoryRouter MCP contract makes vault selection part of authorization. You can authorize another supported client to access that vault too.

search_memories takes a semantic query, with optional tier and importance filters. It returns matching memories rather than a replay of one conversation path. The documented inputs do not include an AgentCore session ID or branch name. There is no documented automatic import of an AgentCore event tree through this interface.

That distinction matters before you connect two systems. Saving a decision in the vault does not preserve its event ancestry. If you need the original branch to establish what the user saw, retain that evidence in the system that owns the conversation.

The MCP connection page covers the shared-vault route. Storage is hosted, and generic MCP saving and retrieval depend on the model making tool calls. Connecting a client does not prove it saved anything.

Evaluate the branch and the handoff separately

For an AgentCore evaluation, create a disposable conversation and fork it with a changed decision. Compare branch-filtered event results with parent inclusion enabled and disabled. Inspect the returned event IDs and payloads before putting them in a prompt. Test long-term retrieval separately rather than assuming the branch filter governs it.

For MemoryRouter, save one approved decision through store_memory, then search for it from a new conversation using a different supported client authorized for that vault. Inspect the actual search result. A queued save can take time to become searchable; repeat the search rather than submitting the save again.

Open a MemoryRouter account, then check whether your second client can retrieve the decision you saved.