--- title: Overseer worker titles (how a spawned worker is named) --- # Overseer worker titles (how a spawned worker session is named) ## What it is ### What it is When an **Overseer** spawns a worker session, that session is titled for it, in one fixed shape: ``` [] : ``` For example `[Verdict] Fixer 1: Fix the flaky auth test`, or `[WT Lifecycle] Red Teamer 2: Attack the lander contract`. The point is the session list. An Overseer runs several workers at once and they all look alike — a wall of "Session 47"-ish rows tells you nothing about who sent them, what they are for, or which one you are looking at. The title answers all four questions at a glance: - **`[Category]`** — what the Overseer is managing, in its own one-or-two-word tag (`Verdict`, `WT Lifecycle`). It is what groups a crew together in the sidebar and separates it from everyone else's work. - **``** — the worker type's label, so it always matches what was actually asked for (`Fixer`, `Auditor`, `Red Teamer`, …). - **``** — that role's running count under that Overseer: the 46th Fixer is numbered 46. - **``** — the job the Overseer wrote, shortened to fit. ## Where to find it The title appears on the spawned worker's own session row — in the session list, the inbox, and anywhere else that session is listed. There is no screen to open: the Overseer writes the title when it spawns the worker. ## How it behaves ### What you need to know - **The number never repeats, and it never resets.** It comes from a stored counter per (Overseer, role), not a tally of the session rows — so archiving, deleting or retention-purging old workers cannot hand the same number out twice. "The 46th Fixer" always means one session. - **Numbering starts at 1 with no backfill.** The worker type was never recorded on a session, so workers an Overseer ran before this shipped cannot be attributed to a role. Every (Overseer, role) pair begins at 1 and counts up cleanly from there. - **A title set this way is never rewritten.** The AI auto-titler only acts on sessions still carrying a placeholder name, so a structured title is left alone. - **A gap is possible, a repeat is not.** If a spawn fails after the number is handed out, that number is skipped. That is deliberate. - **Only Overseer spawns are affected.** A cron spawn, an ordinary agent-driven spawn, and a session you start yourself keep exactly the naming they had. ## For agents ### How an Overseer gets one The Overseer spawns through `POST /agent/sessions` and sends two fields beyond the job: - `agentType` — a worker type from the closed registry (`GET /overseer/agent-types`). Its label becomes ``. - `category` — its own short tag for the mission, at most 24 characters. This becomes `[Category]`. The Overseer does **not** send a `name` on this path; the server composes the whole title, and `` is assigned at the moment the session is actually created (once per real spawn — a retried or re-approved request cannot consume a second number). An Overseer that sends no `category` still gets a clean title — `Fixer 1: Fix the flaky auth test` — rather than an empty pair of brackets. ### Notes for the curious - A category that is too long, awkwardly spaced, or wrapped in its own brackets is trimmed down for the title rather than rejected — a real, paid worker is never refused over a cosmetic field. - The category is cleaned of control and direction-override characters on arrival, because the spawn request rejects those outright and a stray one would otherwise fail the whole spawn. - `POST /project//new` titles only review sessions for you — through its `review` field (see [review-session-titles.md](review-session-titles.md)); any other session started that way is named like any other. ## Related - [overseers.md](overseers.md) — the Overseer that spawns these workers and the fleet it runs. - [agent-status-board.md](agent-status-board.md) — the board where worker sessions show up.