Overseers — running one (part 2)

What it is

This is part 2 of the Overseers page — the operating half: keeping an Overseer running and steering what it watches.

Where to find it

The Overseers hub again — every control described here is on one of its tabs or in the Overseer's own settings.

How it behaves

How it wakes up (the check-ins)

Each Overseer is woken automatically on its own schedule to do the job you gave it. There is nothing to set up — no cron job, no scheduled task, no script.

• Two check-ins are seeded for every Overseer, and neither can be removed. A Heartbeat every 15 minutes — the regular look around — and a Review every 6 hours: a slower, wider pass over the standing picture.
• They are ordinary durable schedules on the Overseer's own session, so a check-in survives an app restart and the session being replaced. A wake-up still arrives as a real turn, so the Overseer remembers what it looked at and did last time.
• The keeper restores a check-in that goes missing or runs out. Every schedule fires a finite number of times, so one that reaches the end of its budget is re-created on the next keeper tick — an Overseer that looks alive but is never woken again is the failure this prevents.
• Every wake-up is also SUBMITTED, not just delivered. The wake says only that the round is due: the Overseer pulls its brief (GET /overseer/heartbeat — the fleet digest, the board traffic, and the sessions it owns) and then sends the round with POST /overseer/round. That submission is what reaches the audit list, your inbox and the fleet board, so a round the Overseer does not send is a round nobody ever sees.
• Change the cadence fleet-wide in the hub's Fleet settings, or per Overseer on its Settings tab (the wizard's Rhythm step names the fleet's live default).
• The Settings tab's Wakes up section shows what is actually scheduled — each check-in, the cadence it really fires on, how much of its fire budget is left, and a warning when a required one is missing, spent, or set to a cadence no schedule can express.
• Add a check-in of your own from that same section: a Heartbeat or a Review at any cadence a schedule can express exactly (minutes dividing an hour, or whole hours). Adding one never replaces or disables the required pair.
• An Overseer can re-pace its own heartbeat, without asking you, by calling POST /overseer/heartbeat {"everyMinutes": N}. Its briefing tells it so. That is the point: an Overseer that notices it is checking too often, or not often enough, simply fixes it.
• A cadence of 0 means "never wake this one", and it is honoured where a check-in is created or restored. An explicit per-Overseer value wins in both directions, so "every Overseer except this one" works — a heartbeat already scheduled on a running session keeps firing until that session restarts or its own fire budget runs out.
• A quiet wake-up leaves no trace. If it wakes, looks around, and finds nothing worth doing, nothing is recorded — so the audit list stays readable even at a fast cadence.

Each wake-up is a real paid turn. Every 15 minutes is 96 a day per Overseer, before the 6-hourly review adds four more.

Check-ins used to be a private timer. Until 2026-09-19 each Overseer was woken by a bespoke in-memory timer with its cadence in a settings number, and a round was read back out of the session's own transcript. Both are gone: the cadence lives on ordinary wake schedules, and the round is submitted by the Overseer itself. The keeper took over two jobs from the retired timer — restoring a required check-in, and arming the runaway-spending breaker.

Two different things guard that spending, and it is worth knowing which does what:

• The runaway-spending breaker is a runaway detector, not a spending cap — a permanently fast cadence simply becomes the normal it measures against. It watches for a sudden spike against what the Overseer normally costs, and pauses it until you restart.

• The shared daily ceiling IS a hard cap, and it is off by default — there is no limit until you set one. Set a dollar figure and it covers the Overseer and every swarm it runs, together, as one budget. When the day's total reaches it the Overseer stops waking and no new swarm workers start. It resets at local midnight and resumes on its own — unlike the breaker, it never needs a restart, because being out of budget for today is not a fault.

  Swarm spending counts against the ceiling but is deliberately kept OUT of the breaker: a swarm running several workers costs far more than an Overseer alone, so counting it into the spike detector would trip it every ordinary hour and leave the Overseer paused for doing its job.

Only the global Overseer's wake-up carries the fleet digest and weekly summary as context; the others just get on with their own job.

