Context Engineering and Prompt Management
Context Isolation — Stack
Context isolation › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
What matters is not whether a mechanism separates things in the common case, but whether every path that could carry content is covered and whether a breach would be visible.
- Completeness of mediation. Whether the boundary key is applied by construction on every path — retrieval, caching, embedding, logging, derived artefacts — or has to be remembered at each call site.
- Failure direction. What happens when the key is missing. Returning everything is the default in most query APIs and is the wrong default here.
- Cache keying. Whether every cache layer can include the boundary identity in its key, and whether that includes caches operated by a provider rather than by you.
- Cost of a clean context. How much has to be re-established when a sub-task starts fresh, since the cost of isolation is what drives teams to inherit context instead.
- Return-path narrowing. Whether a boundary crossing can be constrained to a typed value rather than to free text.
- Residue. Whether anything survives the end of an isolated unit — pooled objects, warm caches, background jobs holding a reference.
- Testability. Whether a cross-boundary leak can be provoked deliberately in a test environment, which is the only way to know a control works.
- Observability without re-aggregation. Whether traces and prompt captures can be stored such that the observability store does not become the place where everything is mixed.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Separate conversation and thread identity per task | The common case: stopping unrelated work from accumulating in one context | Nothing enforces it; a product that silently reuses a thread for a new topic has no boundary at all |
| Sub-agent invocation with a fresh context (LangGraph subgraphs, OpenAI Agents SDK handoffs, Claude Agent SDK subagents, CrewAI tasks) | Analysing untrusted material, and keeping a child's exploration out of the parent's history | Most frameworks pass the parent's messages by default; the return value is usually free text unless a schema is imposed |
| Per-tenant namespaces or collections in vector stores (Qdrant, Pinecone, Weaviate, pgvector schemas) | Hard separation of retrievable material without a filter that someone can forget | Namespace-per-tenant scales poorly past a few thousand tenants; filter-based separation scales and depends on every query being correct |
| Row-level security in the datastore (PostgreSQL RLS and equivalents) | Making the boundary a property of the database rather than of the application | Only covers what the database serves; embeddings, caches, and derived summaries sit outside it |
| Tenant-scoped cache keys across every layer (application caches, semantic caches, rendered-prompt caches) | Closing the single most common leak path | Provider-side prompt caching is keyed by content and organisation, not by your tenant; it needs its own reasoning |
| Separate provider accounts, projects, or API keys per tenant | Strong separation of anything the provider retains, including its own caches and abuse logs | Operationally heavy; quota, rate limits, and cost reporting fragment along the same lines |
| Process or container isolation per request (sandboxed execution, ephemeral workers) | Eliminating residue from pooled state entirely | Startup cost per unit of work; does nothing about shared downstream stores |
| Canary markers injected per context | Detecting a leak rather than preventing one | Only catches verbatim carryover; a leak that passes through a summary will not reproduce the marker |