HomeBlogPricingCareersDocsGitHubSlack community
Field notes/Community builds/Persistent State for AI Agents with Tensorlake Cloud Volumes

Persistent State for AI Agents with Tensorlake Cloud Volumes

Five experiments on one evolving workspace: persist state, replace the compute, recover a known-good version, mount it read-only, and share it across concurrent workers.

SBX-01C4SBX-01E3SBX-0202SBX-0221SBX-0240SBX-025FSBX-027ESBX-029DSBX-02BCSBX-02DBSBX-02FASBX-0319SBX-0338SBX-0357SBX-0376[ RUNTIME: ACTIVE ] P50 2.45S · P99 4.12S · 5M/PROJECT

Raj runs five experiments against a single Cloud Volume and refuses to treat a successful API call as proof of anything. Every artifact is verified by byte length and SHA-256 read back through the volume, not from inside the sandbox that wrote it. Sandbox A writes stage one and is terminated, Sandbox B mounts the same volume and carries on, a permanent snapshot preserves the known-good tree while the live filesystem moves ahead, and a snapshot-pinned read-only mount rejects an attempted write with EROFS. The line to keep is his own: replace the compute, preserve the workflow state. The guardrails section earns its place too, in particular that volume changes publish asynchronously and that concurrent writers still need a path each rather than a lock.

We didn’t write this one — it’s Raj Kumar’s piece, published on Medium. The note above is ours; the full article is theirs.

Read the full piece on Medium Code on GitHub
RK
WRITTEN BYRaj KumarCommunity · Medium
Read next —FROM THE LOG
◆ THE SANDBOX DIGEST

Subscribe for release notes, benchmarks, deep dives.

One dispatch per month from the Tensorlake team — no spam.