Inbox agents

What it is

An inbox agent is one session whose job is your Needs-You list. Instead of you opening the inbox and deciding what each waiting item needs, the agent does that: it reads everything waiting, decides what each item is, does what it can itself, and brings you only the things that genuinely need a person.

Two clocks keep it useful. It runs a fast pass every five minutes, and its job there is to answer the agents that are blocked waiting on a reply — a session sitting on a question is a session not working, and on a cloud machine it is money going out. Then it reports back to you in a short digest on a cadence you choose, 30 or 60 minutes. The fast passes are silent; only the digest reaches you.

It also learns. The first time it runs it works through your real inbox with you one item at a time, asks what you would do, and records the rules it deduces. Those rules are yours, they are stored in the app, and they outrank the agent's own defaults.

Why it exists

An inbox fills with finished agents, waiting questions, alerts and decisions, and deciding what each one needs is real work that repeats every few minutes. Most of it is not a decision only you can make — it is routing something to its owner, archiving something that is done, or answering an agent that is blocked. An inbox agent does that part, so what is left in your inbox is what actually needs you.

Where to find it

• Settings → Inbox agents. The panel holds one control — Start an inbox agent — and the list of rules your agent follows, which you can read, add to, and remove.
• Default: off. The feature is in development, so it is revealed from Settings → Lab (Inbox agents). Until it is on, the panel renders nothing and no agent can be started.
• Nothing runs by itself. Starting an agent is a deliberate click; there is no default that creates one.

How it behaves

• Starting is one action. Pressing Start an inbox agent begins a session that sets up its own crew, arms its five-minute pass and its digest, and then runs the interview that learns your rules. You do not configure any of that by hand.
• Starting twice is still one agent. If an agent is already running, Start hands you the one you have instead of making a second — two agents on one inbox would double every decision.
• A started agent that has not checked in yet says so. The session registers itself, which happens a moment after it starts. Until it does, the panel says it has started but not checked in. If that message stays, the agent did not finish setting itself up, and that is worth knowing rather than having it look installed and do nothing.
• Your rules are the user's own document. The panel is the place to add one in your own words. The interview adds the ones it learns; every rule records whether it came from you or from the agent.
• Only real questions reach you. A pass the agent ran on its own never becomes a notification. You hear from it through the digest, through a card when it has something to ask, and when it answers a message you sent it.
• Its questions arrive written out, never as a pointer. When it needs an answer it puts the question in the message you are reading — numbered, with lettered options — rather than telling you to go and answer something somewhere else. Anything it wrote above its final message, or on another card, is not something you can see, so it never sends you to look there.
• Other people's cards are left to you. A plan, contract or decision card raised by another overseer belongs to you and that overseer. The agent does not re-ask it, does not copy its question into your digest, and does not answer it for you. If one has sat unanswered for a long time — about four hours of your day by default — it sends one short reminder naming the card. That threshold is a rule in the panel; change the number or delete the rule to stop the reminder.
• What it will not do on its own. It never archives a crew member, never archives a finished audit, and never stops a session, pushes, deploys or changes your settings without your explicit yes for that action. It asks before opening up your paused sessions.
• Stopping it is archiving the session. There is no separate stop switch to learn; the agent is a session, and archiving it is how every other session is stopped. Your rules stay where they are, so the next agent starts already knowing them.

What reaches you, and what does not

The dispatch rules an inbox agent's digest follows, stated by the owner on 2026-10-03 and carried verbatim into the shipped playbook:

• Only what it cleared. "I don't need any info on the digest of things that are still in my inbox. I will obviously get to those independently. Just give me the digest of the things you took care or archived for me." The digest is a record of work done, not a status board.
• No waiting-on-you lines. "I don't need any waiting on you alerts in this report."
• One sentence per bullet, detail nested underneath. "one fucking sentence per bullet point and use nested bps. This is the hard standard for all inbox overseers."
• A session that cleared itself out of the list still owes you its outcome. "I still want the fucking info but in the fucking digest unless there are likely next actions. Self archiving means I won't find out it's fucking done." The outcome goes in the digest; a session with a likely next action (a question, a recommended action other than "None", a push/deploy/restart/sign-in) stays in the list instead.
• Each self-archive is judged on its merits — there is no setting for it. "Self archiving is often good but it is sometimes bad."
• "Recommended action: None" is not proof the work is finished. The final message is read in full and judged. "You need to use your fucking llm brain to evaluate each fucking case."
• Quiet hours. Digests are suppressed entirely inside the window, not delayed, and nothing is posted when it ends unless the night had an exception. The setting is Quiet hours, in Settings → Overseers → Behaviour, on by default across 22:15–08:15.
• An item another owner has taken leaves the list once that owner confirms, with a digest line naming who has it.
• Updates never close with a nothing-to-report line. "Updates never end with filler like 'Nothing needed from you'; if there is nothing for him, say nothing about it." Nothing to ask means no such section — the filler itself is the intrusion.
• The agent knows your other overseers and what each one is for. It reads the live roster on every pass and routes an item to the owner whose mission covers it, never to whoever is nearest. The roster and each one-line mission come from GET /overseer/hub; the owner's own brief for a given overseer is that session's firstOperatorMessage from GET /sessions?q=<name>. Note that GET /sessions/digest is not one of these — it is a privileged route and answers AUTH_REQUIRED to a session's own token, so a client reading it as an empty list would report "no overseers" on a refusal.
• It works in your project and nowhere else. Only items whose project is the one the agent was started for are touched; another project's session or card, and any card with no project, is left alone and never judged. "Do not touch a single one of my other fucking things." It also never investigates or routes machine infrastructure — drives, the test fleet, the git store, the rebase lanes — and never puts machine health in an update.
• One row per ask. A question appears in the routed update and never also as a card, so there is nothing to reconcile before answering.
• The digest is bullets and nothing else — no section headings, no group bullets, one short sentence per bullet, and at most ONE level nested underneath.
• While it runs it screens your inbox. Starting one switches the gate on (inboxOverseerGateEnabled, addressed at the agent through inboxOverseerGateSlot) so new sessions and alert cards are held for a moment. The agent reads GET /overseer/gate/held each pass and ends every hold itself — POST /overseer/gate/release for what you should see, POST /overseer/gate/dispose for what it handled, batched up to 50 through POST /overseer/gate/act. Unsure means release.
• The gate cannot strand anything on its own. Its address is the agent's crew lead, so a crew with no live lead has no address — a stopped agent holds nothing, and an item already held is released on its own deadline.

For agents

The inbox-agent skill carries the full routine — the passes, the five dispositions, the safe defaults, the digest format and the interview. Load it rather than improvising a routine.

Over the control server: GET /inbox-agent reads whether an agent is running and whether its registration landed; POST /inbox-agent/start starts one; GET/POST /inbox-agent/rules and PATCH/DELETE /inbox-agent/rules/:id read and edit the rules. Every one of them is absent until the feature is revealed.

Related

• agent-crews.md — an inbox agent is a crew lead, and registering is what arms its five-minute pass and its digest.
• overseers.md — the always-on assistant an inbox agent sits beside.
• inbox-overview.md — the inbox an agent reads, and what lands in it.