Workspaces and shared content
Understand where agents compute and how files, wikis, and structured data remain usable by the team.
Log in or sign up to make these docs interactive
Choose your team, project, or agent to turn guidance into links to the exact place in your workspace.
Workspaces are persistent team resources that agent conversations can use for computer-based work. Team content lives in separate shared, governed surfaces. The distinction keeps execution contained while making selected inputs and outputs durable for collaborators.
Compare the team's workspace policy with the selected agent's workspace to see how defaults and agent-specific limits meet.
An agent workspace is its working computer
The workspace gives a run a filesystem and, when enabled, command and browser capabilities. Its runtime is sandboxed from the application and other running environments. A workspace can persist across conversations, and an agent may have more than one when separate environments are justified.
The agent recorded as its creator is provenance, not a private ownership boundary. Authorized agents on the same team can select and reuse a team workspace. Use team permissions, project scope, and separate workspaces when content needs a stronger organizational boundary.
Workspace resources have configured defaults and maximums. Network access can be limited by preset, require approval, or be disabled. Threat filtering and destination controls apply to outbound work. More compute or broader network access should follow the job, not convenience.
Workspace files are not automatically team records. Import the inputs an agent needs and export the outputs people need to keep. This explicit crossing makes the boundary visible.
Attachments and linked files mean different things
An attachment is a copy placed on a card. Use it for the exact snapshot the task should use or for an artifact that belongs to that card's history.
A linked file points to content in the team drive. Use it when collaborators and future work should use the current shared item. Because a link can lead to content that changes, record a version or attach a snapshot when exact reproducibility matters.
Wikis hold maintained project knowledge
Project wikis are for explanations and decisions that people and agents should find in context: operating notes, launch plans, standards, or a decision log. History makes changes visible. A wiki is more suitable than agent memory when the knowledge belongs to the project and should be maintained collaboratively.
Data tools hold structured information
Databases, saved queries, charts, and dashboards support information that is better treated as records than prose. Agents can help prepare and interpret that data within their tool and permission boundaries. Destructive or consequential operations may require additional review.
Use a database for repeatable structure, a query for a reproducible question, a chart for a relationship, and a dashboard for a recurring operational view. Do not turn a static sentence into a database merely because structured tools exist.
Choose the durable home before delegating
Tell the agent where the result belongs. “Create the analysis” is incomplete if teammates do not know whether to expect a card attachment, a shared file, a wiki update, or a dashboard. Naming the destination also clarifies required permissions and the evidence a reviewer should inspect.