B Blengi docs

Build your agent

Smart Segments

Smart Segments split one agent's knowledge into named areas β€” Products, Support, Docs β€” routed by the page the visitor is chatting from. A visitor on /products/… gets product answers first; a visitor in your help center gets support answers first. The rest of the knowledge base stays reachable: segments prioritize, they never wall off.

How a conversation gets its segment

  1. The visitor opens the chat on some page. The page's URL path is matched against every segment's path list β€” the most specific (longest) match wins; unmatched pages go to the default segment.
  2. The winning segment is stored on the conversation once, at creation. Navigating to other pages mid-conversation never re-routes it β€” context stays stable for the whole chat.
  3. Every answer first searches the conversation's segment. If nothing clears the agent's confidence threshold there, the agent automatically runs one fallback pass across all segments (with a small preference for the home segment on near-ties) before giving up.
  4. Only when the whole knowledge base has no grounded answer does Strict Knowledge Mode defer β€” a segment miss alone never triggers the fallback message.
No fallback chains, by design
There is exactly one fallback: segment β†’ everything. Configurable "try segment B, then C, then D" chains multiply the ways retrieval can silently do the wrong thing, so they don't exist. Every cross-segment fallback is recorded on the turn's trace, so you can see how often visitors needed knowledge from outside their segment.

URL path patterns

  • Patterns match the URL path only β€” query strings and #fragments are ignored; matching is case-insensitive.
  • A path matches itself and everything under it: /products also covers /products/red-pen, but never /products-old (boundaries are respected).
  • A trailing /* is accepted as the same section match: /docs/* ≑ /docs.
  • * alone matches every page β€” useful as an explicit catch-all on a non-default segment.
  • The longest matching pattern wins across all segments: with /products (Products) and /products/manuals (Docs), a visitor on /products/manuals/v2 lands in Docs.

Setting it up

  1. Open your agent β†’ Smart Segments and add segments. The first one you create becomes the default (you can move the star later). Give each segment the URL paths that should route into it; the default usually needs none.
  2. On the Sources page, assign each knowledge source to a segment with the per-row picker. Assignment is instant β€” membership lives in the database, so no re-crawl or re-index happens when you move a source.
  3. Sources you never assign behave as default-segment knowledge, so an agent that predates segments keeps answering exactly as before.
  4. Prefer moving an existing source with the per-row picker over re-adding the same URL. If you do add a page that another source already indexed (a common one: a page the Auto-indexed from visitors source grabbed first), the new source now crawls its own copy so it can be scoped to your segment β€” it won't show up empty. Reindex the source if it was added before this behavior shipped.
  5. Rehearse in the Playground: the Scenario tab gets a Knowledge segment override so you can ask "what would a /products visitor get?" without opening the live site. The Diagnostics tab shows whether the reply came from the home segment or via the fallback.

Category chrome β€” persona, starter questions, greeting

Each segment can present itself as a category specialist. All fields live in the segment's editor on the Smart Segments page and are optional β€” an empty field inherits the agent-level value, so a segment with no chrome behaves exactly like the plain agent.

  • Starter questions β€” the suggestion chips a fresh conversation shows. A Products visitor can see "Which sizes do you have?" while a Support visitor sees "How do I cancel?".
  • Persona name + avatar β€” "Jordin, the TV specialist" in the panel header and launcher for this segment's conversations.
  • Greeting bubble β€” a small, dismissible speech bubble that invites the visitor ("Hi, I'm Jordin β€” can I help?"). Shows once per conversation after a short delay; a dismissal is remembered, so it never nags.
  • Disclaimer β€” every chat panel carries a one-line "can occasionally be wrong, like a human" notice. Hide or reword it per agent via theme.disclaimer (false or a custom string).

Inline embed block

Besides the floating bar, you can place a chat invite inside page content β€” e.g. halfway down a category page. Add an empty container anywhere in the page's HTML:

<div data-pitchbar-inline></div>

The widget renders a compact card there (persona, greeting, starter chips, input). Clicking a chip or the input opens the main chat with that question β€” one conversation, no matter how many blocks the page hosts.

Product context β€” "ask about this product"

On product pages there is no segment per product (a shop has thousands). Instead the widget reads the page's Schema.org Product JSON-LD β€” which WooCommerce, Shopify themes, and most shop platforms emit by default β€” and sends name, price, availability, SKU, and brand to the backend with each message. The prompt then carries a "Current product" block, so "does this fit a 15-inch laptop?" is answered about that product.

  • Visitors on a detected product page get an "Ask about this product" chip as the first suggestion.
  • Product fields are whitelisted and length-capped server-side, and injected as data β€” page content can never override the assistant's instructions.
  • Rehearse it in the Playground: pick the Shopify product page template on the Page-context tab (or paste your own JSON-LD).

Per-segment behavior β€” instructions, threshold, leads, workflows

  • Category instructions β€” extra system-prompt text for this segment only ("You are the storage specialist; always mention unit sizes"). Appended after the agent's own instructions; it can never override the grounding rules or Strict Mode.
  • Confidence threshold override β€” a stricter or looser retrieval gate per segment. Empty inherits the agent's threshold.
  • Lead capture β€” per segment: inherit, ask for contact details as usual, or never ask (e.g. a support portal where a lead form feels wrong).
  • Workflows per segment β€” on the workflow editor, scope a flow to one segment: it then only fires for conversations routed to that category. Unscoped workflows keep firing everywhere.
  • Analytics & alerts β€” the Conversations list shows a segment badge per conversation, and new-lead emails name the segment the lead came from.

What segments do NOT change

  • Curated answers, workflows, and the human-handoff / booking shortcuts run before retrieval and ignore segments entirely.
  • The widget embed is unchanged β€” routing happens server-side from the page URL the widget already reports. Nothing to re-install.
  • Agents with zero segments behave byte-identically to before the feature existed.
  • Deleting a segment re-points its sources at the default segment (deleting the last one turns the feature off); conversations pinned to it simply fall back to whole-knowledge-base retrieval.
Sticky once the chat starts
The segment locks the moment the visitor sends their first message. Before that β€” while the chat panel is still empty β€” it follows the current page, so a visitor who opens the widget on your homepage and then clicks into /products picks up the Products starter questions, greeting and persona. Once they’ve actually asked something, a wander from /products to /support keeps the Products context they started in (retrieval never re-scopes mid-chat). If they return after 24 hours of inactivity, a fresh conversation β€” and fresh routing β€” begins.

Plans

The per-plan Smart Segments per agent limit controls the feature: blank means unlimited, 0 hides it, a number caps how many segments each agent may define. Platform admins set it under Admin β†’ Plans.