Site types & vertical presets

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.

A card's link must come from your sources. The presets give the model the card's shape with placeholders, never real-looking example values (card #859: an example price of 49.00 and a "Start free trial" button in the SaaS preset were copied into made-up plan cards), and a card whose link is a documentation example (example.com, .example, .invalid) — or isn't a link at all — is dropped before the visitor sees it; such links are also removed from the answer text. On a SaaS site the assistant lists only the plans your sources name, with their prices: a pricing card is shown only when its price is the first one your sources give after that plan's name, a plan price written in the answer text is checked the same way, and when a plan price doesn't check out the answer links your pricing page instead. If your pricing page was indexed before card #860, re-index it so the plan names and prices are in the knowledge base. On a marketing site the assistant moves visitors toward a meeting through the booking or contact page your sources give, or the lead form; it never books anything itself. When your sources describe custom, per-deployment or quote-based pricing, it says so and offers a quote instead of inventing tiers.

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.