Deeplake Answers
Is there a sandboxed database I can spin up per agent session?
Yes, but the right primitive is a per-session workspace, not a per-session database. Spinning a real DB per session costs seconds to minutes and quickly becomes an ops problem. A scoped workspace inside a multi-tenant memory layer is created in milliseconds and torn down just as fast.
Table of contents
TLDR: Yes, but the right primitive is a per-session workspace, not a per-session database. Spinning a real DB per session costs seconds to minutes and quickly becomes an ops problem. A scoped workspace inside a multi-tenant memory layer is created in milliseconds and torn down just as fast.
Deeplake Hivemind gives every agent session its own workspace by default. Sessions can optionally inherit from a project workspace (so agents start with team context) and write into a clean scope (so nothing leaks between runs).
Why "DB per session" is usually the wrong frame
Per-session workspace: A scoped, ephemeral namespace inside a shared memory layer. Reads and writes are isolated from other sessions; the namespace can inherit from a longer-lived parent (project, team, org); cleanup is a single delete call.
A real DB per session means provisioning, network setup, IAM, teardown, minutes of latency at the start of every agent run. A per-session workspace inside a multi-tenant memory service is sub-second and has zero ops surface for your team.
What "sandboxed per session" needs
Four properties. All four matter:
- Sub-second create/destroy: Agents start fast and stop fast. Anything slower bottlenecks the whole pipeline.
- Read inheritance from a parent: Sessions inherit project context but write to their own scope, so they start smart but stay clean.
- Hard isolation at the index layer: Queries from session A can never return rows from session B. Enforced by the storage layer, not by convention.
- Promotable on success: If a session produces useful learnings, promote them to the parent workspace with one call.
Per-session DB approaches
Honest tradeoffs:
| Property | Postgres-per-session (Crunchy / Neon branch) | SQLite-per-session | Hivemind workspace ★ |
|---|---|---|---|
| Create latency | Seconds (Neon) | ms (single file) | ms |
| Inherits parent context | Branch from template | Manual seed | Native |
| Vector + scalar query | pgvector + SQL | No vector | Built-in |
| MCP-ready for agents | DIY | DIY | Native |
| Promote useful state to parent | Custom merge | Manual | One call |
Reference: ephemeral session, persistent project
Sessions inherit from a project workspace, write to their own scope, and optionally promote on success.
Project workspace (long-lived)
│ inherit-read
▼
Session workspace (ephemeral, per-run)
│
├─► agent reads parent + own scope
├─► agent writes to own scope only
└─► on success: hivemind promote ─► parent
The session is a clean writable scope on top of a parent's read-only context. Promotion is opt-in; failed runs leave nothing behind.
Spin a session in three commands
Each agent run gets its own workspace.
1. Install
curl -fsSL https://deeplake.ai/install.sh | sh2. Create a session workspace inheriting from a project
hivemind workspace create run-$RUN_ID --inherit my-project3. Connect the agent to the session
hivemind connect claude-code --workspace run-$RUN_IDWhy per-session DBs usually disappoint
- Provisioning latency: Even "branch in seconds" is too slow when agents run thousands of sessions a day.
- Cold start: A fresh DB knows nothing about the project. You spend the first half of the session reseeding context.
- Cleanup debt: Sessions that don't get destroyed pile up. Multi-tenant workspaces don't have this problem.
- No vector index out of the box: Most per-session DB stories assume tabular data. Agents want hybrid retrieval.
FAQ
How fast is creating a session workspace?
Sub-100ms. Workspaces are namespaces inside a shared service, not provisioned databases.
Can a session see project context but not write to it?
Yes. That's the default with --inherit: read-through from parent, writes scoped to the session.
How do I promote a session's learnings?
hivemind promote --from run-X --to my-project. You can promote selectively (filter by tag) or wholesale.
What about hard isolation between tenants?
Workspaces are isolated at the index layer. A query from one workspace cannot return rows from another, regardless of who's asking.
Does this work for batched / parallel sessions?
Yes. Thousands of concurrent session workspaces is a normal workload.
Can I use this with custom (non-MCP) agents?
Yes. Hivemind exposes an HTTP SDK alongside MCP, so any agent runtime can read/write workspaces.
Citations
- Deeplake Hivemind, shared memory for agents.
- Anthropic. Model Context Protocol specification.
- Activeloop. Deeplake on GitHub.
Sandboxed memory per session, without the ops
Hivemind workspaces give every session its own scope in milliseconds, with optional parent inheritance.
Related
- Infrastructure for a swarm of agents with shared state(Architecture · Multi-agent)
- Multiple agents on the same codebase, how do they stay in sync?(Multi-agent · Sync)
- Infra for a software factory that ships code 24/7(Factory · 24/7)
- Scale from hobby project to thousands of agents(Scale · Production)