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. When Mobius can decide from evidence by itself, let the agent check the evidence instead of asking a person.

An interaction can be:

• standalone, with nothing waiting for it, when you want the answer on the record;
• agent-bound, where an agent opens the request mid-turn and waits for the result; or
• subscriber-bound, where your own software receives a signed callback when the request resolves.

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 organization. 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:

• Team 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 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.

An agent-bound request suspends only its waiting turn. Mobius does not run a model or action while it waits, but the turn remains open and its wall-clock limit continues to count. A response may also wait briefly for the runtime to resume the turn; 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. The waiting turn then fails. 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.

Have an agent ask before it acts

Grant the agent the interaction actions, then say in its instructions when it must ask. Be specific about which operations require approval, who to ask, and what to show them:

Before you send anything to a client, open an approval interaction targeting
the service desk lead, with the exact text you intend to send. Send it only
after the request is approved. If it is rejected or expires, stop and say so.

While the agent waits, its turn is waiting and the request appears in Runtime > Interactions. An approval response of approved returns to the agent as the tool result and it continues. Rejection, cancellation, or timeout returns the same way, and the instruction above is what makes the agent stop.

Read the transcript to verify three separate facts: the interaction was requested, the expected person responded, and the following tool call did or did not happen. An approval record alone does not prove that a later message or update succeeded.

An interaction is a gate the agent chooses to open. When a wrong call would be expensive, withholding the action is the stronger control.

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 record

My inbox shows pending requests assigned to you and submitted work waiting for your acceptance. Team 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.

Tell your software the result

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

The event payload carries status, consumer_kind, interaction_id, kind, and completed_at, plus outcome and responder when present. Check status before acting: cancellation and expiry resolve the interaction too, and they are not approval.

An HTTP-subscriber interaction is the direct route. Give it a callback URL and a signing secret when you create it, and Mobius POSTs the resolution to your endpoint, retrying failed attempts. Make your handler idempotent: a retry can deliver the same resolution twice.

Next

• Create, respond, review, and cancel through the Interactions API.
• Use interaction commands from the CLI command reference.
• Inspect the waiting turn in agent sessions.
• Decide who can respond with roles.