Only the global Overseer can put a card in your inbox from a wake-up. Every Overseer records what it did in the audit list, but a card is a stronger claim — a person should look at this — and only the global one is reading the fleet-wide digest that produces that kind of conclusion. Without this, a fleet of Overseers each waking four times an hour would turn your inbox into an activity log, which is the exact noise the Overseer exists to remove.

History worth knowing. Until this existed, an Overseer was never woken at all. The service meant to do it was written, tested, and documented — but was never switched on at startup, so it never ran once, and a per-project or custom Overseer's job description was never executed by anything. The same was true of the spend breaker: it could not trip, because nothing called it. Both are now live.

How it stays alive

A background service — the keeper — checks every 30 seconds whether a live Overseer session exists for each enabled slot (global + any per-project ones). If none exists, it spawns a fresh one. The keeper uses an exponential backoff when spawns fail and raises one inbox alert after five consecutive failures so you know something is wrong.

The 30-second check is the keeper's steady state, not a delay you wait through: switching an Overseer on runs the keeper straight away, so it starts within a couple of seconds of the switch rather than at whatever tick came next.

The keeper also holds the two spend gates and restores the check-ins, both of which used to belong to the retired wake-up timer: a tripped runaway-spending breaker pauses the keeper until an app restart, a reached shared daily ceiling skips the tick (so it comes back by itself when the day rolls over), and every healthy tick re-seeds a required check-in that has gone missing or run out of fires.

A brand-new Overseer gets its check-ins the moment it starts — they are seeded against the new session as it is created, so there is no first interval of silence to wait through.

Archiving an Overseer's session switches that Overseer off. The keeper stops replacing it, and so the agent stops and stops costing anything, until you start it again. This is the second way to turn one off, alongside the run switch on its Settings tab — use whichever is in front of you, and the two agree.

To bring it back, either reopen that session (which clears the archive) or switch the slot on again; a switch-on counts as the more recent of the two instructions, so it wins. Nothing is lost either way — the notes file and the transcript stay exactly where they are.

The stuck-session sweeper (which recovers crashed sessions for normal agents) explicitly excludes Overseer sessions. Only the keeper ever revives them. This prevents the sweeper's hard cap (12 consecutive failures → permanent terminal state) from applying to a session that is designed to be permanent.

Memory and scheduled restarts

The Overseer's durable memory lives in a file called NOTES.md in the app's own data directory (<userData>/overseer/NOTES.md), and it stays there for every kind of Overseer — global, per-project or custom. Running one inside your repository therefore never touches that repository: no file is created, changed or deleted in it, and its git status is exactly as you left it. You can read the notes or add to them directly; the Overseer writes to them as it discovers patterns worth keeping.

When the Overseer starts (whether for the first time or after a scheduled restart), its standing instructions reach it as a system-level briefing the session carries every turn, never as a file dropped into the working directory:

1. A base persona with an instruction-lock section (prompt-injection guard).
2. Your custom Overseer instructions (from settings).
3. Its own notes, read from the notes file above.

The briefing is delivered through the system prompt rather than a generated CLAUDE.md, which is what makes "an Overseer writes nothing into your repo" structural instead of a promise: a generated file in a project's folder would collide with one the project may already own, and would dirty every repository that has an Overseer. (Upgrading from an older build deletes that generated file once, so an existing Overseer cannot end up carrying its instructions twice.)

Notes carry forward across restarts — the Overseer never loses what it has written down. Context resets (fresh session, no accumulated context); notes persist.

Scheduled restarts happen automatically at the interval you set (overseerRestartHours, default 24 h). The keeper terminates the current session and immediately spawns a fresh one that re-reads NOTES.md. Restarts are deferred if the session is mid-turn (status running, starting, stalled, or terminating) — the keeper waits for the next tick. Every restart is recorded in the action ledger (see below).

How it screens the inbox (the hold mechanism)

When any alert is created — whichever part of the app or which agent raised it — the Overseer can place a hold on it:

