The Pitchbar install's public marketing site (home page + any /marketing/* route) can host a real chat widget pointed at one of the install's published agents — not just the seeded demo sandbox. Configure it under Settings → Marketing → Marketing-site widget (super_admin only).

How it works

1. Toggle Enable widget on marketing pages. While off, the marketing site has no chat surface (default).
2. Pick an agent from the dropdown. The dropdown lists every published agent across every workspace on this install (super_admin can mount any agent).
3. Click Save marketing widget. The form sends only the widget toggle + agent id; the marketing home content editor is a separate sibling form on the same page and is unaffected. The widget mounts for anonymous visitors only — signed-in admins, customers, and platform admins never see it (would look like surveillance and pollute your own analytics with internal traffic).

Gate logic

The blade gate in resources/views/app.blade.php resolves the agent in this order:

1. AppSetting override — when marketing_widget_enabled = true AND marketing_widget_agent_id resolves to a published agent, that agent is mounted with no demo pill.
2. Explicit choice with invalid agent → no widget. When the toggle is ON but the selected agent is unpublished or deleted, the gate mounts nothing. It does not silently substitute the demo agent — that would surface a stranger's persona name on your marketing site (client report 2026-05-23).
3. DEMO env fallback — when the toggle was never enabled (default false) AND DEMO=true is set in the environment, the seeded MarketingDemoAgent mounts with the data-demo="true" attribute so visitors see a "DEMO" pill.
4. Nothing — no script tag emitted at all.

Agent name shown to visitors

The widget header label resolves with this fallback chain:

1. agent.persona.name — set in Agent → Customize → Persona → Display name. This is the visitor-facing persona; treat it as a stage name.
2. agent.name — the internal label set in Agent → Settings → Basics → Name. Used when the persona display name is empty, so an agent created through the dashboard ships with a sensible header without needing to also touch the persona form.
3. Localized literal AI assistant — last-resort fallback when both fields are empty (legacy seed data).

Toggle changes apply immediately

Saving Marketing → Marketing-site widget flushes the marketing.demo_agent_id cache (5-minute TTL) and the per-id marketing.demo_agent_id.explicit_valid.* cache (2-minute TTL) so the next marketing-page request reflects the change. Without the flush, toggling off could leave the demo widget visible for up to 5 minutes (client report 2026-05-23).

Open marketing tabs also pick up the change without a hard reload. The widget mount payload ships as the marketingWidget Inertia shared prop, and a small controller component (resources/js/components/marketing-widget-mount.tsx) reactively injects or tears down the widget <script> tag whenever the prop changes. Two trigger paths cover the common cases:

1. Same-tab navigation — any Inertia visit between marketing pages refreshes shared props; the controller's useEffect compares the new agent_id to the live DOM and remounts or removes the widget as needed.
2. Cross-tab focus — when a backgrounded marketing tab regains focus, the controller dispatches a router.reload({ only: ['marketingWidget'] }) partial reload so an admin toggling the widget in a sibling tab takes effect on the marketing tab without a manual refresh. Client report 2026-05-25.

CORS

The agent you pick must have your marketing site's origin (the APP_URL) in its allowed_origins. Saving the marketing widget with the agent picked auto-appends the current APP_URL to the agent's allowed_origins if it isn't already there — so the widget works the moment you save. Disabling the widget does not remove origins; you can safely toggle the widget off and back on without losing CORS configuration on the agent.