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 New 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 New 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 the Inbox. Confirm that:

• All requests shows the request under Open;
• For me shows it with Approve and Reject, and the card's top line shows who asked and when it is due.

On the card, optionally select Add a comment, then select Approve. A Response submitted notice should say that the response was recorded. The request moves to Resolved on All requests, where its card shows who answered and the answer.

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

The card is the whole record; there is no separate details view. When an assistant asked from a conversation, the card's footer links to that conversation.

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

A request has no deadline unless its creator sets one. Leave Deadline empty and the request stays open until someone answers or cancels it. Set a deadline when the answer stops being useful after a certain time.

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. Dismissing an open interaction makes it Dismissed (stored as 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.

Select Dismiss on a request's card to withdraw an open request for everyone. The card offers Dismiss to whoever asked and to the people the request waits on; anyone who can act on the request can dismiss it through the API. Mobius asks you to confirm and lets you add a reason; whoever asked is told it was dismissed. 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.create 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.

A wait has its own time limit, separate from the request's deadline. When the wait runs out, the question stays open, and its outcome still arrives in the conversation later.

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.create 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

For me shows pending requests assigned to you and submitted work waiting for your acceptance. A one-question request is answered right on its card, and a request an assistant asked from a conversation links back to it. All requests groups visible requests as Open, In review, Resolved, Expired, or Dismissed.

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

Mobius records response values, comments, actors, timestamps, the rule that resolved the request, and each lifecycle transition. A closed request's card shows each responder's answer and any comment, or the reason it was dismissed. Completed, expired, and dismissed requests stay on All requests.

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.