Scoped Routing: How Memplex Decides What an AI Tool Gets to See

When an AI tool asks Memplex for context, the obvious-sounding question is "what context does this tool need?" That's the wrong framing. The real question is: "what context is this tool, in this moment, for this user, on this task, allowed to see?"

The answer requires resolving nine variables before any retrieval runs.

The nine variables

1. Actor — who is this request on behalf of? A specific user, a service account, an automated agent?
2. Destination — which AI tool is asking? Claude in a browser, Claude Code on a local machine, Cursor, ChatGPT, a custom agent?
3. Scope — what high-level scope is the user currently operating in? Personal, work, client-facing, sensitive, public?
4. Task — what is the immediate task? Debugging, drafting, summarizing, research?
5. Project — which project does this task belong to?
6. Token budget — how much context can this destination consume in this request?
7. Source ACLs — what permissions does the actor have on the source artifacts?
8. Destination policy — what is this destination allowed to receive? (A consumer ChatGPT account, for example, may have stricter outbound policy than a self-hosted enterprise agent.)
9. Freshness — what is the user's tolerance for stale data on this kind of task?

The router evaluates these nine variables and produces a retrieval plan. Memories that match the plan are surfaced; everything else stays in the graph, invisible to this particular request.

Why this much resolution

The temptation in early-stage AI products is to skip routing — give the AI everything, let it figure out what to use. This works at small scale and breaks badly at any real scale.

Three failure modes:

Personal/work leakage. Your work AI shouldn't surface the personal note you wrote about a job interview. Your personal AI shouldn't surface a confidential project decision. Without explicit scope routing, this happens.

Project cross-contamination. If you work on three projects, the AI debugging Project A shouldn't see decisions about Project B. Vector similarity will absolutely surface them if you let it. The fix is project-scoped retrieval.

Sensitive-to-untrusted routing. A memory derived from a "M&A planning" source should not appear in a context request from a public-facing chatbot, even if the embedding is similar. Source-tagged sensitivity has to be a routing input.

Per-destination policy

Different destinations need different defaults. A self-hosted enterprise agent might have a 200K token budget and full markdown rendering. A consumer chat product might have 32K tokens, plain text only, and stricter sensitivity gating.

Memplex stores per-destination policy as a first-class config. When a request comes in identifying itself as destination X, the router applies X's policy automatically. The user doesn't have to remember which destination they're talking to.

Source ACL inheritance, again

The ninth variable, source ACLs, deserves its own attention. Memplex inherits ACLs from the source at ingestion and revalidates at retrieval time.

What this means practically: if a user has lost access to a Slack channel since the memory was ingested, the memory becomes inaccessible — automatically, no manual cleanup required. The source remains authoritative.

This is the property that lets Memplex be safely connected to enterprise data sources. You don't have to trust that we'll do the right thing with the data; you can verify that we mirror the source permissions exactly.

The router's output

The router produces a retrieval plan that looks roughly like:

"For this request from actor=sean, destination=cursor, scope=work, task=debug, project=atlas, with 50K tokens available: query the graph with lexical weight 0.5, semantic 0.2, traversal 0.3. Filter to memories with source ACL granting access to sean AND lifecycle state in (extracted, accepted, verified, pinned) AND freshness within 30 days for context, no freshness limit for decisions. Apply destination policy 'cursor-default' for format and sensitivity. Return up to 50K tokens with explain_inclusion trace."

That plan then executes against the graph. Memories that survive the filters are returned, with full lineage. Everything else stays where it is.

Why this is invisible to the user

A good routing system is invisible. The user doesn't think about scope; they just notice that personal context never accidentally surfaces at work, and work context never surfaces in personal chats. They don't think about per-destination policy; they just notice that each AI tool gets context that's the right size and format.

The price of invisibility is implementation rigor. Every retrieval is a routing decision. Every routing decision is logged via explain_inclusion. Every policy change is auditable. The system that feels effortless to the user is the result of nine variables resolved on every single request.