Every AI agent generates files: configs, intermediate artifacts, model outputs, logs. The working state of an agent session lives somewhere on disk. Where does that state go, and what happens to it when things break?
The options today are not great:
At scale (thousands of agents, millions of repos), none of these hold up.
Tensorlake’s Git Repositories feature takes a different approach. You mount a versioned repo as a local directory. No clone. No download. The agent writes files with standard tools like echo, cat, and Python's open(), while the platform handles versioning, crash safety, and publishing behind the scenes.
It’s Git semantics without Git’s operational weight.
I spent a week testing this hands-on. Here’s what I found.
Before the walkthrough, here’s the mental model. Tensorlake’s Git Repositories system has seven core concepts, and understanding them makes every CLI command intuitive.
The pipeline:mount(no clone) →autosave WAL(crash-safe) →snapshot(private) →promote(publish).
Everything below comes from a live Tensorlake Sandbox running CLI 0.5.89. Every command shown produced the output you see.
First, create a repo and push initial content. In 0.5.89, tl git push no longer takes a path argument, so you cd into your worktree first:
$ tl git create exp89$ cd /tmp/push-content$ tl git push exp89 main -m "initial content"pushed bf52db70... → refs/heads/main (3 files)
Three files pushed. The repo exists on Tensorlake’s git server, cloneable with standard git. No .git directory needed in the source because the CLI handles it.
Now mount the repo as a local directory:
$ tl git mount exp89:main /tmp/mnt-expMounted exp89:main at /tmp/mnt-exp (workspace ..., WAL checkpoint every 30s; no commit or branch is created)
That’s it. /tmp/mnt-exp is a normal directory. You can ls it, cat files, pipe output into it, open files with Python. Under the hood, a FUSE filesystem streams content lazily from the server.
Every 30 seconds, your changes are silently checkpointed to a WAL: a durable recovery point that doesn’t create any commits or move any branches.
$ echo "## Notes" >> /tmp/mnt-exp/README.md$ echo "Added with CLI 0.5.89" >> /tmp/mnt-exp/README.md$ cat /tmp/mnt-exp/README.md# Experiment 0.5.89## NotesAdded with CLI 0.5.89
When you’re ready to create an explicit checkpoint:
$ tl git snapshot /tmp/mnt-exp -m "add notes"Snapshot aa4f2d05f693 (1 file(s), 1 of 1 chunks uploaded in 821ms)
Here’s the key insight: after the snapshot, the branch HEAD is unchanged. I verified this by cloning the repo via standard git:
$ git clone https://t:$TOKEN@git.tensorlake.ai/.../exp89 check$ git -C check log --oneline -1bf52db7 initial content ← still the old commit!
The snapshot is private. Nobody else can see it. The branch hasn’t moved. This is what makes the system safe for concurrent agents, because snapshots never interfere with one another or with the public branch.
Before we promote, let’s prove something dramatic: unpublished work survives sandbox death.
I unmounted the filesystem to simulate a crash. In 0.5.89, git mounts require tl git unmount (not tl fs unmount since the CLI enforces strict separation between the two systems):
$ tl git unmount /tmp/mnt-expUnmounted /tmp/mnt-exp. Session kept. `tl git mount exp89 <path> --workspace <session-id>` resumes it.
The sandbox died. The work didn’t. On the server, the workspace persists:
$ tl git workspaces exp89ID Base Head Snapshots WAL60dac7e84b3c bf52db70 aa4f2d05 1 materialized
Base bf52db70 (where we started), Head aa4f2d05 (our snapshot), one snapshot, WAL materialized. Everything is intact. Now remount:
$ tl git mount exp89:main /tmp/mnt-exp$ cat /tmp/mnt-exp/README.md# Experiment 0.5.89## NotesAdded with CLI 0.5.89
Content intact. No re-clone. No re-download. Instant resume.
The CLI even prints the exact command to resume a specific workspace session. This is qualitatively different from the git clone recovery path: there’s no download step, no rebuild, no lost work.
Now that we’ve proven the work survived a crash, let’s publish it:
$ tl git promote /tmp/mnt-exp mainPromoted workspace 60dac7e84b3c → refs/heads/main at b14e9a4 (squashed)
Note: no -m flag in 0.5.89. Promote squashes by default, so your snapshot(s) land as a single clean commit on the branch. Verify:
$ git clone ... check2$ git -C check2 log --onelineb14e9a4 Promote workspace 60dac7e84b3c...bf52db7 initial content
Two clean commits. The full lifecycle:
snapshot(private) →survive crash→promote(public)
The branch history is clean regardless of how messy the agent’s working process was.
The pattern above covers a single agent. But what about distributing content like prompt libraries, tool configs, and model weights to a fleet of agents? Tensorlake offers two approaches.
For versioned distribution with rollback capability:
$ tl git mount exp89:main /tmp/mnt-exp --roMounted exp89:main at /tmp/mnt-exp (read-only, follows the branch)
bash
$ echo "hack" > /tmp/mnt-exp/hack.txtbash: Read-only file system
The mount follows the branch. When someone promotes new content to main, every --ro mount sees the update automatically. No redeployment, no restart, no polling.
Best for: shared prompt libraries, tool configs, reference docs where you need branch-level control, rollback, and audit trail.
For cases where you don’t need branching or version history, Tensorlake’s Cloud Volumes (tl fs) offer a simpler model:
$ tl fs mount cv-final /tmp/mnt-cvMounted filesystem cv-final at /tmp/mnt-cv (saves publish automatically)
Every save auto-publishes. All mounts of the same volume see updates within 5 seconds. No snapshots, no promote step, just a shared directory.
Best for: ephemeral shared data, scratch space, distributing a shared config file to 100 agents where branching would be overkill.
Rule of thumb:need branches, history, or selective promote? Use git --ro. Need simple auto-sync? Use Cloud Volumes.
Tensorlake offers two filesystem products. Here’s when to use each:
The CLI enforces strict separation: tl fs commands won't work on git mounts and vice versa. If you run tl fs unmount on a git mount, you'll get a clear error: "use tl git commands for it." This keeps the mental model clean.
This isn’t a wrapper around git. Tensorlake re-engineered Git’s metadata, ingestion, and storage layers to scale to tens of millions of repos.
Key architectural decisions:
For production teams running fleets of agents, visibility matters. Tensorlake provides two observability tools.
tl git workspaces shows a table of all active workspaces for a repo: workspace ID, base commit, head commit, snapshot count, WAL status, attachment path, and last activity. At a glance, you see which agents are working, how far along they are, and whether their WAL is current.
tl git smartlog shows the branch/workspace/snapshot graph: branch [public], workspace [live], snapshot [active], and active_chain relationships. It's the fleet-wide equivalent of git log, but it shows private workspaces too.
Liveness heartbeats let Tensorlake’s management layer (the service that orchestrates mounts, tracks workspace state, and routes requests) know which mounts are alive. Every action (snapshot, promote, merge) is attributed to a principal with a full audit trail that persists after sandboxes are gone.
The core workflow is simple:
mount(no clone) →autosave WAL(crash-safe) →snapshot(private checkpoint) →promote(publish)
It’s still just Git underneath. You can clone the repo, read the log, and browse commits with any standard git tool. But the operational weight is gone: no downloads, no local .git directories, no merge conflicts to resolve manually.
One repo per user or per project scales to millions. The workspace/branch separation keeps shared history clean while giving each agent its own private working space. And when a sandbox dies (which happens all the time in production) the work survives.
Tensorlake’s Git Repositories feature is available now on cloud.tensorlake.ai. Combined with Tensorlake Sandboxes (MicroVMs with built-in FUSE support), it gives AI agents the same durable, versioned state that developers have taken for granted for years.
The difference is: agents don’t need to learn git. They just write files.
All CLI outputs shown are real, captured from hands-on experiments with Tensorlake SDK/CLI 0.5.89 in July 2026.
Git Without the Clone: Durable, Versioned Workspaces for AI Agents was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.