• The hold is a nullable held_until timestamp on the inbox_alert_items row.
• All three user-facing alert reads (listActiveAlerts, listDripSourcedInboxItems, listAlertsByDrip) exclude held rows by default. A held card is invisible to you, to the phone, and to the badge count — but it is NOT deleted or suppressed at the push layer.
• A release sweep runs on each cycle and clears expired holds, emitting ALERT_CHANGED so the renderer picks up the newly-visible card.
• A clock-jump floor force-releases any hold sitting too far in the future (a multiple of the hold window), so a bad clock cannot hold a card forever.
• Past a storm ceiling (many cards held at once), new cards are not held at all — fail-open.
• Some cards are never held (overseer-never-held.ts): anything that can page the phone (owner-critical alerts), auth/spend/security/data-loss/real-time-comms prefixes (including all team-chat notices), and any card with an empty or unknown dedupKey. An unclassifiable card is always immediately visible.
• If the Overseer is dead or unreachable, the hold step is skipped and the card goes straight through. The Overseer being broken can never silence your inbox.
• Only the global Overseer can cause a hold, because it is the only one that comes back to judge held cards. A per-project Overseer never holds anything: a card it withheld would be read by nobody and simply released later, which is delay without screening.
• Until 2026-09-11 this section overstated things. Holding was wired into one of the two ways an alert can be created, and the other one — the one almost every agent-raised card comes through — skipped the screening entirely. On the owner’s machine that was 130 of 138 live cards, and 14 cards had ever been held out of 9,910. Both ways now screen.

Having more than one Overseer

There are three kinds, and you can run as many as you like at once.

Kind	What it watches	How you get one
Global	everything	on whenever the Overseer is on
Per-project	one project	turn on "an Overseer for every project", or switch on the one project you want
Custom	only the sessions you assign it	you create it and give it a name

Any of the three can also be handed specific sessions to watch — see below.

"An Overseer for every project" (overseerAutoPerProject) gives each project its own, without switching them on one at a time. It is off by default — each Overseer is a real running session that costs money, so switching them all on is your call, never a default.

You can still turn an individual project off while that is on. An explicit per-project choice always wins, in both directions, so "every project except this noisy one" works.

Each Overseer is a fully independent session: its own spawn claim, its own failure counter and retry backoff, and its own memory. A slow spawn for one never delays another, and one going down does not affect the rest.

A project-scoped alert goes to that project's Overseer if it has one, otherwise to the global one.

Copying an Overseer

A running session can ask for a copy of itself in one call, and what it gets depends on what the copy is FOR. POST /session/:id/clone takes a kind:

kind	What you get
one-off	An ordinary session, started on the source session's own engine with the briefed opening below. It runs its job and finishes — it is not an Overseer, nothing keeps it alive, and no slot is created for it.
standing-peer	A full new Overseer on its own slot, with its own heartbeat and its own memory, kept alive by the keeper like any other. It is a slot rather than a session, so it starts from the slot's own instructions, not from a brief.

A copy is never blind. It used to be handed its mission and nothing else, so it opened blank and asked what the conversation had already answered. A one-off copy now opens with four things, in this order, and the mission last:

• Who it is — its own name, the session it copies, and the engine and model it was actually started on. That line outranks anything else the agent reads about itself, including the harness banner in its own terminal, because a copy that believed its banner over its brief refused to do the job it had been copied for (measured 2026-10-04).
• The crew's memory, when the session it copies belongs to a crew — the same block that crew's lead is woken with.
• The conversation it is carrying — the source's visible messages, the same ones the export button gives you, scoped to the most recent compaction so a copy gets a working thread rather than an archive. A very long thread is trimmed in the middle with the amount dropped stated in band, so nothing is silently cut.
• A purpose brief, from one fixed template every copy shares: the single job it was made for, what to return (a one-line summary, then the finding and the evidence), that its actions are read-only, when to stop (including a 20-minute limit), and who it reports to.

The engine comes with the copy. Unless the caller asks for something else, a copy runs on the source session's own engine and model, so it is the same instrument you started. provider and model in the body override that, and a pair that engine cannot run is refused with a 400 rather than quietly swapped for the box default. A source whose own model has since been retired is not refused — the copy keeps that engine and uses its current default model.

