Build

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.

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 or organization secret for credentials.

Tables

A table is a small spreadsheet inside an organization. Use one for a review list, reference data, or other structured information that people and automated work both 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

1. Open Build > Tables and click New table.
2. Enter a lowercase name and a short description.
3. Add instructions only when automated work needs them.
4. Add the columns you need.
5. Mark one required text column as Identity.
6. 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.

Tables use organization access. There is no separate access list for each table. Any agent granted the table actions can read and write every table in the organization, so give those actions only to agents that need them.

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.

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.

Open Runtime > Environments to create or inspect a managed workspace. The detail page shows its provider, lifecycle, retention setting, attached worker, and current use. Provisioning or waking can take time. Before changing a job that appears stuck, check the environment state and whether its worker is online.

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 or organization secret instead.

Use the Environments API reference for provisioning, lifecycle fields, and current public operations. 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

1. Grant the agent the Write Artifact action, and Publish Environment Artifact as well if it works in an environment.
2. Ask it to save the result as an artifact, giving the name and media type you want.
3. Open Runtime > Artifacts, 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.