State, data, and files
Choose between sessions, agent memory, tables, environments, and artifacts.
Mobius records conversations and agent activity for you. Add another place to store information only when later work needs to find, share, or change it.
| You need to keep... | Use | Why |
|---|---|---|
| Messages from one conversation | Session | A later message in the same session can use what was said earlier. |
| A few facts for one agent to remember between conversations | Agent memory | The facts stay with that agent. |
| Rows that people and agents share and update | Table | Each record has named fields that can be searched and edited. |
| Files and commands needed only while work is happening | Environment | The workspace can be cleaned up after the work ends. |
| A report, export, image, or other file you want to keep | Artifact | The stored file can outlive the workspace that produced it. |
When in doubt, leave the information where Mobius already recorded it. A tool result belongs in its turn. A reply belongs in its session. Move information only when it has become useful outside that conversation.
Sessions
A session remembers messages exchanged with one agent in one conversation, and each turn keeps the tool calls, results, and errors from one request. Reuse the session when a follow-up should depend on what was already said. Start another when the request should have a clean history.
Use a session to diagnose work and compare attempts, not as a list that unrelated work updates over time.
If a fact from a conversation becomes a standing preference, put that one fact in agent memory. If several people or processes need to edit it, use a table.
Agent memory
Agent memory is a small set of facts one agent can reuse in otherwise separate conversations. A person's preferred report format may belong there. A customer list or device inventory does not.
Keep memory selective. Do not save passwords, API keys, guesses, temporary tool output, or instructions copied from an untrusted message. Use a connected integration for provider credentials, or keep a worker's credentials in the secret store on that worker's machine.
Tables
A table is a small spreadsheet with explicit ownership and visibility. Use one for a review list, reference data, or other structured information that the people and routines in its audience need to inspect and change.
Keep data in its original system when it needs large-scale storage, joins, transactions, or that system's own access, backup, or compliance rules. A Mobius table is organization data, not a replacement for every application database.
Each table has named columns and one Identity column. Identity means the stable field Mobius uses to match a saved row, such as a ticket number or device serial. It must be a required text column. Choose it carefully because you cannot change which column has that job after creating the table.
The optional Instructions field is guidance for agents that use the table. It is not a permission rule or validation rule.
Create a table
- Open Build > Tables and click New table.
- Enter a lowercase name and a short description.
- Add instructions only when automated work needs them.
- Under Who is this table for?, keep Only you while the data is personal, or choose Team when the organization should own it. Only an organization administrator can create a team table.
- Add the columns you need.
- Mark one required text column as Identity.
- Click Create.
The empty table opens with its columns ready. Use Insert rows to type data, paste structured rows, or upload a CSV file.
Keep one table focused on one kind of record. If people need to change individual rows in a CSV over time, import them into a table. If they only need to download the CSV as one finished file, keep it as an artifact.
The Only you default creates a person-owned private table. A Team table is owned by the organization and can be found by people with table access. A table can also sit inside an assistant's audience, which narrows who can reach it. The server checks both that resource boundary and the caller's table permissions on every read and write.
Grant table actions only to assistants that need them. An action selection lets an assistant attempt the operation; it does not widen a private table or bypass its owner, visibility, and assistant-audience checks.
A table works well as a routine's source when Mobius should own the rows. For data that already belongs in Google Sheets, a ticket system, or another application, leave it there and grant the routine read access to that exact account. This keeps the source of truth clear.
Software can create, query, search, and update rows through the
Tables API reference. Row updates use a
version to prevent silent overwrites: sending an old version returns 409 Conflict instead of replacing a newer change.
Environments
An environment is a workspace with files and command execution. Use one when an agent must clone a repository, download inputs, run a program, or assemble several files. Work that only reads information, makes a decision, and calls an action usually does not need one.
| Kind | Use it when |
|---|---|
| Managed | You want Mobius to provide the workspace and run the commands. |
| Worker-provided | Commands must run on infrastructure or a network you control. |
A worker-provided environment does not make every result private. Step output, logs, and artifacts you send back are stored by Mobius according to those features. Review that data before treating this choice as a residency or compliance control.
Start fresh when work is independent or handles code and files from outside your organization. Reuse a workspace only when later work genuinely needs its installed tools or existing files. A separate workspace reduces stale-state and cross-task risk, but it does not make untrusted code safe to execute.
Environment provisioning and lifecycle are supporting runtime capabilities in the current release rather than a general public setup flow. When work that uses an environment appears stuck, inspect the owning conversation and its worker activity before changing or repeating the work.
Do not leave the only important copy of a file in an environment. Confirm the file is published as an artifact before the environment is destroyed. Do not put credentials in commands or logs. Use a connected integration for provider credentials, or run the work through a self-hosted worker that reads its own local secret store.
Environment management is not part of the current public API. Use Workers when commands must run on your own machine.
Artifacts
An artifact is a file Mobius keeps, such as a report, CSV export, screenshot, audio file, or PDF. Publishing a file from an environment copies it into artifact storage, so destroying the workspace does not remove that copy.
Each artifact carries the same ownership posture as other Mobius resources: Only you, Shared by you, Shared with group, or Team. A direct upload starts as Only you. Output produced in a person's conversation stays with that person and private. Background agent work follows the agent's human custodian when it has one; otherwise it belongs to the team. The producing agent can further narrow who reaches it.
See Your work and the team's work for the sharing, handover, and administrator privacy rules.
Publish a file
- Grant the agent the Write Artifact action, and Publish Environment Artifact as well if it works in an environment.
- Ask it to save the result as an artifact, giving the name and media type you want.
- Open Work > Library, select the file, and confirm that it previews or downloads.
The file now has an artifact ID and no longer depends on an environment copy.
Write Artifact takes content the agent already has. Publish Environment Artifact takes a path in an environment workspace. Each publish creates a new artifact, even when another artifact has the same name. Use the artifact ID, not the name, when later work needs one exact file.
An agent-produced file records the turn that created it. That history proves which authenticated work published the bytes; it does not prove that the file is correct or safe.
Artifact storage is counted across the organization. Deleting an artifact removes its stored bytes and has no restore action. Mobius keeps enough metadata for audit history, but that metadata is not a backup of the file. Keep another copy when your own recovery or records policy requires one.
Receiving an artifact ID does not grant access to its content. Shared artifacts still require organization read access, and private artifacts still require the owner's identity. Never publish credentials, access tokens, or unnecessary personal data.
Use the Artifacts API reference for uploads, downloads, signed URLs, filters, quotas, and response schemas.
Next
- See how one conversation keeps context in Sessions.
- Decide what one agent should remember in Agent memory.
- Decide what one agent may reach in tools and skills.
- Run commands on your own infrastructure with Workers.