The mission is recovered, never invented. The copy is given the mission the source session was started with — its own first message, the exact text a person typed. Hand it a session with no opening message and the call is refused with "there is nothing to copy", because a copy carrying a made-up job would be worse than no copy at all. An optional job in the body is what the brief names as the copy's one job — the instruction it reads before the mission, never instead of it, so the copy knows what it is before it is told what this particular run adds.

A standing peer does not ask you first. Creating an Overseer normally raises an approval card — POST /overseer/slots still does, and so does switching one on. This one path is a deliberate exception to that rule: you already approved this Overseer by standing it up and giving it a standing job, so it may make a peer of itself on its own authority. Only an Overseer can ask for one — a plain session asking is refused — and the ordinary routes are untouched, so every other way of creating an Overseer goes on asking exactly as before.

Nothing about that is open-ended, because two brakes stand in front of it:

• Your cap — overseerSelfCloneLimit in Fleet settings (Copies of itself). Leave it blank and there is no cap. Set a number and it bounds how many peers made this way still exist, so deleting one frees the room back for another. It is one number for the whole box, and a switched-off peer still counts — it exists, it holds its slot, and it can be switched back on.
• A built-in burst guard — one Overseer may make at most three standing peers in any trailing hour. This is not your setting: it is always on and it does not move when yours does. It exists to catch an Overseer that has gone wrong minting a burst of paid always-on sessions in one sweep. Three in an hour is far past anything a working Overseer does, so an Overseer making a second peer next week is left alone.

The two refusals read differently on purpose. When your cap is the one that refused, the message names the number and tells you to raise it in settings; when the burst guard refused, it says to try again later — because one is a limit you chose and can lift, and the other is not.

One-off copies carry a guard of their own, not a share of that one: a copy is a much cheaper thing than a standing peer, so the two are counted separately. Across the whole box, one-off copies are capped at twelve in a trailing hour, and a copy is only counted once it actually starts. It is not a setting, and it is deliberately far above ordinary use — twelve real investigations in one hour is a busy night, so a working Overseer never meets it, while a runaway loop meets it at once.

The review round — where an Overseer buys fresh eyes

An Overseer is woken by two schedules: a heartbeat (its regular check-in) and a review (every six hours, a slower and wider look). The review exists because an agent cannot see its own blind spots from the inside, so the round does not ask it to try.

For a crew lead, the app runs the round itself (app-run side missions, on by default — the "crewAppRunReviewsEnabled" setting turns it off). When the review is due, the app:

• picks the next of thirteen written lenses — each lens runs once before any repeats:
  • Owner's Eyes, Claim and Done Audit, First-Principles Rethink, Blind-spot Scan, Toolsmith;
  • Stop Doing, Speed, Owner's Time, Collision, Hand-off, Owner's Experience, Every Developer, Safety;
• gathers the evidence itself, with secrets scrubbed before anything leaves the machine:
  • the owner's own typed words to the mission, and what the lead told the owner;
  • the crew's tasks with their proof, and its rules and decisions;
  • spend, live machine load, and earlier rounds' findings;
• starts an independent reviewer through the Review Service, on a low-cost AI from a different vendor than the lead (DeepSeek, or GLM when the lead runs on DeepSeek) unless the owner named one in "crewReviewEngine".

The lead is not woken to do the review. When the review finishes:

• each finding (at most five) is added to the crew's task list as a "Review finding" task the lead owns, due two hours later;
• the lead accepts a finding by closing its task as done, and the app refuses that unless the outcome names what makes the fix stick: a move made now, a check, a playbook change, or an owner card;
• the lead rejects a finding by closing its task as dropped, with its reason;
• a finding left open past its due time is flagged overdue;
• a finding about the lead itself that a later round repeats reaches the owner as one inbox card per crew and topic.

A round that cannot start is recorded with its plain reason rather than handed back to the lead. The reasons are:

• the lead is not running;
• the machine is busy;
• two mission reviews are already running;
• no reviewer AI can run.

The first three postpone the round rather than cancelling it, and the same lens comes round again on the next wake. Because the machine being busy and the review slots being full both clear on their own, neither may hold a review up for ever: after a small number of deferrals the round runs anyway, and says on the record that it started late. A lead that is not running is the one reason that does not expire — a review nobody will read is waste, not service.

