Help Desk autopilot

What it is

The Help Desk autopilot answers two of the Help Desk's own go-ahead questions without you, and then tells the reporter what happened. The first is the release of a report nobody was able to read — the safety screen that vets an outside report before an agent starts on it was unable to run, so a second, independent judge reads it instead. The second is the approval of a fix plan when a written rubric says the plan is a small, contained, root-caused defect that touches nothing guarded. It also writes to the reporter twice: once, in plain English on their own ticket, when their fix lands, and again when a release carrying it ships.

It is deliberately narrow. A feature request is never approved. Anything touching database schema, authentication, money, billing, deletion, cloud deploys or a dependency always waits for you, as does any security, privacy or data-loss risk, any change to user-visible behaviour beyond restoring what was intended, any unconfirmed root cause, any workaround, and any change that is large or spans more than one subsystem. Every decision it makes is written onto the ticket with the rubric rule that made it, so a judgement can always be told apart from a bypass. Turning it off puts a person back in every step below.

Where to find it

Two switches, both in Settings → Lab, both on by default. Help Desk autopilot — customer notes (helpdeskAutopilotEnabled) governs the legs that write to a reporter; turning it off puts a person in front of every customer note. Fix confirmed bugs without asking (helpdeskPlanAutopilotEnabled) governs whether a confirmed, guarded-clearing bug's plan is approved without you; turning it off puts a person back in front of every plan. They are separate on purpose — one decides a fix, the other puts words in front of a customer — so turning customer notes off never silently stops plan approvals, and turning plan approval on can never send anything to a reporter.

What it acts on lives in the Help Desk itself: the moment a [Ticket] investigation stops and asks for a go-ahead on its plan, the hold the intake screen places on a report it could not read, and the ticket's own session, where each automatic decision is recorded as a message.

How it behaves

A held report can be released without you — but only one kind

Before an agent starts on an outside report, a cheap screen reads everything that agent will be given and checks it for prompt injection and dangerous requests. It holds what it flags or cannot check, and a held report normally waits for you.

The autopilot adds a second, independent judge for exactly one of those holds: the one that means nobody read the material — the screen's provider could not be reached, or its daily budget was spent. Everything else still waits for you, and each of those refusals is deliberate:

• a flag is a judge that was worried, and a second opinion that can soften a flag is a bypass;
• an unusable answer is reachable by the report itself — steer the screen into output it will not trust and you have chosen which judge reads you;
• an open breaker is the same trick at scale;
• anything unreadable or too long was never read completely.

And it is plain text only. The second judge reads text and cannot see pictures, so a report carrying any image or non-text attachment stays held no matter what it answers — otherwise spending the screen's budget would be a cheap way to get a report's pictures past a judge that cannot see them. A report the second judge releases starts with no person involved; one it is unsure about, or that it cannot answer on, waits exactly as before.

A plan can be approved without you

A [Ticket] investigation reads the customer's report, works out what is wrong, and proposes a plan — then it stops and asks for a go-ahead. Normally you answer that.

The autopilot answers it instead, but only when a written rubric says it may. Every rule is put to an independent decision model on every plan, and the first one that matches decides. Any HOLD rule beats the one rule that allows an autofix.

#	Rule
H1	It is a feature request, an enhancement, or a change in how something works — not a defect.	Hold
H2	It touches database schema or migrations, authentication or security, money or billing, data deletion, cloud deploys, or a dependency change.	Hold
H3	Any security, privacy or data-loss risk, of any size.	Hold
H4	It would change user-visible behaviour or wording beyond restoring what was clearly intended.	Hold
H5	The root cause is not confirmed, or the fix is a workaround.	Hold
H6	The change is large, or spans more than one subsystem.	Hold
H7	The request is ambiguous, or reads as a preference rather than a defect.	Hold
H8	The plan could not be read, judged, or answered on.	Hold
A1	A small, contained, root-caused defect restoring documented or obvious intended behaviour.	Autofix

Two things make this safe rather than merely convenient. Only a report filed as a defect is eligible at all — that is read from the record written when the report arrived, never from the investigation's own prose, because an agent that mistakes a request for a bug writes a plan that reads exactly like a fix. And a help-desk plan the autopilot declines never falls through to the broader auto-approve-everything setting, which is on by default in a developer setup.

Approving a plan is permission to proceed, not a verdict on the fix: the branch still owes a test that fails before the fix and passes after, and the normal land gate enforces that.

The reporter is told when their fix lands — and again when it ships

Two notes, one per milestone, each sent on the customer's own ticket thread through the same operator reply path a person's reply uses. There is no second send path.

Every note is written in the desk's one customer voice: short paragraphs, plain and specific, the reporter's own words for the problem, contractions, and a short bullet list where steps help. No em dashes, no stock support phrasing like "Great question" or "Thanks for reaching out", and the last line is always the sign-off The Omniscio support team. The same voice, and the same checks, cover the acknowledgement a support email gets and the replies the help desk's own AI drafts.

Before either note reaches a customer it must clear two local checks and a judge: one refuses any file path, commit hash, version number, internal id or internal name; another refuses anything that reads like a machine wrote it (a dash used as punctuation, a banned phrase, or a note that does not end with the exact sign-off line); and an independent rating judges accuracy, matching the evidence, and whether it reads like a person wrote it. A note that fails either local check, or that cannot be rated, is not sent. Nothing is ever sent twice for one milestone, even across a restart.

A finished fix is not a delivered one. While the fix has landed but no release carrying it has gone out, the note says only that it is fixed and that we will write again — never a version, never a date, and never "in the next update".

Seeing what it decided

Every automatic release, approval and reply writes a notable system message onto the ticket's own session with the rubric rule that made the decision, so you can always tell a judgement from a bypass later. Turn the switch off and the same tickets wait for you as before.

What this does not cover yet

• A held report the second judge could not answer is not retried on a schedule. It simply waits for you, exactly as it did before the autopilot existed.
• A note is not taken back if a fix is reverted after it was sent. A revert before the note goes out sends nothing, because the verdict is re-derived from the live branch each pass.
• Emailed reports are not covered by the second opinion. Their safety screen releases through its own path; this covers in-app, teammate, GitHub and Sentry reports.

Related

• Bug intake safety screen — what happens to an outside report before an agent starts on it.
• Help Desk email tickets — how support mail becomes a ticket.
• Start a session from a Help Desk ticket — the investigation this approves the plan for.