Reference

An interaction is a request for a person or agent to answer a question or make a decision. Mobius stores the request, each response, and the final outcome together.

Use an interaction when the missing input requires judgment or authority. Use a check when Mobius can decide from evidence by itself.

An interaction can be:

• standalone, with no run waiting for it;
• run-bound, where a loop run pauses until the request finishes; or
• agent-bound, where an agent opens a request and waits for the result.

Creating an interaction does not make earlier or later external changes safe by itself. Put the request before the change, show the responder the actual change being proposed, and make rejection or expiry stop that change.

Request choices in the app

Open Runtime > Interactions and select Create request. The app offers:

The API also supports assigned work that can require a separate acceptance review. That workflow is not authored in the standalone app form. See the Interactions API when you need it.

Create and answer a harmless request

You need permission to run work in the project. The responder must appear in the form's Users field. Choose yourself for this test so it does not notify or block anybody else.

1. Open Runtime > Interactions and select Create request.
2. Choose Ask for approval.
3. Under Who should respond?, select your own account in Users.
4. Set Title to Approve interaction walkthrough?.
5. Set Description to This only tests the Mobius interaction inbox..
6. Under Details, set Deadline at least 15 minutes in the future.
7. Select Create interaction.

The app returns to Interactions. Confirm that:

• Project board shows the request as Open;
• My inbox labels it Needs response; and
• Details shows the title, responder, deadline, and Pending status.

Select Respond, optionally add a comment, then select Approve. A Response submitted notice should say that the response was recorded. The request moves to Resolved, and Details shows Completed, the approved outcome, the responder, and a resolved entry in the timeline.

The board uses Resolved as a group label. The stored status is completed. They describe the same successful terminal state.

To remove the test record, open Details, select Delete interaction, and confirm Delete. Open requests cannot be deleted; cancel them first.

Who can respond

Targets are specific project principals selected when the request is created. A person who is not in that target set cannot answer it. Each target can submit one response in the current review round. If two people respond at nearly the same time, Mobius records them in transaction order and applies the resolution rule once.

With more than one target, the app shows How is this resolved?:

A quorum is a participation threshold, not a majority vote. Two responses can finish a quorum of two even if their answers disagree. If the final decision needs agreement, model that decision explicitly instead of treating response count as approval.

Once a rule finishes the request, later responses are rejected. Use first response only when any one target truly has authority to settle the request.

Deadlines and waiting work

Standalone requests created in the app default to seven days when you leave Deadline empty. Set an explicit deadline when a shorter response window matters.

A run-bound or agent-bound request suspends only its waiting work. Mobius does not run a model or action while it waits, but the run remains open and its wall-clock limit continues to count. A response may also wait briefly for the runtime to resume the run; it does not resume merely because any one person answered when an Everyone or Quorum rule is still incomplete.

If the deadline passes first, the interaction becomes Expired and rejects late responses. A run-bound interaction also fails its waiting step. Cancelling an open interaction makes it Cancelled and stops the waiting continuation. Neither path rolls back work that happened before the request opened.

The creator can cancel an open request from Details > Cancel interaction. Add a reason so the record explains why it stopped.

Put an interaction in a loop

The current loop editor does not add Interaction steps. Author a run-bound Interaction step through the API or CLI, then inspect and run the saved loop in the app. The step specifies:

• the request protocol;
• exact target principal IDs;
• the prompt and response controls;
• the response-count rule; and
• a timeout.

While that step waits, the run is Suspended and the request appears in Runtime > Interactions with a link back to the run. An approval response of approved lets the next step start. Rejection, cancellation, or timeout fails closed before later steps run. Information requests resume with the collected value.

Use the run's Timeline to verify three separate facts: the interaction was requested, the expected person responded, and the downstream step completed. An approval record alone does not prove that a later message or update succeeded.

Acceptance review for assigned work

The API can add an acceptance review to assigned work. Reaching the response threshold then moves the interaction to In review instead of completing it. The waiting consumer remains suspended.

An allowed reviewer can:

• Accept work, which completes the interaction and resumes the consumer; or
• Request changes, which reopens the request in a new review round and keeps the consumer waiting.

Earlier submissions remain in the timeline but do not count in the new round. The original deadline keeps running. A submitter cannot accept their own work, so name a reviewer who is not an assignee; otherwise the request can have no eligible reviewer.

This acceptance gate is separate from a Request a review interaction. The first is a second person accepting submitted work. The second asks a responder to choose a review outcome.

Inbox, email, and the project record

My inbox shows pending requests assigned to you and submitted work waiting for your acceptance. Project board groups visible requests as Open, In review, Resolved, Expired, or Cancelled.

The app inbox is always the response system of record. Optional email delivery sends a notification to the addresses entered in Details; it does not turn an arbitrary email recipient into an eligible responder. Verify the request in the app even when email delivery is enabled.

Details records response values, comments, actors, timestamps, the rule that resolved the request, and each lifecycle transition. Completed, expired, and cancelled requests remain visible until somebody with permission deletes them.

Start follow-up work from the result

Every terminal interaction emits interaction.resolved, including completed, cancelled, and expired requests. A standalone request has consumer_kind: none; run, agent-tool, and HTTP-callback requests use their corresponding consumer kind.

To start follow-up work only for standalone requests, create an Event trigger for interaction.resolved and add both conditions:

event.consumer_kind == "none"
event.status == "completed"

The status condition prevents cancellation or expiry from starting the normal success path. In addition to status and consumer_kind, the event payload includes interaction_id, kind, and completed_at, plus outcome and responder when present. Make the follow-up idempotent in case its own action must be retried.

Next

• Create, respond, review, and cancel through the Interactions API.
• Use interaction commands from the CLI command reference.
• Inspect waiting work in runs.
• Decide project permissions with roles.