Run
Interactions
An interaction is a structured request for a person to provide information, approve a decision, review a subject, or perform assigned work. A loop can wait for that answer before continuing, and a person can create a standalone request from the app.
Use an interaction when the response should be visible, attributable, and bounded by a deadline. Do not hide an important decision inside an informal chat message.
Choose the request
| Request | Use when |
|---|---|
| Information | The work needs a value, choice, or written answer. |
| Approval | The work needs permission to continue. |
| Review | The work needs judgment on a plan, artifact, diff, or recommendation. |
| Task | Someone has to go do the work and return the result. |
Keep the request honest. A yes-or-no gate is an approval. A verdict with notes is a review. A field value or choice is information. Work someone performs and reports back on is a task.
Create a standalone interaction
- Open Runtime > Interactions.
- Click Create request.
- Choose what you are asking for.
- Select who should respond.
- Choose whether the first answer, every answer, or a quorum resolves it.
- Write the prompt and choose the response controls.
- Add optional email delivery or expiry.
- Create the interaction.
The new request appears on the project board and in each eligible responder's inbox.
Add an interaction to a loop
In the loop editor, add an Interaction step where the run should pause. Set the request, responders, response controls, and timeout. Later steps can use the resolved answer as step output.
While the request is open, the run is suspended, not stuck. It consumes no
active worker slot and resumes when the resolution rule is satisfied.
Give every waiting interaction a deadline. Decide whether expiry should fail the run or follow another authored path so unattended work cannot wait forever.
Decide how many responses are enough
| Policy | Resolves when | Use when |
|---|---|---|
| First response | Any eligible responder answers. | One answer or approval is enough. |
| Everyone | Every assigned responder answers. | Each person owns part of the decision. |
| Quorum | A chosen number of distinct responders answer. | A group can decide without waiting for every member. |
Start with the first acceptable response unless the decision truly requires several people.
Require acceptance before work counts
A task is often not done when the assignee says so. Turn on Require acceptance to add a review gate: the submitted result moves the request to In review instead of resolving it, and anything waiting on the request keeps waiting.
A reviewer then chooses:
| Decision | What happens |
|---|---|
| Accept | The submitted result becomes the outcome, the request resolves, and any waiting run resumes. |
| Request changes | The request reopens for the assignee with your feedback attached. Whatever is waiting stays waiting. |
Name reviewers explicitly, or leave the list empty so whoever created the request reviews it. An assignee can never accept their own work.
Requesting changes starts a new round. The assignee answers again, and the earlier submission stays in the history with the round it belonged to. The deadline still applies while a request sits in review, so a stalled acceptance expires like any other unanswered request.
Leave acceptance off for ordinary approvals, choices, and information requests. A single answer already settles those, and a review gate would only add a step.
Respond in the app
Open Runtime > Interactions. My inbox contains open requests assigned to you, plus any submitted work waiting on your acceptance. Project board groups every request by state: Open, In review, Resolved, Expired, and Cancelled. Empty states stay hidden.
Open a request, review its subject and context, then submit the answer. Once the resolution policy is satisfied, Mobius freezes the outcome and resumes the waiting run or agent tool — or, when acceptance is required, holds the result in review until a reviewer accepts it.
Delivery and audit history
The app inbox is the default. Optional email delivery can notify someone who does not keep Mobius open, while the response still returns to the project record.
Mobius records who answered, when they answered, who accepted the result, and which outcome resolved the request. The detail view's timeline shows every transition in order, including each send-back and its feedback. Completed, expired, and cancelled interactions remain visible for later diagnosis.
Every terminal interaction also emits interaction.resolved. A loop can use
that event as a trigger for channel-independent follow-up work, including for
standalone requests that have no waiting run or agent tool. The event also fires
for run-bound, agent-tool, and HTTP-subscriber interactions, so filter
event.consumer_kind == "none" when the trigger should start only for
standalone work. Other values are run, agent_tool, http_subscriber, and
unknown for malformed legacy consumer data.
Terminal payloads share interaction_id, kind, status, consumer_kind,
and completed_at. Completed events can include response, comment,
outcome, and responder fields. Cancelled events include cancelled_by,
reason, and cancelled_at. Expired events have status: expired and a
response with timed_out: true and expired: true.
Next
- Define request shapes through the Interactions API.
- Inspect and respond from the CLI command reference.
- Add interaction steps with steps.
- Inspect waiting work with runs.
- Give responders access with roles.