AI launch controls

Contents

In Sanity, open AI Assistant. Publish the settings to apply changes.

Launch without email submissions

  1. Under Tools & launch controls, leave Allow email / contact submissions off. To test an information-only launch on pre-prod Preview, also turn Allow submissions on staging only off.
  2. Leave the information tools and Build a personal agenda in chat enabled.
  3. Under Widget, enable Show AI on production when ready, then publish.

The production switch defaults off, including for existing settings documents where the field is missing. It gates both the widget and /api/ai/* endpoints. Local and preview widgets remain available. The read-only model-status endpoint remains available for Studio. AI_AGENT_ENABLED=false can force production off; true cannot override Sanity. Deploy the updated web app and Studio once to install these controls; subsequent published changes require no rebuild. The widget starts hidden until a fresh, uncached browser permission check succeeds, so cached HTML cannot enable it. Open tabs recheck every 30 seconds and on focus; request failures hide the widget. API access changes on the next request. An already-started response may finish; submissions recheck permission before sending.

Tool availability

The Tools tab exposes all 18 registered tools individually. Missing individual values mean enabled; an explicit off removes that tool. New unregistered tools fail closed until added to the shared registry. The master submission switch defaults off and takes precedence over both submission tools, subject to the separately configured pre-prod Preview permission:

pre-prod in Vercel Preview uses stagingEmailSubmissions === true; other environments use allowEmailSubmissions === true. The production visibility switch still applies independently and cannot be bypassed by the staging permission. The read-only eventFacts switch does not authorize contact submission. No published settings were changed during the October fix cycle.

Agenda email also requires agenda building. Disabling email delivery retains agenda building in chat but removes its email offer. Sales knowledge tools only retrieve information and may stay enabled independently of lead submission.

Enforcement

Published controls are fetched server-side without CDN or stale-cache fallback. Draft settings cannot enable production or submissions. Failed/invalid settings reads disable production and all tools. An absent settings document leaves production and submissions off, with information tools available locally/preview.

Before generation, the application filters the actual tool registry, ignores disabled active workflows, and bypasses their deterministic qualification/consent replies. Prompt lines referencing disabled tools and associated contact/agenda-email instructions are removed from the effective CMS/default/runtime prompt. Authoritative capability rules are appended; keep custom prompt instructions on separate lines to avoid removing unrelated instructions together. Tool descriptions are filtered too. Availability is enforced by code, not by trusting prompt compliance.

Immediately before either submission, the application re-reads published controls. If a switch changed during generation, the external request is not made and success is not claimed. Existing consent or an old conversation cannot bypass this check. A request already delivered before a switch changed cannot be recalled.

Validation

Regression tests cover production opt-in and emergency override, information-only launch, independent tool switches, agenda dependencies, prompt filtering, unknown-tool rejection, revocation before execution, hidden-production sends, and preserving rejected webhook outcomes. Existing workflow and streaming tests remain in the web suite. These checks do not send live enquiries.

The October fix record and current report separate local regression evidence from untested live deployment controls.