Supervisor
The judgment Vibestrate brings to a run - how hard it looks, and a labelled record of every call.
In simple words
A supervisor decides how hard to look at the work before calling it done. It sets the level of scrutiny, then writes down every call it makes. A building inspector, not the crew.
vibe ui opens the dashboard on 127.0.0.1:4317. Supervisors, under More in the sidebar, is the catalog: every supervisor available, which one is the default, and Set default on each card. The New run page carries a Supervisor picker that overrides the default for one run.
single-profile on the run’s Supervisor panel is the supervisor telling on itself: one model both wrote and judged, so the review is a self-check. Point the reviewer role at a second provider and the tag becomes cross-model. The label can lower your confidence in a result; it never inflates it.
You meet the result at the top of a run:
The decision count opens the feed. Where the flow was chosen rather than pinned, a why link expands Flow & why: the flow it resolved, where the choice came from, its confidence, and the words that triggered any upgrade.
A supervisor is advisory, and only ever adds scrutiny. It can upgrade a run to a heavier flow, never downgrade one; it can suggest a stricter execution posture, never relax it. A setting that could quietly reduce checking would make every verdict weaker.
One word, two things. This page is the setting, which project.yml calls a persona. The Supervisor chat on Mission Control is a conversation, covered by supervisor control. Under vibe supervisor, list, archetypes, adopt, default and remove manage the setting; stop, resume and status belong to the conversation.
The calls it makes
More care for risky work. Each supervisor carries a list of risk signals. The default staff-engineer watches for logins, payments, credentials, database migrations, permissions and concurrency. On a match the run is upgraded to a heavier Flow, a multi-reviewer panel, and the words that triggered it are recorded.
The reviewers’ aim. A supervisor’s lenses aim the reviewers. staff-engineer points them at correctness, tests and security risk; the built-in security at authorization, secrets and injection. Which lenses ran is recorded.
A heavier posture, suggested. For a risk-tagged task a supervisor can ask for a heavier way of executing. security asks for sandbox-suggested, which by default is a suggestion you see rather than a gate.
A lens on planning. A supervisor can also aim the agents that scope, spec and architect the work in Spec-up. The default stays neutral.
The lens vocabulary is closed. These ten, and nothing else:
Naming a lens is the only way a supervisor changes what a reviewer looks at, so a project cannot slip free-form instructions into a review. A lens outside the vocabulary contributes nothing.
A suggested posture becomes a rule only if you say so. posture.autoApplySandbox makes a sandbox-suggested run sandboxed; posture.autoApplyApproval makes each change wait for your approval. Both default off, and the Supervisor posture group on the Policies page carries both as switches.
The two switches are not guarded alike. The approval gate steps aside twice: an explicit --permission-mode wins over it, and it is suppressed for unattended runs, where a prompt would only stall. The sandbox has neither escape - autoApplySandbox raises isolation on a sandbox-suggested run regardless of --permission-mode, because it only ever raises safety and there is nothing to stall. What it does not do is pretend: only a provider CLI that enforces a real OS sandbox gets one, and a seat on a provider without one degrades and is reported as unsandboxed rather than counted as protected. The default supervisor stays posture-neutral, so a plain vibe run meets none of this.
Context it adds, never removes
Between steps, a seat receives the inputs its step declares, and they arrive whole: prior artifacts are delivered in full up to a budget of 32K tokens (2K under the compact context policy), and only when that ceiling is genuinely hit are the largest inputs summarized, largest first. An input a step names in requiredInputs is never summarized; if it is missing, or would only fit as a summary, the run stops before the step starts rather than let the model work from a digest. The flow YAML reference has the field.
The supervisor’s part is what a step was not given. Every run produces more than any one step declares, and a reviewer that never saw the architecture step’s output will report a settled decision as a finding. So before each seated step, the supervisor looks at the outputs this run has produced that the step did not declare, and may add from them. It is never shown what the step already has, so there is no shape in which it could shrink or drop an input: adding is the only sentence it can form.
Two tiers do that work.
- A manifest, always on, no model call. One note listing every undeclared output with its size and where to read it. A fact, not a guess; the seat decides whether to open one.
- A model tier, off by default. With
supervised.supervisor.contextEngine.enabled: true, the supervisor reads a 1,500-byte preview of each candidate and names up to two worth having. The run then injects up to 6,000 bytes of the artifact’s own text, never the supervisor’s paraphrase, so a hallucinated name resolves to nothing. One model call per step; a provider failure adds nothing and records why.
supervised:
supervisor:
contextEngine:
enabled: true
profile: null # null = the supervisor's own profileAdditions are capped at four per step and 8,000 bytes each, carry the supervisor’s stated reason, and each becomes a supervisor.context_injection event with effect: added, its source, label and size. Each tier also records a verdict per step, added, declined or failed, so a step that got nothing extra is distinguishable from an engine that never ran. Both show on the run page in the supervisor’s decision feed, on the step they belong to: an addition as what was added and why, the model tier’s decline as a judgment, a failure as a warning. The step’s context packet at artifacts/flows/<step-id>/context-packet.json lists what was delivered whole, what was summarized, what was missing and what was added.
Judgment, enforced, or structural
Every entry in the decision feed carries one of three labels.
judgment - the supervisor’s own call: which flow to run, a review verdict, a verification verdict. A model made it, so it can be wrong.
enforced - a deterministic gate fired: the diff gate, an Action Broker denial, a budget ceiling, a required approval. No model was involved.
structural - the supervisor carrying out the shape it chose: a parallel review wave, a rewind.
Picking one, and picking who reviews
Two supervisors ship built in and need no setup: staff-engineer, the default, and security. Six more are archetypes, which have to be copied into your config first.
Add supervisor, on the Supervisors page, opens two tabs. From an archetype lists the six with an Adopt button each. Write your own takes an id, label, description, risk signals, preferred flows and a suggested posture, validated against the persona schema before it lands in project.yml. Nothing is enforced until you set it as the default or pick it on a run.
Point reviewerProfile at a Profile and every review seat runs it: a cheap model for routine reviews, or a different vendor for an independent second read. It is a config field only; the Supervisors page shows it on a card but never sets it.
personas:
thrifty:
label: Thrifty staff engineer
reviewerProfile: cheap-reviewer # review seats
profiles:
cheap-reviewer:
provider: claude
model: haikuGive it a new id, as above. A personas: entry replaces a built-in of the same name, so writing staff-engineer: here to change one field empties that persona’s risk signals, preferred flow and lenses, with no error. A new persona starts empty for the same reason. A per-step profile override, or a run-wide --profile, beats reviewerProfile.
Project rules are not the supervisor’s
A rule like “use a hyphen, not an em-dash” belongs to the project. The active supervisor is the enforcer, not the owner: it carries advise rules into the reviewer’s turn, and the project’s block rules cap the merge whichever supervisor is on duty. Policies has the tiers. Older configs scoped these under a persona’s preferences key; vibe policies migrate lifts them across once.
Automation
The interactive shell (vibe, or vibe shell) has no supervisor screen, and its Config page does not carry one either - that view has fourteen sections and personas are not among them. Picking and authoring happen in the dashboard or on the CLI, and these are what a script or a repo template reaches for.
vibe supervisor list # what you can pick
vibe supervisor archetypes # the six adoptable ones
vibe supervisor adopt security-hawk # copy it in
vibe supervisor default security-hawk # then use it
vibe run "harden the login" --supervisor securityThe CLI overview has the shape of the tool; the command reference has every flag.
Also worth reading: Flow is what an upgrade changes.
Next: policies is the rule surface a supervisor enforces on every run.
