Reference

An action is a named operation with defined inputs and outputs. It might read a calendar, post a message, update a ticket, call your HTTPS endpoint, or run code on one of your workers.

The definition makes calls consistent and inspectable. It does not guarantee the same result every time: credentials, external state, rate limits, network failures, and the supplied inputs can all change the outcome.

Open Library > Actions to see the current project's catalog. Ready means Mobius has the configuration needed to attempt the action. It does not prove that an external account, endpoint, or worker will succeed on the next call. Needs setup explains the missing connection or worker.

Where actions come from

Connecting a provider makes its catalog entries available, but each entry may need particular credentials, scopes, or provider setup. Read its Needs setup message instead of assuming that one connection enables every action.

Run a harmless action from a loop

This walkthrough uses the read-only platform action Runtime Context. It has no external account and does not change outside data.

1. Open Build > Loops and select New loop.
2. Name the loop Action walkthrough.
3. Remove the Agent step that appears in the new loop.
4. Select Add step > Run action.
5. In the action picker, choose Runtime Context. It has no parameters.
6. Select Create, then select Run on the loop page.

Open the new run and confirm:

• its status is Completed;
• Timeline shows the action step completed; and
• the step result contains run_id, step_name, path_id, org_id, and project_id.

The result's run_id should match the run page. This proves that the catalog entry was ready, the loop invoked it, and the result was recorded. It does not test an integration or custom endpoint.

When you are finished, return to the loop, open Loop actions, select Delete loop, and confirm. The completed test run remains available for inspection.

Use an action as a step or an agent tool

The same catalog action can be used in two different places:

Prefer an explicit step for messages, writes, charges, deletions, or other external effects. The separate checkpoint makes the intended change, input, attempts, and result easier to review and recover.

Agent tools are not invisible: their calls and results remain inside the agent step or transcript. They are less prominent than a top-level step, and the model decides whether and when to call them. Give an agent only the actions it needs, with the narrowest provider permissions and input schema you can use. An action's Read-only, Idempotent, and Destructive annotations describe expected behavior; they do not turn a mutating endpoint into a safe one.

Pass inputs and use results

In the loop editor, a Run action step shows fields from the action's input schema. Enter a fixed value or a template that refers to the run event, config, or an earlier step result. The editor validates the declared shape, while the receiving system remains responsible for its own business rules.

The successful response becomes that step's result for later steps. Inspect the actual result before writing a template against it. A provider may return an empty value, a partial result, or a structured error, and an HTTP 202 response may mean only that another system accepted work rather than finished it.

Use steps for reference syntax, conditions, retries, and checks.

Create a project action

Create a custom action when Mobius needs to call an operation that is not in the catalog.

1. Open Library > Actions and select New action.
2. Enter an immutable Name using the dotted action-name format, such as tickets.search.
3. Add a clear Title and Description. Agents use these to decide whether the action fits their task.
4. Choose HTTP endpoint or Worker-backed.
5. Define the input and output with JSON Schema.
6. Set the behavior annotations accurately, then select Create action.

For an HTTP action, enter a public HTTPS Endpoint URL. Signed context is the default request-body format and includes authenticated project, action, actor, and invocation details. Use Legacy only for a receiver that already implements the older body contract.

Mobius generates an HMAC signing secret when the action is created and shows it once. Store it in the receiving service's secret manager before leaving the page. The receiver must verify the signature over the exact request body and reject invalid signatures and replayed deliveries. The Actions API defines the body, signature headers, limits, and response behavior.

There is no dry-run button that makes an arbitrary endpoint harmless. Test a new receiver with a disposable, read-only operation and non-sensitive input. Verify both sides:

• the run's action step or agent tool call completed with the expected result; and
• Library > Actions > Recent invocations shows the action name, status, source, retry count, parameters, and output summary.

Only then add credentials or state-changing behavior.

A Worker-backed action has no endpoint URL or signing secret. A connected worker must advertise the exact action name and meet the loop's location and capability requirements. If no eligible worker is active, the action cannot run.

Share an organization action

Organization Owners and Admins can create any number of shared HTTP action definitions under Organization > Actions. Each definition has its own endpoint and signing-key versions and is available in current and future projects.

A loop can select an organization action directly as a step. A toolkit is needed only when an agent should receive it as a tool. Each invocation still runs, audits, and bills in the calling project.

A project action with the same name takes precedence inside that project. This is useful for a client-specific endpoint, but it can also redirect existing name-based references. Review loops and toolkits before creating a collision.

The signing secret lets the receiving service verify requests sent by Mobius; Mobius is not accepting inbound calls with that key. On creation, install the one-time key in the receiver. For rotation:

1. Open the action's Manage signing keys panel and select Rotate key.
2. Store the revealed pending key in the receiver without removing the active key.
3. Select Activate for the pending version.
4. Use the secret reference and version headers to choose the verification key in the receiver.
5. Keep the previous key available there for the 24-hour overlap so delayed or retried requests signed before activation can still be verified, then revoke or remove it according to your key policy.

New deliveries use the newly active key. Revoking the only active key requires disabling the action first; activate a replacement before enabling it again.

Retries and irreversible effects

An action attempt can fail after the external system already performed the change, for example when the response is lost after a successful update. Treat a timeout or connection loss as an unknown outcome until you check the remote system.

For a change that supports idempotency:

• derive one stable key for the logical change;
• reuse that key for every retry of the same change;
• use a different key for different work; and
• confirm the provider's retention window and duplicate behavior.

Mobius retries cannot unsend a message or generally reverse a remote change. When a provider has no idempotency support, reconcile the remote state before retrying. Put an interaction before a high-risk change when a person must authorize it, but remember that approval does not make the provider call idempotent and does not undo an earlier effect.

Return application context to an agent

A signed custom HTTP action used as an agent tool can return named application context alongside its normal result. Mobius adds that context to the active agent turn so the model can see the updated application state on its next move.

This mechanism does not make a mutating tool safer. Prefer a loop action step for externally visible changes, then pass its result to a later agent step. Loop action steps ignore the application-context channel because no agent turn is active. The Actions API defines the response media type, size limits, and SDK helpers.

Next

• Connect provider accounts with integrations.
• Give selected actions to an agent with toolkits and skills.
• Implement and verify custom receivers with the Actions API.
• Run action commands from the CLI command reference.