Automatic decisions

Some things your workspace decides for you. Settings → Classifiers lists every one of them, what it decides, and a link to where that setting lives.

Each is a classifier, not a chatbot prompt: it’s asked a typed question — a yes/no, a choice from a fixed list, a score — and it answers with a confidence. That confidence is what makes the whole thing usable. A decision only takes effect once it passes a threshold; below it, nothing happens and the older rule takes over.

Which model answers is an implementation detail that will change. What each one decides is not, and that’s what the page lists.

What gets decided

Chat labels. Is this conversation Billing? A bug? One yes/no per label with an automatic rule. Applied while the conversation is open, after each visitor message, and again when it ends. See Labels and triage.

Chat review. When a conversation ends, six judgements plus a predicted star rating: was the issue resolved, was the bot consistent with its own tool results, were your rules followed, does a person need to follow up, is this a documentation gap, and how did the visitor feel. See Satisfaction and usage.

Message screening. Every visitor message is read before the bot answers, and the ones trying to talk the assistant out of its instructions are refused. This one runs in front of a reply rather than after it.

Ship a fix, or open a pull request. When a code agent’s change is approved, this reads the request and the files touched and decides whether it’s safe to commit straight to your base branch or wants a human review first. See Code agents.

Which repository a request means. When an agent covers several repos and your message names none of them, this picks the one you meant — or answers unknown and asks in the room rather than guessing.

How a decision is made

Three properties are worth understanding, because they explain most of the behaviour you’ll see:

It answers the question asked, and nothing else. A labelling pass is asked only “does this belong under Billing?” — it isn’t asked to summarize, judge or reply. Questions that can only be answered at the end of a conversation (“was the issue resolved?”) are only asked at the end; questions answerable from the first line (“is this about billing?”) are asked from the first line.

Every answer carries a confidence, and there’s a bar. A label is applied at 0.7 and above. Below the bar nothing is filed — not a guess, not a maybe.

A failure is never an error you have to deal with. If the model is unreachable, rate-limited, or answers nothing usable, the caller falls back to whatever it did before: the size rules decide how a change ships, the pattern-based screen still runs, no label is applied. Nothing breaks; it just stops deciding.

The rules that protect your decisions

A decision never overrides yours. If an automatic pass files a conversation under Billing and you remove that label, it does not come back — not on the next message, not when the chat closes. Nothing is ever un-filed automatically either. Adding is automatic; removing is always a person.

Some things are never put to a vote. Your code-agent settings can insist that certain paths always get a pull request — a database migration, say. That’s checked before the model is asked at all. An operator saying “a schema change always gets reviewed” isn’t a preference to be weighed.

You can see every call. Each decision writes a row you can read at Settings → Model calls: what it was for, which model answered, how long it took, what it cost, and what it was about. If a label looks wrong, the call that produced it is there.

Turning it off

Everything here degrades to the behaviour that came before it. Remove a label’s rule, or untick Apply this automatically, and that label becomes manual-only. Set your code-agent ship policy back to deciding by size and the model is no longer asked. There’s no all-or-nothing switch to find, because each decision is switched on where it’s configured.