How Per-User Tool and Memory Scoping Reshapes Orchestrator Routing in Multi-Agent Pipelines

Per-user tool and memory scoping determines both what an agent may access and where an orchestrator can send work. A product that gives every customer an isolated AI agent needs persistent per-user memory, tool credentials bound to that user, and API-driven provisioning and teardown. A single provisioning call is not proof of isolation. The runtime must enforce those boundaries on every task and handoff.

Why routing in multi-agent pipelines is harder than it looks

The orchestrator picks the right agent for the job. A search task goes to a search agent, and a writing task goes to a writer. That picture works only if the agent can see the required context and use the required tools when the task arrives. Its role alone does not establish either condition.

In a single-agent system, one context window, toolset, and memory store make capability relatively easy to see. A multi-agent pipeline distributes those resources across workers whose permissions can differ at runtime. An agent may understand a request perfectly and still lack the customer history or account access needed to complete it. The orchestrator therefore has to match work to an agent’s current scope, rather than treating agents with similar roles as interchangeable workers.

What agent memory scoping actually means and the access levels it creates

Memory scoping divides stored context into distinct access levels. Private memory belongs to one agent and includes its internal reasoning traces, draft outputs, and working state. Other agents cannot read it. Shared memory serves a defined group, giving its members access to handoff summaries, escalation context, and team knowledge. Global memory holds material available to every agent, such as system configuration, product knowledge, and organization-wide policies, with writes typically restricted.

A support pipeline makes these levels easier to picture. A triage agent has private working notes, participates in its team’s shared support context, and reads the global knowledge base. An engineering escalation team has its own shared context, which the triage team cannot see. Both teams read the same global material.

These boundaries reflect responsibility. Sharing everything exposes private data and fills agents’ context with unrelated material. Sharing nothing breaks handoffs and makes users repeat information. The three-level model provides room between those extremes, so agents can collaborate without exposing all their working state. That alignment with team responsibilities also makes the boundaries easier to govern.

How scope boundaries become routing constraints the orchestrator cannot override

Once memory has boundaries, routing already has limits. An agent that cannot read the facts needed for a task is not an eligible destination, even if its role sounds right. Sending it the task anyway can produce a functionally wrong result from an otherwise capable model.

Visibility follows a hierarchy. An agent serving one user in one run should see its own memory, the run, that user, that user’s organization, and the global tier. It should not see another user’s memory or another tenant’s records. Routing toward a more specific agent can respect that hierarchy when the necessary context is available within its scope. Routing across a boundary cannot make inaccessible context available merely because the orchestrator wants the work done.

A supervisor can delegate to a worker that lacks the context to execute correctly. In a sequential pipeline, an upstream agent can write a result into private memory that the next agent cannot read. Parallel workers can reason from different subsets of state and return results that cannot be cleanly merged. Dynamic handoffs can loop when the receiving agent lacks the context needed to proceed. None of these failures requires a worse model.

Tool scoping as the second half of the routing constraint

Memory determines what an agent can know about a task. Tools determine what it can do about it. Pipeline-parallel orchestration research identified as arXiv 2607.15257 in 2026 illustrates that distinction through role-scoped toolsets. It reserves schema and task mutation for the orchestrator, browsing for explore and search agents, skill loading for search agents, and outline and state access for writers. Those tool boundaries define which tasks each role can validly receive.

Credential design makes these action boundaries enforceable. When agents share credentials, the orchestrator cannot use those credentials to tell them apart, and a compromise puts all the access they share at risk. Per-agent static keys improve attribution but leave standing privileges in place. Per-task dynamic tokens let routing reflect what an agent is authorized to do now. Capability-based scoping attaches permissions to signed tokens that the orchestrator can revoke mid-flight, making authorization responsive to a changing task.

Roughly five to ten distinct tool scopes per agent is a useful guide when designing the system, and production write access should need a separate approval path. Each agent should have its own identity and short-lived credentials. Secrets should never sit in prompts, system messages, or memory, where prompt injection can expose them. A credential broker should instead check the current task against policy before it issues credentials at runtime.

How Composio's connected-account model illustrates per-user tool authentication as a routing input

When an agent acts for a human, the user is also part of the scope. The same agent role may need different permissions for different people. Composio stores users’ OAuth credentials in connected accounts, allowing an agent to act for the right person without the agent or orchestrator touching the token directly. User identity can therefore become an explicit routing input.

An agent that checks Gmail for keywords and creates Notion tasks must use the intended user’s accounts. Routing it into the wrong user context can cause it to read the wrong inbox as well as return an inaccurate answer. Similarly, a GitHub-label-to-Linear-issue workflow requires access to the right repository and the right workspace. Having both tool names available does not show that the agent has the right permission for either.

