Overview
Each deployment has its own filesystem rooted at/workspace inside the agent’s container. It’s a real filesystem: the agent reads, writes, and organizes it with the standard file tools, everything persists across sessions, and your product gets direct access through the Files API.
What lives in the workspace:
| Content | Description |
|---|---|
| Outputs | Storyboards, scripts, drafts, rendered assets — what the agent produces |
| Working state | Notes, intermediate results, and to-dos the agent keeps across runs |
| Skills | Skill files loaded with source: "file" |
| Memory files | The durable context behind Memory |
How the agent uses the workspace
The agent treats/workspace the way an employee treats their desk: it saves outputs there, keeps notes for itself, and picks up where it left off. A run can end with “saved to storyboard.md” and next week’s run starts by reading it. The agent’s file activity appears on the SSE stream as ordinary tool_call / tool_result events.
Debugging often starts here too — reading the agent’s workspace is the fastest way to see what it was thinking.
Access files from your product
Read and write the workspace directly with the Files API:Watching for changes
Rather than polling, enablefilesystem_webhooks in the deployment’s features to receive filesystem events on the SSE stream the moment the agent writes:
Lifecycle
| Event | Effect on the workspace |
|---|---|
| Run ends | Nothing — files persist |
| Restart or deploy | Nothing — files persist |
| New thread | Nothing — threads share the deployment’s workspace |
| Deployment deleted | Destroyed, unless retain_filesystem: true keeps a snapshot for 30 days |

