Build
Actions
An action is a named capability that performs deterministic work. A loop can call an action as a step, and an agent can call an allowed action as a tool.
Use an action when the work has a clear input and result: post a Slack message, add a GitHub label, send an email, fetch provider data, or run your own code.
Actions and agents
Actions are exact; agents decide. A useful pattern is to let the agent produce or choose something, then give it one narrow action that makes the result real.
| Need | Choose |
|---|---|
| A known provider or code operation | Action |
| Judgment, interpretation, or open-ended generation | Agent |
| A fixed operation at a known point in a process | action step |
| An operation the model should choose when needed | Agent tool |
Where actions run
| Kind | Where it runs | Use when |
|---|---|---|
| Server | Inside Mobius with a connected provider. | Mobius already supports the provider. |
| Worker | In your worker process. | The action needs your network, secret, code, or model stack. |
| Control | Inside the Mobius runtime. | The operation changes runtime behavior. |
Do not run a worker just to call a supported provider. Connect the integration and use its server action. Keep worker actions for behavior that genuinely belongs in your environment.
Browse actions in the app
Open Library > Actions to see what the current project can call. The catalog groups actions by provider and shows whether each one is ready, which inputs it accepts, and which connection or worker it needs.
Open an action to inspect its schema and recent invocation history. This is the best place to diagnose a provider action before putting it in a loop.
Click New action when you need a project-owned HTTP or worker action. Give
it a stable name that describes the capability, not the current caller. A name
such as tickets.search remains useful across several agents and loops.
Organization Owners and Admins can open Organization > Actions to register one signed HTTP action for all projects. It remains a shared definition, not a global execution scope. A toolkit must select it, and every call still executes, audits, and bills in the consuming project. A project action with the same name wins, which supports deliberate project-specific overrides.
The project catalog labels these definitions Organization. You can inspect their schemas and project invocation history there, but edit, signing-key, and delete controls are intentionally unavailable because those operations belong under Organization > Actions. Project-owned actions keep the normal management controls.
Creating an organization action reveals its signing key once. Copy the key into the receiving service before leaving the page. For later rotation, create a pending key under Manage signing keys, install it in the receiver, and only then activate it. Mobius accepts the previous key for up to 24 hours after activation so deployments can overlap safely. The Actions API documents the receiver headers and lifecycle details.
Put an action in a loop
In the loop editor, add an Action step and choose the action from the catalog. The editor shows the action's inputs so you can enter fixed values or map output from earlier steps.
The result becomes that step's output. Later steps can use it without knowing whether the action ran inside Mobius or on your worker.
Give actions to an agent
Add actions to a toolkit, then assign the toolkit to the agent. A small toolkit helps the model choose correctly and limits the side effects available during a turn.
Do not give every action to every agent. Start with the smallest useful set and add another capability only when a real task requires it.
Side effects and retries
Mobius can retry action steps, but it cannot undo an external side effect that already succeeded. Actions that charge, send, publish, or mutate another system should accept a stable idempotency key when the provider supports one.
Place an interaction before a destructive action when a person should approve the exact change.
Custom action context
A custom HTTP action used as an agent tool can return fresh application state alongside its ordinary result. This is useful when the action mutates a board, document, or account record that the next model iteration should see.
The media type, response envelope, limits, and SDK helpers belong to the Actions API. Loop action steps use only the ordinary result because they do not have an active agent turn.
Next
- Connect provider credentials with integrations.
- Group agent tools with toolkits and skills.
- Implement HTTP action responses with the Actions API.
- Test and operate actions with the CLI command reference.