Inbox overseer gate (hold new items for one Overseer to screen)

What it is

An Overseer is an agent you run that watches your fleet and answers other agents for you. This feature lets ONE of them also screen your inbox. Instead of a new session finishing a turn, or a new card being raised, landing straight in front of you, it waits a short while on that Overseer's desk. The Overseer looks at it and does one of three things:

• Lets it through — it appears to you as it normally would.
• Puts it away — it decided this is something you need not see, and records why.
• Does nothing — and when its time is up, the item arrives to you anyway.

The point is that the arrangement becomes something you can check rather than something you take on faith. An answered session and a silenced card used to look identical to one that was never raised. With the gate on, both what is waiting and everything the Overseer already handled are readable, so its silence is something you can prove rather than trust.

• It is not the same as the alert grouping an Overseer already does. That one briefly batches related alerts so duplicates and near-duplicates arrive as one thing. This one holds a single item for a single decision, and records that decision.
• It does not hold work. The hold exists so an Overseer can glance at one item and decide, not to park things until it gets round to them. Its default is ten minutes.

Where to find it

• The switch is on the Overseers hub, in the "How they behave" settings. One toggle turns the gate on, and a slider sets how long one thing may wait on the Overseer.
• What is being held, and what was handled, is a chip in the inbox header — the row at the top of the inbox where the title sits. It appears only while the gate is on. Clicking it opens a small panel with two lists: what the Overseer is holding right now, each row with a Release button, and what it already dealt with, each row with the disposition and a one-line reason.
• Releasing one item is that Release button. It works at any time, with no confirmation, and it does not depend on the Overseer being alive — the item goes back to your inbox the moment you click. There is also a rebindable keyboard action for it (Settings → Keybindings), with no default key set.
• The Overseer reads and acts on what is held over the command line, not through the app: GET /overseer/gate/held lists what is being held, GET /overseer/gate/handled walks back the history, and POST /overseer/gate/release and POST /overseer/gate/dispose end a hold. Those two POSTs refuse every caller that is not the named Overseer, so no other agent can quietly clear something out of your inbox.

How it behaves

It is switched off until you switch it on. While it is off, nothing is held, no item's delivery changes, and every existing path behaves exactly as before.

A hold always has an expiry, and the item itself honours it. Even if the background pass that releases expired holds stopped running entirely, a held item would still arrive on time, because the reader that decides whether an item is visible checks the expiry itself. A dead part of the machinery can never turn a hold into something permanent.

Nothing is held when there is nobody to read it. If the Overseer you named is not running, is paused, is stood down, or has stopped itself over spending, the gate declines to hold and the item comes to you. An item waiting on an absent Overseer would be a delay with no purpose.

Held things are never deleted or rewritten. A release puts the item back exactly as it would have arrived — it kept its own status and its own question the whole time it was held, so there is nothing to restore. Putting something away archives it rather than destroying it.

A few classes are never held, whatever the settings say. Money and billing, security and credentials, and anything you scheduled or are waiting on always pass straight through. Anything the Overseer says to you, or raises for you, is never held by its own gate — that would be a loop with no exit. Permission requests and plan approvals always come straight to you too, because those are your decisions and nobody else's.

You can add your own pass-through entries. A setting holds a list of entries; anything whose key matches one, or begins with one, is never held. An entry for a whole family of alerts therefore waves through everything from that producer. The list ships empty.

A flooding producer cannot build a wall out of your inbox. If the number of things being held at once reaches a fixed ceiling, the gate simply stops holding anything new until the backlog clears, and items flow straight through. This is a safety valve rather than a volume control.

Every skip has a name. The gate counts one event per outcome, so a near-zero hold rate can be read as a specific reason — nobody to hold for, unhealthy, not an item it screens, an owner-critical class, on your own pass-through list, the ceiling, the Overseer's own traffic, or a session that was already waiting on you — instead of looking like a quiet success. (A gate that is switched off is not among them: it refuses before it decides, so there is nothing to hold and nothing to count.)

Off by default; the two on-screen controls are the switch and the hold length. Which Overseer runs the gate, and your own pass-through list, are live settings that do not yet have a control on the settings screen. Left alone, the gate uses your global Overseer and the built-in protections only.

For agents

• Contract — .claude/memory/contracts/inbox-overseer-gate-contract.md (invariants O89–O96). Read it before changing what an inbox overseer may withhold.
• Map — .claude/memory/inbox-overseer-gate.md: the pure decision and the order of its refusals, the one record and the hide seam, the two doorways, and where a change bites.
• Settings — inboxOverseerGateEnabled (default false), inboxOverseerGateSlot (default '' = the global Overseer slot), inboxOverseerGateMaxHoldMinutes (default 10, clamped 5–120), inboxOverseerGateAlwaysThrough (default []).
• Storage — inbox_gate_items is the record; gate_held_until on sessions and on inbox_alert_items is its projection onto each reader. The item's own read honours the expiry; the sweep is a backstop, never the authority.
• Events — overseer feature tracking emits gate_held, one gate_skipped_* per refusal, plus gate_released and gate_disposed.

Related

• The Overseers themselves — what one is, what it watches, its heartbeat and its spend cut-off — are covered on the Overseers hub in the app and in the Overseer contract family.
• The short-window batch hold that groups related alerts before they reach you is a separate mechanism; it answers a different question (how many things arrive) from this one (whether this one arrives at all).
• The session digest an inbox overseer reads to triage is its own contract, not this one.