Interactions

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 assistant asks in a conversation and the outcome comes back to that conversation; or
• subscriber-bound, where your own software receives a signed callback when the request resolves.

An interaction records a decision and gives the assistant that asked its answer. It does not appear automatically before an external action. If a person should review a draft or decision first, put that review step in the assistant's instructions.

Request choices in the app

Open Work > Inbox 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 Work > Inbox 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 assistant's question does not pause the assistant. It asks, carries on or finishes, and the outcome arrives in the same conversation once the request resolves. An open question costs nothing while it waits. The outcome does not arrive merely because 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. Cancelling an open interaction makes it Cancelled. For an assistant's question, either terminal state reaches the conversation the same way an answer does; the assistant's instructions decide whether it stops, explains the outcome, or takes another safe step. 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. In a conversation, select Dismiss on the question card to withdraw the assistant's question; the assistant is told it was dismissed. The assistant can also withdraw its own question with mobius.interaction.cancel. Stopping a turn does not withdraw its questions: they stay open until someone answers or dismisses them, or they expire.

Have an assistant ask for judgment

mobius.interaction.open and mobius.interaction.cancel are built in; you do not grant them as actions. Say in the assistant's instructions when it should ask, who should answer, what evidence the request should show, and whether it must wait for the answer:

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

Asking doesn't stop the assistant. The request appears in Work > Inbox and as a card at the end of the conversation, and the assistant carries on. When the instructions say to wait, it waits on the question with mobius_event_wait and its turn shows waiting. Waiting costs nothing and does not use the turn's active-work limit. A message you send in that conversation still reaches the assistant: it interrupts the wait, and the question stays open.

The outcome arrives as an interaction.resolved event. Its status says how the request ended. For completed, outcome carries the responder's answers, keyed by question id, so an approval reads [{"question_id": "decision", "value": "approved"}] and a rejection carries "rejected". cancelled and expired carry no answers, and the instruction above is what makes the assistant stop. In the conversation, the outcome shows as one line, such as Request answered, that expands to who answered and what they said.

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 ordinary interaction is a gate the assistant chooses to open. Use it for a business decision such as “Is this draft ready?” or “Which option should we take?” The instructions decide what the assistant does with the answer.

Review before an external action

Mobius does not insert an approval before a built-in, MCP, custom HTTP, or worker action. Once the assistant has the action and an eligible connected account, an authorized call can proceed. Mobius still freezes the selected account for the call and rechecks its live grant immediately before dispatch; a denial never falls through to a different account.

Use mobius.interaction.open when your workflow calls for a person's judgment. Show the proposed destination and content in the request, name the eligible responder, and tell the assistant to act only on an approved outcome. This is an instruction-driven business review. It is not a dispatch token, and Mobius does not automatically compare a later action's arguments with the interaction.

A connection grant limits which account the assistant can use and who may receive its results. It does not record consent for one outbound destination. If a recipient or channel needs human review, make that destination explicit in the interaction and verify the later tool call in the transcript.

Channel replies have their own delivery path. For example, the final answer to an inbound agent email is delivered back through that email conversation; it is not a gmail.message.send action. Put any required review before the final answer in the assistant's instructions.

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. Nothing that is waiting on it resumes yet.

An allowed reviewer can:

• Accept work, which completes the interaction and delivers the outcome; or
• Request changes, which reopens the request in a new review round and keeps anything waiting on it 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 conversation that asked in agent sessions.
• Decide who can respond with roles.