AI assistant editor operations

Index

This guide covers the 2 October AI fixes, the controls for editors, and the work needed when an event ends. The code changes described here are local until the web app and Studio are deployed. No published Sanity settings or production model configuration were changed during this work.

October fix record and evidence

Updated 5 October: the complete fix record and report document final local changes and test results. No October application fixes have been deployed; no Sanity documents were edited in this cycle. Five published Paris pages were refreshed into 22 vectors through the existing pipeline.

Editors should maintain the approved page/FAQ, then refresh its existing Pinecone namespace. Do not change retrieval sources to hide a stale or missing source. Sponsor names need public text/reference labels or explicit alt text; image filenames are not an approved roster. Volunteer guidance, complete sponsor names, the intended Miami speaker destination and a decision-maker statistic remain content actions. Current structured ticket prices replace historical test constants.

The registry now has 18 tools, including read-only eventFacts. It covers narrow policies and startup/Award distinctions without permitting submissions. Seven mechanical FAQ update/delete checks and four final removed-fact response probes passed, but sustained Sanity publish-to-answer timing and configured webhook filters still need operational verification.

Agenda, session and topic browsing should answer the visitor’s question and offer to create a personalised agenda. Accepting that offer starts pillar selection when interests are unknown. A supplied pillar goes straight to the validated planner. Browsing alone does not start contact collection.

Agenda email qualification uses short questions: “What company are you with?”, “What is your job role?”, “What name should I use?” and “What work email address should I use?”. Literal answers to those questions, including the company UNLEASH, are retained before model extraction. Personal email addresses are rejected using the forms’ validator.

Ticket enquiries, sponsorship enquiries and agenda emails now use the three purpose-specific privacy and Terms & Conditions messages supplied by the team. Existing conversations using the previous confirmation question can still complete after deployment.

In Sanity, open AI Assistant Settings → Lead capture → Privacy and consent notices. Ticket enquiries, sponsorship enquiries, and agenda emails each have their own editable notice. Markdown links let each notice point to the appropriate privacy policy and terms. Blank values use the supplied approved wording, visible in Studio as the built-in default. Publish the settings and allow up to 60 seconds for the server cache to refresh.

The final “Shall I …?” confirmation question is added automatically and stays fixed so editing the legal notice cannot break consent detection. Do not add a different confirmation question to the notice. The old shared Consent Statement field no longer controls submissions. This configures the notices and their links; it does not create or edit the linked policy pages. These settings require deployment of both the updated Studio and web application.

consent: true means the visitor authorised this particular enquiry or agenda email. It does not mean permission for unrelated marketing.

opt_in: false means no separate marketing opt-in was recorded. Previously only agenda emails included that property; ticket and sponsorship lead payloads now also include opt_in: false for consistency. Do not use opt_in to decide whether to send an agenda that the visitor requested. Use the submission type and consent for that transaction. This change does not add a newsletter signup flow.

Agenda payloads retain the existing Markdown agenda field and add agenda_html. Map agenda_html to the email provider’s HTML body in Zapier. It contains paragraph tags, escaped text, clickable titles and absolute HTTPS links to unleash.ai. The existing field remains available for old mappings. Changing the application payload does not automatically change the Zapier/Postmark template mapping.

Changing models

Use AI Assistant Settings → Models in Sanity for routine model changes. The three tasks are Concierge, Agenda and Profile extraction. Publish the settings; the app refreshes them within approximately 60 seconds. Inspect /api/ai/models on the environment being tested to see effective IDs and whether each comes from an environment override, Sanity or the built-in default.

Task-specific environment variables AI_MODEL_CONCIERGE, AI_MODEL_AGENDA and AI_MODEL_PROFILE override Sanity. Avoid changing the shared published Sanity model merely to run a staging experiment: those settings can affect production too. Use preview-scoped environment overrides when testing on staging. AI_GATEWAY_MODEL is a legacy concierge fallback below a populated Sanity setting.

The Agenda setting previously existed in Studio but the main route always selected the Concierge model. It now selects the Agenda model for agenda workflow turns. Session selection and conflict checking remain deterministic server code; the model does not create a second unchecked schedule.

An Anthropic development preset is included:

cd apps/web
bun run dev:ai:anthropic

It uses anthropic/claude-sonnet-4.6 for Concierge and Agenda through the existing Vercel AI Gateway credentials, leaving Profile extraction unchanged. This model ID was verified against the live gateway catalogue and exercised through real application flows. No new Anthropic key is required for this gateway route. Stop that process and use the normal development command to restore the normal model settings.

For a speed/quality comparison, replay identical prompts with the same content, profile and tool settings. The E2E runner records profile-extraction and complete-chat duration separately. Those measurements include retrieval and tool calls; they are not pure model latency. A single successful Claude run does not establish that it is faster or better than the current model.

Showing the agent on pages

After deploying the updated Studio and web app:

Editor action Control
Show the agent without a section prompt Open the page’s AI tab, set Show AI assistant → Show on this page, and publish.
Hide it on one page Set Hide on this page. This overrides section prompts and category defaults.
Show or hide it on the homepage AI Assistant Settings → Widget → Where to show the assistant → Homepage.
Show or hide it across editorial pages Use Editorial pages in the same group. Individual editorial documents also have the page override.
Show or hide it across every Paris event page Use All Paris event pages.
Show or hide it across every Miami event page Use All Miami event pages.

Unset/inherit preserves existing behavior. A page-specific setting wins over its category default. Publish and refresh the visitor page. Global production visibility and the visitor’s functional-cookie consent still apply; a page setting cannot bypass them. These are display controls, not tool/data-retention controls.

After an event

Do not clear the whole Pinecone database. It also contains editorial, FAQ and other-event material. Hiding the widget or unpublishing a web page does not itself retire the stored event data.

The current agenda tools read sessions and links from Pinecone and cache them for up to ten minutes. They do not check the live publication status of each linked page, and the planner does not impose an event-end cutoff. Therefore taking an agenda page offline alone is insufficient: stored sessions can still be recommended. An empty ingestion result also does not reliably clear old vectors. The nightly refresh still fetches both event agendas from Inwink, so manually clearing an agenda store without retiring its ingestion can repopulate it.

For event shutdown:

  1. Disable agenda building/email and the affected agenda search/lookup tools in Tools & launch controls before removing pages. The current tool switches are global, so a switch may affect both events; a separate per-event lifecycle control is still needed for selective retirement.
  2. Retire the old event’s ingestion configuration and automatic refresh path, then remove/replace only that edition’s agenda records and stale event/FAQ content. Wait for cache expiry or invalidate caches and verify fresh and existing conversations.
  3. Update the published event dates, pages, badge mappings and factual content for the next edition. Do not rely on changing the city/event title to rescope old data.
  4. Re-enable tools only after the new edition’s sources and links have been verified.

Ticket prices and Swapcard

The live-price resolver checks each product’s start/end availability on every read, including cached products. Expired bands are not quoted as current; overlapping bands fail closed. However, an open-ended product remains active, and a reused old Inwink event/product mapping does not automatically become the next edition. Remove or replace old mappings and expire old products during event rollover. The implementation currently has no additional event-end cutoff for those products.

Agenda ingestion and live product pricing are still Inwink-specific. Moving to Swapcard requires separate adapters for session ingestion and ticket/product pricing, or another verified published pricing source. Preserve the agenda contract (edition identity, start/end time, room, speakers, access, five pillar IDs and canonical public URLs), retire the old Inwink refresh, and populate the new source before enabling recommendations. If no replacement source is ready, keep the affected tools off and answer that the next agenda/prices are not yet available.