Pitchbar agents adapt to the kind of site they live on. When you set up an agent, the system can auto-detect whether you're running an e-commerce store, a documentation site, a SaaS product, a help center, a marketing site, or an internal knowledge base — and load a vertical preset tuned for that context.

What a preset changes

Each preset bundles four kinds of defaults:

System prompt fragment — appended to the LLM system prompt at every turn. Sits after retrieval data and before any custom system prompt you write, so your custom instructions always win.
Starter prompts — the chips visitors see on first open. Filled in for new agents; left alone if you've already curated your own list.
Launcher label — the call-to-action on the widget's closed orb (e.g. "Browse our shop", "Search docs").
Capabilities — a list of rich-UI affordances the widget reads on init. Phase 3 renderers ship today for product cards, pricing cards, case-study cards, and the escalation button (see resources/widget/src/ui/blocks.tsx); more renderers (code blocks, FAQ accordions, etc.) follow as the capability list grows.

The seven verticals

Slug	For sites that…	Capabilities (locked in this version)
`ecommerce`	Sell products. Pricing, stock, returns, shipping.	`product_card`, `price_inline`, `shipping_estimate`, `cart_handoff`, `order_status`, `ticket_escalation`
`documentation`	Publish technical docs, API references, SDK guides.	`code_block`, `api_reference_card`, `version_picker`, `troubleshoot_steps`, `ticket_escalation`
`saas`	Sell software with pricing, features, and signup.	`pricing_card`, `signup_handoff`, `feature_compare`, `account_status`, `ticket_escalation`
`help_center`	Run a public support / FAQ surface with article and ticket flows.	`ticket_escalation`, `kb_article_card`, `sentiment_routing`, `ticketing`
`marketing`	Capture leads, run case studies, do top-of-funnel content.	`lead_capture_inline`, `demo_booking`, `case_study_card`, `ticket_escalation`
`internal_kb`	Serve an employee wiki, runbooks, or compliance docs.	`policy_lookup`, `team_handoff`, `auth_aware`, `ticket_escalation`
`generic`	None of the above, or you'll configure everything yourself.	`ticket_escalation` only — every vertical exposes this so the LLM can always hand off to a human.

Auto-detection

During onboarding (after you paste your website URL) Pitchbar fetches the homepage, scores a handful of structured signals, and picks the highest-scoring vertical. The signals it weighs:

og:type meta tag (e.g. product, website, article)
JSON-LD @type values (Schema.org entities like Product, SoftwareApplication, FAQPage, TechArticle)
generator meta (Shopify, WooCommerce, Docusaurus, Mintlify, Zendesk, WordPress…)
URL path patterns (/products, /docs, /help, /api)
Hostname signals (app. / dashboard. subdomains for SaaS; .local / .internal for KB)
Presence of <article> tags and <pre><code> blocks

Each signal carries a weight; the highest-summing vertical wins. If no vertical clears a confidence floor of 0.25, the detector falls back to generic and asks you to pick manually.

Auto-detection is best-effort. JS-heavy SPAs that ship empty SSR HTML, or auth-walled hosts, fall back to generic — you can always pick a vertical manually from the radio cards.

Changing a vertical later

Open /app/agents/{id}/vertical from the agent's nav tiles. You can:

Re-detect if your site has changed (e.g. you added a Shopify storefront to a previously content-only site).
Pick a different vertical via the radio grid. If your customisations would be overwritten, a confirmation dialog explains exactly what gets replaced.

The system prompt fragment is runtime-applied — it isn't baked into the agent record, so changing the vertical instantly changes the prompt with no stale text. Capabilities are runtime too: the widget receives the live list on every /init call. Starter prompts and launcher label are merged into the agent record on apply, so you can edit them in Customize without losing your work next time you re-apply the same vertical.

Overriding capabilities

Each agent has an optional vertical_overrides JSON column. Set vertical_overrides.capabilities = [...] to replace the preset's capability list with your own. The widget reads the override; the LLM still sees the preset's system fragment so your overrides don't accidentally weaken the prompt contract.

Multi-tenancy & security

Both endpoints (POST /app/agents/{agent}/vertical/detect and POST /app/agents/{agent}/vertical/apply) are gated by AgentPolicy::update — only members of the agent's workspace can call them. Cross-workspace access returns 403. vertical_signals caches the most recent detection on the agent row so the admin UI can show "auto-detected on …" without re-fetching.

What's next

Phase 1 ships the data model, detection, presets, admin UX, and exposes capabilities to the widget. Phase 2 (tool / function calling) is partially shipped — the ToolRegistry in app/Services/Tools/ToolRegistry.php is wired, and the first tool (EscalateToHumanTool) ships gated to the ticket_escalation capability. Vertical-specific tools (product_lookup for e-commerce, etc.) follow as integrations land. Phase 3 (rich-message renderers in the widget) is partially shipped — resources/widget/src/ui/blocks.tsx renders product, pricing, case-study, and escalation blocks the LLM emits via inline-XML markers; additional renderers follow as we extend the capability list.