> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensorlake.ai/llms.txt > Use this file to discover all available pages before exploring further. # Store Agent-Generated Code > Store code, docs, and assets produced by coding agents in versioned repositories. Use Tensorlake repositories when your product creates or updates many user projects with coding agents. A coding agent platform may create thousands of repositories each day and keep updating existing applications as users ask for changes. Tensorlake gives every generated project a durable Git source of truth, private autosave WAL for active agents, snapshots for deliberate commits, and activity history for visibility. ## Pattern 1. Create one repository per generated app, site, package, or user project. 2. Mount the repository when an agent needs to change it. 3. Let autosave protect work during the run; snapshot deliberate milestones as Git commits. 4. Promote accepted changes back to the project branch. 5. Use repository activity to see what agents created, updated, merged, or published. ## Create Repositories at Product Scale Create repositories from your control plane when users start new projects: ```bash theme={null} export TENSORLAKE_API_KEY=tlk_... ``` ```python theme={null} from tensorlake import RepositoryClient with RepositoryClient.from_env() as repos: repo = repos.create("app-7f3c2a1b", default_branch="main") print(repo.url) ``` ```bash theme={null} export TENSORLAKE_API_KEY=tlk_... ``` ```typescript theme={null} import { RepositoryClient } from "tensorlake"; const repos = await RepositoryClient.fromEnv(); const repo = await repos.create("app-7f3c2a1b", { defaultBranch: "main", }); console.log(repo.url); ``` Use stable repository names, such as an internal app id. Human-facing app names can change without changing the storage identity. ## Why This Scales A repository is the durable unit for a user project. A mount is the ephemeral file-system path for one sandbox. A workspace is the isolated snapshot history for one agent run. That separation keeps high-volume platforms simple: your control plane can create, list, fork, archive, and update repositories through the SDKs, while agents work through writable mounts. Mounting does not copy the whole repository into the sandbox. File content is fetched as processes read it, autosave persists changed content into private workspace WAL, and snapshots materialize deliberate Git commits without forcing every run to become one large final commit. Use branches for product states such as `main`, `preview`, or `release`. Use workspaces for in-progress agent attempts. ## Store Generated Files When a backend process already has a generated worktree, push it directly: ```python theme={null} report = repos.push_worktree( "app-7f3c2a1b", root="./generated-app", branch="main", message="create initial app", ) print(report.commit) ``` ```typescript theme={null} const report = await repos.pushWorktree("app-7f3c2a1b", { path: "./generated-app", branch: "main", message: "create initial app", }); console.log(report.commit); ``` `push_worktree` and `pushWorktree` create one commit from a local directory. They skip `.git`, honor `.gitignore`, preserve symlinks, and preserve executable bits on regular files. Use this for generated code, app assets, docs, migrations, configuration, and deployment metadata: ```text theme={null} generated-app/ src/ public/ docs/ migrations/ package.json ``` ## Let Agents Work in a Mounted Workspace When an agent is editing an existing project, mount the repository into the sandbox: ```bash theme={null} $ tl git mount app-7f3c2a1b /work Mounted writable app-7f3c2a1b at /work (workspace activates on the first WAL checkpoint) ``` The agent edits `/work` like a normal directory. Autosave protects the changing state in private workspace WAL. Create snapshots when the run reaches meaningful Git history boundaries: ```bash theme={null} $ tl git snapshot /work -m "scaffold billing page" Snapshot 8b21f6a9c3d5e7f1a2b4c6d8e0f3a5b7c9d1e3f5 (28 file(s), 28 of 28 chunks uploaded) $ tl git snapshot /work -m "wire billing API" Snapshot 4d9a2f7e5b3d8c6a4f2e0d9b7c5a3f1e8d6b4c2a (12 file(s), 12 of 12 chunks uploaded) ``` Autosave makes long-running agent work durable without producing a stream of commits. If a sandbox stops, the workspace can be reattached through its latest server WAL checkpoint. Snapshots provide deliberate points you can inspect, rebase, and promote. When the user accepts the result, publish it. Promotion first seals and materializes any dirty WAL, so the latest edits are included even if the agent did not run one final snapshot command: ```bash theme={null} $ tl git promote /work main Promoted workspace 3f9a2b7e1c4d -> main at 1c4d9a2f7e5b3d8c6a4f2e0d9b7c5a3f1e8d6b4c (squashed) ``` After promotion, future agents that mount `app-7f3c2a1b`, build systems that clone it, and developers who fetch it get the published version. ## Update Existing Repositories Safely Generated applications keep changing after the first version. Users ask agents to add pages, fix bugs, change copy, update dependencies, or regenerate docs. For backend pushes, pass `expect_oid` in Python or `expectOid` in TypeScript when the update should fail if the branch moved: ```python theme={null} info = repos.info("app-7f3c2a1b") current = next(b.oid for b in info.branches if b.name == "main") report = repos.push_worktree( "app-7f3c2a1b", root="./generated-app", branch="main", message="update homepage", expect_oid=current, ) ``` ```typescript theme={null} const info = await repos.info("app-7f3c2a1b"); const current = info.branches.find((branch) => branch.name === "main")?.oid; const report = await repos.pushWorktree("app-7f3c2a1b", { path: "./generated-app", branch: "main", message: "update homepage", expectOid: current, }); ``` Use server-side merge APIs when two agents or a user and an agent changed the same project branch. Preflight first when you want to know whether a merge is clean before publishing. ## Visibility for Agent Fleets Every repository and workspace has activity you can inspect through the API and dashboard: * Which repositories exist for user projects. * Which branches changed. * Which workspaces are live, detached, or resumable. * Which durable WAL checkpoints and snapshots each agent created. * Which paths changed in a snapshot. * Which principal pushed, promoted, merged, or reconciled changes. This gives the product control plane enough state to answer operational questions: which users have active generations, which runs published to production branches, and where a failed run can resume. Fine-grained edits remain local until autosave; the control plane observes durable checkpoints rather than every keystroke. ## Scale Model | Need | Use | | ------------------------------------- | -------------------------------------------------------------------- | | New user app or project | Create a repository | | Agent edits an existing app | Mount `main` (writable by default) | | Long-running generation | Rely on autosave for recovery; snapshot meaningful commit boundaries | | User accepts a result | Promote the workspace to the project branch | | Backend writes generated code or docs | Repository SDK `push_worktree` | | Prevent overwriting newer work | `expect_oid` / `expectOid` | | Inspect what agents did | Workspace status, snapshots, operations, and branch activity | | Build or deploy generated code | Ordinary `git clone`, `git fetch`, or a read-only mount | ## Next Steps Create repositories, push worktrees, merge branches, and inspect refs from application code. Mount, snapshot, and promote code generated by agents. Handle branches that moved while an agent was working. Understand snapshots, lazy content delivery, merge behavior, and observability.