The rules are in the Overseer Side Missions contract.

With app-run rounds switched off — and always for a slot Overseer — the round asks the Overseer to spawn a reviewer: a fresh, read-only session that reads its notes and ledger and reports what it finds.

Which call starts that reviewer depends on which kind of Overseer it is, and it is worth knowing why, because the two were confused for a while and a whole round was lost each time. A crew lead uses POST /crew/reviewers — no body; the app reads the crew, works out the project and the lens, and writes the reviewer's brief itself. That is deliberately the only spawn a crew lead's own locked-down credential is allowed to make, which is the point: a lead can buy fresh eyes without being handed the run of the machine. It refuses anything that is not the live lead, and it will not start a second reviewer while one is still on the crew. A slot Overseer spawns through POST /agent/sessions with an allowed agent type, as before.

In that mode, successive reviews rotate through six lenses, so each round asks a genuinely different question instead of re-finding the last answer:

Lens	What it asks
META	Which of my own rules would have prevented my last mistakes?
RED TEAM	Attack my findings and every "done" I accepted.
PATTERNS	What recurring shape am I still treating as separate instances?
FRESH EYES	Re-derive the approach from scratch, without my priors.
INTAKE AUDIT	What request never got a row, an answer, or a close?
SPEND	What did the period cost, and what was waste?

The Overseer records which lens is next in its own notes — for a crew lead, a decision line on its crew log — because the reviewer is a fresh session that carries none of that memory. A reviewer is normally capped at ten ranked findings, each with its evidence.

Both of these abilities are named in the prompts an Overseer actually reads — the standing persona for a slot Overseer, and the wake prompts for a crew lead — which is the fix for a real gap: both were fully built and documented while appearing in no prompt at all, so no Overseer ever used either one. The two kinds of Overseer spawn their reviewer differently:

• A slot Overseer requests a reviewer worker through the agent-driven route. If that is refused (its allowed agent types may exclude reviewer), it says so.
• A crew lead spawns its reviewer through POST /crew/reviewers — the one spawn its own scoped credential can make. The normal pathway (POST /project/<name>/new) and the agent-driven route both refuse every crew session. The reviewer registers into the crew, changes nothing, and reads the crew's record itself. It starts on the app's configured default engine, the same one every other agent spawn uses.

Either way, a refused spawn is reported rather than quietly replaced by a self-review, because a self-review reads exactly like a completed one. The copy ability splits the same way: a one-off copy works for any Overseer, while a standing peer can only be copied from an Overseer slot.

Giving one specific sessions to watch

A whole project is often the wrong unit. Open any Overseer's Settings tab in the hub and you can name the exact sessions it is responsible for — the Sessions it watches field, with a chip per session and a search box to add another. The wizard's Scope step offers the same choice (Just these sessions) when you set one up.

This is also what makes a custom Overseer useful. Before it, nothing routed to one at all: it woke up, read its job description, and had no work attached to it.

Three things change once a session is assigned:

1. Its alerts go to that Overseer — not to its project's, and not to the global one.
2. Its questions reach that Overseer when the agent asks for guidance.
3. That Overseer is told about it — every wake-up lists the sessions it owns with their current status, project, and when they were last active.
4. Its finished turns report to that Overseer, not to you — see Where a watched session's answers go below.

A session has exactly one Overseer. Add a session another Overseer already watches and it moves; the dropdown says who currently has it, so that is never a surprise. The most specific choice wins: an assigned session beats its project's Overseer, which beats the global one.

Assigning pins a session; it does not narrow the Overseer. Give the global Overseer three sessions and it still covers everything else — otherwise every un-routed alert would have nowhere to land. A per-project Overseer likewise keeps its whole project and simply picks up the extras.

A broken assignment quietly falls back. Delete or switch off an Overseer that was watching sessions and they revert to their project's Overseer, or the global one. Nothing is stranded.

