Ask an operator and collect the reply

Ask the operator a concrete question and collect the answer from the mailbox. Sending a notification does not itself establish a reply or permission to perform the proposed action. Start with a responding local controller, the CLI on PATH and an agreed agent label.

Send one question

Use a non-secret message that names the decision and avoids collecting an unnecessary process inventory. This example posts a real message; send it only when that question is appropriate:

fleetctl notify --agent docs-example   --message "May I stop the completed documentation preview?" --ask
fleetctl inbox --agent docs-example --unanswered --json

--ask marks a message as needing a reply and raises a notification. --problem is a separate failure marker; plain status notifications do not interrupt. Keep the returned or listed message identity so the answer can be matched to the original request.

Receive the operator's decision

The operator answers the specific message, substituting its actual identity and an explicit response:

fleetctl reply "MESSAGE_ID" "Leave it running until the review is finished."
fleetctl inbox --agent docs-example --json

Read the same message's answer. An unanswered-only query no longer showing a message is not enough by itself to establish what the operator said. A second reply is refused, so do not repeatedly answer a message to try to overwrite the decision.

Check authority before acting

In this example the answer does not permit a stop. Even an affirmative answer must identify the intended service and action; inspect that service's current identity and management class before control. A mailbox reply cannot make a claimed process signallable or replace the controller's identity checks.

If a response is lost, inspect the mailbox before resending the question or reply. Do not turn an uncertain exchange into automatic consent. The CLI message reference defines notify, inbox and reply.