Between an AI that changes nothing and an AI that writes to customers there is a step most rollouts skip: the model produces a real, specific proposal, and a person decides how much of it becomes true. That is Assist. It is not a softer prompt or a lower temperature — it is a different permission set, where Ven may read a conversation and suggest structured changes but may not apply them and may not reply.
What Ven proposes, and how much of it you can take
A proposal arrives as three separable parts. Ven may suggest the catalog service the conversation is about, a set of qualification field values it extracted from what the customer wrote, and the next state the request should move to. Each is rendered as a before-and-after pair rather than as prose: the service currently on the request against the one Ven matched, the stored answer against the extracted one, the current status against the recommended one. Service matches and field values carry the model's confidence beside them, so a plausible-sounding guess and a near-certain reading do not look identical on screen.
The operator accepts them individually. Taking the extracted address while rejecting the service match is a normal outcome, and so is taking nothing at all. The review is recorded with a status of accepted, partially accepted, or rejected depending on how much of the candidate set was taken, and rejection is written down as completely as approval: which service was declined, which field keys were left behind, whether the recommended next action was refused. A review that only recorded agreement would leave the most useful signal — where the model is consistently wrong — invisible.
Stale proposals are refused, and accepted facts keep their provenance
A proposal is bound to the version of the request it was made against. Before anything is applied, the server checks that the active request is still the same one, that its version matches the version recorded when Ven produced the decision, and that the version the operator's screen was showing matches too. If a colleague corrected a value or the customer sent another message in between, the review is refused as stale rather than applied on top of work that has moved on. The next decision is cheap to produce; a silently overwritten correction is not.
Accepted answers keep their provenance. Each one stores the message it was extracted from, the model's confidence, and the operator who agreed to it — but it is explicitly not marked as confirmed by the customer, because nobody asked and nobody answered. Marking it otherwise would inflate every accuracy figure built on that column. For the same reason the answer is not locked against later change: agreeing with a suggestion is authorship, not an override, so a customer who later says something different should still win.
Reviewing twice does not apply twice
Reviewing the same decision twice does not apply it twice. The review is written under an idempotency key derived from the decision it reviews, so a repeated submission with the same selection returns the original result rather than creating a second one. A repeated submission with a different selection is refused as already reviewed instead of quietly replacing the first verdict — a double-click and a change of mind are different events, and only one of them should be resolvable by retrying.
A full audit trail, and a mode that never writes to the customer
Every review lands in the action audit as its own record: who reviewed it, which decision it responded to, the exact selection, the request version before and after, the accepted values with their previous ones, and everything declined. A durable event is enqueued in the same transaction for anything downstream. The customer-facing action on that record is always none, and that is the point of the mode — Assist is where a workspace learns whether Ven's readings deserve the wider permission that Qualify grants, and it learns it without a single wrong answer reaching a customer.
Run Assist as a measurement, not as a waiting room
Give the review queue a named owner and a response window before switching the mode on. Assist only produces value while proposals are being read; a queue nobody clears turns a safety step into a backlog, and the qualification it was meant to speed up gets done by hand anyway.
Reject deliberately rather than by leaving items untouched. A declined service match and an unreviewed one look similar in the inbox but not in the audit, and the rejected set is what tells you whether a template is asking for the wrong thing or a service description is too close to its neighbour.
Read the accumulated reviews before promoting to Qualify. What you want to see is a period where most proposals are accepted whole, where rejections cluster on one explainable service rather than scattering across all of them, and where stale-context refusals are rare enough that operators are clearly reviewing while conversations are still live.
Frequently asked question
What can Ven actually change in Assist mode?
Nothing on its own. In Assist, Ven records a structured proposal — a matched service, extracted qualification values, and a recommended next state — and an operator accepts or rejects each part individually. Accepted changes are applied in one transaction against the exact request version the proposal was made against, and the customer-facing action on every Assist review is none, so no reply reaches the customer from this mode.