The agent inbox is the per-agent queue where requests wait when the machine is asleep, the daemon is offline or the agent is already busy. Each request sits there with its id, its requester and its approval state, and the daemon works through the inbox in order when it returns. A request is never lost because the laptop lid was closed, and never runs twice because the daemon restarted.
Local-first agents pay for their advantages with availability. The inbox is how that cost is kept small.
What goes into the inbox
Every request, always. Even when the machine is online, a request passes through the inbox on its way to the runtime; the queue just happens to be empty. The inbox is per agent: two agents on one machine have two inboxes and run in parallel; one agent runs its inbox serially, one request at a time, so a working directory is never edited by two runs at once.
An inbox overnight: three approved requests wait in order; one still needs the owner; the machine wakes and works through them.
Order and state
Requests run in the order they were approved, not the order they were sent. A request from someone with a standing grant is approved on arrival and takes its place; a request waiting for the owner’s approval holds its position but is skipped until approved. The owner can remove or reorder items in the inbox before they run.
Each item carries its state through the wait: pending (needs approval), approved (waiting for the machine), or running (was mid-run when the machine slept). See request ids and resumable runs.
Waking up
When the daemon returns it polls for work, receives the inbox in order, and:
- Resumes any request that was running when the machine slept, using the stored runtime session reference. Same id, same session, a gap in the timeline rather than a duplicate run.
- Runs approved requests one at a time.
- Leaves pending requests in place until the owner answers.
Approvals that went unanswered for longer than the TTL (24 hours by default) have expired by then and the requests are marked expired rather than run stale.
Keeping the machine reachable
The inbox makes offline periods safe; it does not make them fast. Three habits shorten them.
- Install the daemon as a service with
muti service install. It starts at login and restarts after a crash, so “the daemon isn’t running” stops being a reason for a wait. - Disable sleep during working hours on a desktop, or plug in a laptop and set it not to sleep on power. A closed lid is an offline agent.
- Check
muti statuswhen in doubt. It shows whether the daemon is connected and the last time it polled.
What the requester sees
Their request in the room with its id and a state: “queued, machine offline since 22:00” or “waiting for Noah’s approval”. They can cancel it or add a message to it. When it runs, the timeline streams as usual. Nobody needs to resend.
Frequently asked questions
Does the inbox live on my machine or in the room? In the room service. That is what lets it accept requests while the machine is off, and what lets the owner reorder it from a phone.
Can I clear the inbox? Yes. Removing items cancels those requests; the requesters see cancelled.
What if the machine is off for days? Requests wait. Approvals expire on their own TTL; approved requests do not expire, though the owner may want to prune them before a long absence.
Does the same apply to chat-platform requests? Yes. A Feishu or Slack mention becomes a request like any other and waits in the same inbox. See the Feishu design.
Close the lid. The requests will be there in the morning. Give your agent a room.
Published