The dropdown lists sessions that are still running — an Overseer watching a finished session has nothing to do — and the list handed to the Overseer is capped, so a large assignment cannot quietly multiply what every wake-up costs.

Starting an Overseer from an existing session

If an ordinary session has been doing Overseer work, use Use an existing session as a template in the hub's New Overseer wizard. This creates a real native Overseer; it does not relabel or modify the old session.

The template copies only editable basics—its name, a bounded purpose, and its project scope. It does not read or import the conversation, notes, files, hidden instructions, or other session content. Review the purpose, scope, sessions, rhythm, allowed agent types, interrupt budget, and cost before starting it.

Omniscio then performs the handoff in a safe order:

1. It creates and starts the native slot through the normal approval and keeper path, without moving any watched sessions.
2. The hub shows Starting until that exact slot has a canonical live session. A keeper failure changes the state to Needs attention; Running means the native session is live.
3. Only after Running does it move the sessions you reviewed. Each move succeeds only if that session still has the same owner it had during review, so a concurrent reassignment always wins.
4. Conflicts are reported and left untouched; successful moves are kept.

A startup failure or abandoned wizard leaves assignments unchanged. The old session is never messaged, stopped, archived, deleted, or rewritten automatically. Keep it as history until the replacement has completed whatever real operating proof you require, then archive it separately.

Custom Overseers still govern only sessions explicitly assigned to them. A specialist-sounding name does not grant project-wide or fleet-wide authority.

Doing it from the command line

POST /overseer/sessions moves one session in one call:

{ "sessionId": "<session>", "slotId": "custom:<id>" }   // assign (or move it here)
{ "sessionId": "<session>", "slotId": null }            // stop anyone watching it

The underlying setting (overseerSessionAssignments) is one whole map, so without this route you would have to read it, edit it and write it back — and skipping the read would wipe every other session's assignment. This route does that for you.

It is a convenience, not a second way in: it hands the result to the same approval step a raw settings change goes through, so a session running inside Omniscio applies immediately and any other caller is queued for you to approve. Nobody gains access they did not already have.

Two things it refuses rather than accepting quietly: a session that does not exist, and an Overseer that is not running (deleted, switched off, or a project with no Overseer). Both would be stored and then ignored forever, so the call would look like it worked and never do anything — the worst possible outcome for a script. Removing an assignment skips both checks, so a stale entry can always be cleaned up.

Where a watched session's answers go

Once an Overseer watches a session, that session stops reporting to you and starts reporting to it. The agent finishes its turn, its final message goes to the Overseer, and nothing appears in your inbox — no card, no badge, no chime. The Overseer reads it, and only what it genuinely cannot handle reaches you.

That is the point of an Overseer. Before this, one could command a fleet of agents and every one of their answers still landed on you.

Sessions an Overseer starts belong to it automatically. You do not have to assign them — if an Overseer spawned it, it owns it, and gets its reports back. An assignment you made by hand is never overwritten by this.

Questions go to it too. If the agent ends its turn asking something, the Overseer answers it when it can and passes it up when only you can decide.

Some things always come straight to you, whoever is watching. A request for permission and a plan waiting for approval are your call, not an Overseer's, and they are never handed off. Nor are the failure states an agent can get stuck in — a rate limit, a sign-in problem, an interrupted response — because something else is already working on those.

A watched agent can never be lost. Three separate things bring it back, and only one has to work: the Overseer replies and the agent carries on; the message fails to reach the Overseer, in which case the agent comes straight to you as it always did; or thirty minutes pass with no reply, and it appears in your inbox with its message intact. An Overseer that is switched off, deleted, stuck, or simply ignoring an agent cannot swallow it.

It is only ever quiet once the message has actually arrived. The hand-off is not "assume it worked" — if there is no Overseer running to receive it, or the delivery is refused, the session never goes quiet in the first place.

You can turn the whole behaviour off and keep everything else about the Overseer — the Send their sessions’ replies to them, not you switch, under How they behave in Overseer settings. Off, every session reports to you exactly as before.

Giving each Overseer its own job

