Build

Mobius records conversations and loop 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 step result belongs in its run. A reply belongs in its session. Move information only when it has become useful outside that run or conversation.

Sessions and runs

A session remembers messages exchanged with one agent in one conversation. Reuse the session when a follow-up should depend on what was already said. Start another when the request should have a clean history.

A run records one time a loop started. It keeps the input, step results, errors, and final status. Use runs to diagnose work and compare attempts, not as a list that unrelated runs update 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 project secret for credentials.

Tables

A table is a small spreadsheet inside a project. 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 project 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 and loops 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 project access. There is no separate access list for each table. Row changes can start a loop, so filter the trigger to the table and change you actually intend to process.

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 project 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 has one access space:

Worker output is always Shared because Mobius ties it to the worker's active job. A direct upload outside a run is Personal and has no run or step history. Write Artifact defaults to Shared, so change the selection when only the owner should read the file.

Publish a file

1. In the loop editor, click Add step > Run action.
2. Choose Write Artifact for text or base64 content already available to the step. Choose Publish Environment Artifact for a file in the loop's environment workspace.
3. Enter the artifact name and media type, then provide the content or workspace path requested by the action.
4. Save and run the loop.
5. 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.

Use Write Artifact when a step already has the file content. Use Publish Environment Artifact when the file exists 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.

Run-produced files show which run and step created them. 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 and run 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 project read access, and Personal 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.
• Inspect output beside the work that produced it in Runs.
• Run commands on your own infrastructure with Workers.