Composio’s catalogue, as of August 2026, listed more than a thousand toolkits exposing tens of thousands of individual tools through a single MCP endpoint. That breadth makes separating credential management from agent reasoning especially important. A large catalogue does not make every tool eligible for every task. The routing question remains which user’s connected accounts authorize this particular action.

What context window pressure does to routing when scope is not enforced

Without scope enforcement, the orchestrator can accumulate context from every worker. Over time, the task state an agent needs must compete for space with unrelated histories, intermediate outputs, and private working notes. More context is not automatically better context. The model can spend attention on irrelevant entries and incorporate them into responses, while the system pays for tokens that do not improve the result.

With parallel fan-out, that waste spreads across the pipeline. Each extra agent that gets unscoped context uses more tokens and adds another chance for private information to appear in the wrong response. Loading every other agent’s conversation history costs more as the number of agents grows. In a multi-tenant product, the same failure can move customer data across tenant boundaries. Context pollution is therefore a quality, cost, and privacy problem at once.

Two warning signs call for scoping action. Conversation history and tool outputs may consume the large majority of the context window, or the distinct tool count may rise to around a dozen. These are signals to examine what each task actually needs. Context-aware routing can materially reduce token usage without harming accuracy by avoiding irrelevant material. Without it, a small demo can become a production pipeline whose routing decisions worsen as accumulated state grows.

How Claude Code, OpenClaw, Hermes, and Codex handle scope boundaries differently — and what that means for routing

The boundary can sit in different places. A 2026 academic analysis, arXiv 2604.14228, characterizes Claude Code as emphasizing per-action safety, OpenClaw as emphasizing perimeter-level access, and Hermes Agent as applying per-action approvals across many surfaces. For routing, the distinction is whether authority is checked around an environment, at an individual action, or across several points of execution.

OpenClaw supports independent agent instances for different users or purposes through different channels. Its opt-in sandboxing offers agent, session, or shared scope, with Docker, SSH, and OpenShell backends. Within that sandbox configuration, agent scope is the default. Sandboxing itself defaults to disabled, however, and skills run with full user permissions, while the default loopback binding limits network exposure and leaves tenant isolation to explicit scope settings for cross-user routing.

Hermes separates per-turn delegation from durable coordination. Its strict per-turn delegation default operates beside a Kanban layer through which multiple agent processes can share a persistent board. That board works for pipelines that need shared state during long-running work, and its loopback defaults, session logging, and human approval for dangerous commands add more controls. Persistent shared state still needs limits on who can use it.

OpenAI’s “Running Codex safely at OpenAI” guidance recommends OS-backed keyring credential storage and operator-defined workspace controls. That is not evidence that credential and scope management automatically move into OpenAI’s infrastructure. For an orchestrator, workspace boundaries and credential handling remain design inputs rather than guarantees inferred from the product name.

The production checklist: what scope enforcement actually requires at runtime

Every agent should have its own identity and short-lived credentials, with tools, data, and budget limited to its task. Policy must be checked on every model call, tool call, and handoff. A boundary checked only when an agent starts does not establish whether a later action is allowed.

Enforcement belongs beneath the orchestrator’s routing logic. Namespace isolation, row-level security, and a credential broker should enforce access at the data and credential layers. Application-layer filters alone can be bypassed by a misbehaving or compromised agent. The orchestrator should read scope state from the enforced layer and use it to determine eligible destinations, rather than trying to make its routing choices serve as the access-control mechanism.

Handoffs need the same checks as tool calls. Context passed between agents should contain only what the receiving agent is allowed to see. Otherwise, the handoff itself bypasses the memory boundary that routing was supposed to respect. Installation choices also need review, because an MCP server or plugin runs with whatever access its own process has. Approval modes and careful routing do not remove that supply-chain risk.

Why per-user scope is the prerequisite for scaling an agent-powered product to multiple customers

For a customer-facing agent product, these controls define the unit of scale. Each customer needs an isolated, persistent agent, provisioned automatically at onboarding. Persistent memory preserves continuity, while per-user tool credentials keep actions tied to the correct accounts. Giving an agent a separate label does not give a customer a separate environment without both.

A platform that offers a per-user AI agent sandbox through a single API call must still enforce memory and tool boundaries for as long as the agent exists. For white-label delivery, each client needs an isolated instance. Provisioning and teardown should be API-driven, with scope enforcement handled by the platform.

Setting up, monitoring, and recovering a separate instance for each new customer adds work in proportion to customer count. Automatic provisioning takes away that setup work only if the instances it creates have runtime isolation. The decisive criterion is whether the orchestrator can route each customer’s work without crossing that customer’s memory, credential, or execution boundaries.