Where: the Overseers hub. New creates one through the wizard (purpose, scope, rhythm, review — Start watching is the approval to spend, Save without starting keeps it unstarted); the Settings tab of any Overseer edits its name, purpose and job, and its run switch starts or stops it. A custom Overseer can be deleted from its Settings tab (it asks first) or simply switched off, which keeps whatever you wrote for it. Every one of those edits goes through one writer in the main process — the app itself never writes an Overseer's settings directly.

An Overseer that has never been started says so, where you are looking. Its Chat tab reads "Not switched on — it will not start until you turn it on", with a Turn it on button that is the same approval to spend as the Settings tab's run switch. An Overseer that HAS been started and is simply between wake-ups still says "It starts on its next wake-up" — the two are different situations and must never read the same way, because only one of them is going to start on its own.

Every Overseer has a name and a job description, both optional:

• Leave the job blank and it runs a built-in stock description — screen the inbox, answer agents, watch for patterns. Turning an Overseer on never requires writing a prompt first.
• Write your own and it replaces the stock text rather than being tacked onto it, so an instruction like "only watch billing, ignore everything else" is not contradicted by stock text telling it to do everything.

Don't want to come up with a name? Describe what it's for in the Purpose field instead — "Watch the billing pipeline and flag anomalies" — and Omniscio turns that into a short title for you automatically. Edit the Purpose later and the title updates to match, right up until you type a Name of your own; from then on your name always wins, and further Purpose edits never touch it. Already renamed it and want the generated title back? A Use the auto title button next to the Name field clears it for you.

Names show up in the session list, so you can tell them apart: Overseer, Overseer — Billing, or whatever you called your custom one. Without a name they would all read "Session 1", "Session 2".

Whatever you write, the safety half is always present and cannot be overridden by your instructions or by anything an agent says to it: the prompt-injection lock, the tool list, and the memory rules.

A custom Overseer can be paused without deleting it — it stops running and keeps the job description you wrote for it.

Asking one a question

Its Chat tab in the hub is its real session: type a question, get an answer. "What did I miss today?" / "Why is the billing project so noisy?" It has been answering your agents all along; this is your way in. Just us shows only your exchange with it; Everything it does shows the whole session, wake-ups and agent questions included. Swarms it proposes appear in the same tab as cards you approve or decline.

Why "Just us" is nearly empty compared to "Everything it does"

An Overseer's session is mostly machinery. Most of what is in there is the app talking to it — the wake-up prompt every fifteen minutes, the "here are the alert cards to judge" briefing, and the questions your other agents put to it — plus its replies to all of those. None of that is addressed to you, so Just us leaves it out. What is left is what the two of you actually said. On a busy Overseer that can be four messages out of a hundred and fifty, and that is the view working, not a bug.

Two things decide it, and neither is a guess:

• The app knows which turns it injected. A turn only counts as yours if you actually typed it. A briefing can never pass as your message, even one sent by a part of the app that forgets to label itself.
• The Overseer can quiet one of its own replies. When it answers you but the answer is just a routine status update — "done", "still watching" — it can tag that reply and it stays out of Just us. It decides; you never have to configure anything.

Nothing is ever deleted. A tagged reply is still in the session, still searchable, and shows in full under Everything it does. And the tag has limits the Overseer cannot talk its way past: it can only quiet its own answers, never anything you wrote; a reply that is asking you something always shows; and the answer to your most recent message always shows, so you are never left looking at your own question with silence under it.

Telling one it got it wrong

Any row on its Board tab where an alert was kept from you — silenced, merged, or still being held — carries an "I wanted this" button. Pressing it does three things:

1. Brings the alert back, so you get the thing you missed.
2. Writes the correction into that Overseer's notes, so it still knows tomorrow.
3. Tells the running Overseer immediately, so it applies today rather than waiting for its next restart — up to 24 hours away.

The confirmation says which of those actually happened. If the original alert was already gone, it tells you that rather than claiming everything worked.

The button doesn't appear on alerts that reached you normally — there'd be nothing to correct.

Related

• Overseers — part 1, what an Overseer is and how you create one.
• Overseers part 3 — the work it hands out, its settings and the internals.
• agent-status-board.md — the board that shows what the fleet is doing right now.