NLWeb Knowledge Assistant — Enable, Evaluate, Publish

Audience: Customer Success Managers

Overview

Knowledge Assistant is Schema App's product that turns a customer's Content Knowledge Graph (CKG) into a queryable platform. It is powered by NLWeb — the underlying technology that serves both a conversational experience for human users and agent endpoints (MCP, WebMCP) for AI tools and agents. It synthesizes grounded answers from the customer's structured data and provides source citations with every response.

Knowledge Assistant enables three deployment surfaces:

In-app access: https://app.schemaapp.com/knowledge-assistant

This document covers how to enable Knowledge Assistant for a customer, what they should test across all three surfaces, and how to determine readiness for public deployment.

Naming convention: "Knowledge Assistant" is the customer-facing product name. "NLWeb" refers to the underlying open-source technology and infrastructure. Internal references (GitHub issues, deployment pipelines, tenant provisioning) use "NLWeb."

Customer-facing resources (share with eval accounts)

• Knowledge Assistant — Evaluation Release Guide — customer-facing written guide: access, test scenarios, troubleshooting, MCP/WebMCP overview

• Knowledge Assistant — Product Walkthrough (Evaluation Release) — ~7-minute video walkthrough (cross-site synthesis, FAQ rich results, contact routing)

Send both links when enabling evaluation access. This internal article is the CSM playbook; the two articles above are what customers should read.

Prerequisites

• Customer has an active Schema App account with published schema markup

• Customer's Content Knowledge Graph has been populated (markup is deployed and crawled or loaded via S3)

• Customer has been selected for the Knowledge Assistant Evaluation Release

• NLWeb tenant has been provisioned — either manually by Engineering (current) or via trial activation in admin editor (planned, see "Enabling Knowledge Assistant" below)

Enabling Knowledge Assistant for a Customer

Current Process (Manual — Interim)

Provisioning a new NLWeb tenant is currently a manual process handled by Engineering. The automated pipeline template (#22145) and multi-tenant deployment pipeline (#22257) have not yet been completed.

To request provisioning today:

1. Confirm the customer meets the prerequisites above.

2. Open a request to Engineering (Joel Cummings) with:

   • Customer name and Schema App account/site ID(s)

   • Which accounts (websites) should be queryable

   • Any tenant-specific configuration needs

3. Engineering provisions the tenant using the existing infrastructure and AppConfig-based configuration (#22256 — completed).

4. Engineering confirms provisioning is complete and the NLWeb endpoint is active for that tenant.

Planned Activation Architecture (In Development)

The manual provisioning process above is being replaced by a self-service activation model with two new capabilities:

1. Trial Activation via Admin Editor (#23115)

• A new ProductSpecification entity (with a product SKU) will represent the NLWeb product

• The ProductSpecification is attached to a custom Offer, which connects to the customer's Obligation (account/subscription)

• CSMs or admins activate a 90-day free trial through the admin editor view report interface, using existing Entity Hub UI patterns

• No HubSpot integration required for the trial path — trial management is handled outside HubSpot initially

2. Automated Deployment Trigger (#23116)

• A GraphWrangler event subscription listens for NLWeb ProductSpecification creation/save events

• On trigger, the NLWeb deployment pipeline automatically provisions the tenant's stack

• Supports both admin manual entry and future HubSpot automated flows as event sources

• Eliminates the need for Engineering to manually provision each tenant

Future paid state: HubSpot contract integration with line items will enable paid activation via background triggers (Neptune streams or graph wrangler events). Pricing structure (multiple SKUs) is TBD — Schema App is covering all API token costs during the trial/evaluation phase. High-traffic sites may create significant usage; token cost monitoring will be established before scaling.

Data Ingestion

Customer Knowledge Graph data is loaded into NLWeb via one of two methods:

• Crawler — for sites with server-side rendered markup

• S3 import — for customers whose markup is generated by Schema App and stored in S3 (most Schema App customers). This was enabled by #22686.

[VERIFY] Confirm whether data ingestion runs automatically after tenant provisioning or requires a separate trigger.

How Customers Use Knowledge Assistant

Conversational UI

Once provisioned, the customer logs into Schema App and navigates to:

https://app.schemaapp.com/knowledge-assistant

No additional setup is required on the customer side.

Data scope — customers can choose which content Knowledge Assistant queries:

Multi-account mode is useful for organizations managing multiple domains or brands. Responses may synthesize information from multiple sites when using "All Accounts."

Summarize Mode — Knowledge Assistant operates in Summarize Mode by default:

• Each response synthesizes information from the customer's Knowledge Graph

• Multiple supporting citations are included

• Responses draw only from the customer's own structured content

• Customers can click citations to review source documents

This approach reduces hallucination risk and ensures responses are grounded in the customer's authoritative content.

Conversation memory — history persists between visits (stored in browser localStorage). Memory is not stored server-side. Clearing browser cache or using the Clear History button resets the conversation. Memory is scoped to the individual user's browser session.

Agent Endpoints (MCP / WebMCP)

In addition to the conversational UI, each NLWeb tenant exposes agent endpoints that allow AI tools and agents to query the customer's Knowledge Graph programmatically.

MCP (Model Context Protocol) — a structured API that AI agents, copilots, and LLM-powered tools can connect to. This allows the customer's Knowledge Graph to be a data source for any MCP-compatible agent. https://modelcontextprotocol.io/

WebMCP — a web-based variant of MCP designed for browser-based agent interactions, enabling web agents and browser extensions to query the Knowledge Graph directly. https://webmcp.dev/

These endpoints mean Knowledge Assistant is not just a chatbot — it is the infrastructure that makes a customer's structured data agent-ready. The conversational UI is one consumer of that infrastructure; MCP and WebMCP are others.

Common Pre-Sales and Implementation Questions

Audience: CSMs answering customer technical questions during evaluation and hosted-deployment scoping. Share the substance with customers in your own words; this section is the internal playbook.

Can Knowledge Assistant be chat and site search?

Yes in intent: the conversational UI is a natural-language interface over the customer's Content Knowledge Graph. Customers often frame that as replacing a chatbot or improving site search — both are valid use cases for the same surface.

• What to say: Knowledge Assistant is grounded Q&A with citations, not a keyword search index. It can sit where chat or search UI lives today, but answers come from structured markup, not a full-text crawl of every page string.

• Positioning tip: Prefer "conversational search over your structured content" over promising a drop-in replacement for every HubSpot/chat or search feature (tickets, live agent handoff, lexical site search, etc.).

Can they test on their own preview / staging site (without adding Schema App users)?

Yes. Prefer this when the customer wants broader internal review than Schema App logins allow.

• Engineering can provide an embeddable JavaScript snippet for a hosted Knowledge Assistant experience on a customer-controlled preview or staging URL.

• CORS must be enabled for the customer's preview/staging domain before the embed will work.

• Coordinate with Engineering (widget/embed + domain allowlisting). Customer does not need every tester added as a Schema App user for this path.

• What to say: "We can put a preview embed on your staging site so your team can test there. We'll need your staging domain(s) for CORS allowlisting."

Does changing schema deployment (head code, GTM, server-side GTM) affect Knowledge Assistant?

No. Schema deployment method controls how markup is delivered on the website. Knowledge Assistant indexes the customer's published structured data (via crawler or S3 import, per tenant). Changing head code ↔ GTM ↔ server-side GTM does not change the Knowledge Assistant product surface or require a separate NLWeb redeploy.

• Indirect effect only: If a deployment change breaks or delays markup publish/crawl, answers can look stale or thin until ingestion catches up — same as any markup freshness issue.

• Should they switch to server-side GTM? That is an SEO/performance/ops decision about schema delivery, not a Knowledge Assistant requirement. Happy to advise separately; do not frame it as required for Knowledge Assistant.

• What to say: "How you deploy schema (head snippet vs GTM vs server-side GTM) does not change Knowledge Assistant itself. We care that markup is published and ingested; the delivery pipe is independent."

What to Test During Evaluation

Guide customers through these test scenarios to properly evaluate their Knowledge Graph's readiness — both for the conversational UI and for agent consumption via MCP/WebMCP.

Conversational UI Tests

1. Core Product or Service Topics

Ask Knowledge Assistant to summarize main offerings and evaluate:

• Accuracy — are the facts correct?

• Completeness — are key details present?

• Citation quality — do sources link to the right pages?

Example: "Summarize your enterprise analytics platform."

2. Comparison Questions

Test cross-entity synthesis across products, services, or locations:

Example: "Compare Product A and Product B."

Look for structured comparison, multiple citations, and clear differentiation.

3. Cross-Site Queries (Multi-Account Customers)

If the customer has multiple accounts enabled, test aggregation:

Example: "Summarize your healthcare initiatives across all brands."

4. Coverage Gap Discovery

Ask about topics that may not be fully marked up:

Example: "What can you tell me about [niche topic the customer hasn't prioritized for markup]?"

Thin or incomplete responses typically indicate:

• Schema coverage gaps

• Outdated markup

• Content not yet modeled in the Knowledge Graph

These findings are valuable — they show the customer exactly where to invest in markup improvements before any public deployment.

Agent Endpoint Tests

If the customer plans to expose their Knowledge Graph via MCP or WebMCP:

5. MCP connectivity — connect an MCP-compatible client (e.g., Claude, Cursor, or a custom agent) to the tenant's MCP endpoint and issue queries. Verify that responses return structured, citation-backed results.

6. Agent-appropriate responses — agent consumers need concise, structured data rather than conversational prose. Test whether the endpoint returns results that an agent can parse and act on (e.g., entity lists, factual summaries with source URLs).

7. Scope and access control — confirm the agent endpoint respects the same data scope (single account vs. all accounts) and that no data leaks across tenant boundaries.

Success Criteria

Use the following criteria to assess whether a customer's Knowledge Assistant evaluation is successful and whether they are ready to discuss public deployment.

Evaluation Success — Conversational UI

Evaluation Success — Agent Endpoints (if applicable)

Coverage Gap Assessment

Readiness for Public Deployment

A customer is ready to discuss public deployment when:

1. Core topics pass — primary products/services return accurate, well-cited answers

2. Coverage gaps are identified and addressed — or the customer accepts the current scope

3. Stakeholder confidence — the customer's team has tested and is satisfied with response quality

4. Use case is defined — the customer has a clear plan for which surfaces to deploy:

   • Conversational UI — where on their site (e.g., support page, product finder, homepage widget)

   • MCP endpoint — which AI agents or tools will consume it (e.g., internal copilot, partner integrations)

   • WebMCP endpoint — which web-based agents will connect

What the Evaluation Release Does NOT Include

Set expectations with customers — the following capabilities are not part of the current in-app evaluation:

• Admin dashboards or usage analytics

• Booking or action workflows

• CRM integrations

• Advanced guardrails for regulated PII workflows

• OAuth sign-in for end users

• Public-site hardening (security review, SLA, branding)

• Drop-in replacement for CMS/HubSpot site search or chat widgets (hosted embed is scoped separately; HubSpot needs Engineering review)

• Customer staging/preview embed without Engineering CORS / domain allowlisting

If a customer requires any of these for their deployment, escalate to the CSM lead and Engineering to discuss roadmap and scoping.

When a Customer Wants to Go Public

If a customer decides to deploy Knowledge Assistant publicly (on their website, via agent endpoints, or both), the following additional steps apply:

Public deployment follows a separate scoping process from the in-app evaluation. The customer must meet the minimum requirements below before scoping begins.

Minimum Requirements for Public Deployment Scoping

Scoping Process

1. CSM initiates — CSM opens a public deployment scoping request with the requirements above filled in

2. Engineering + Product review — scope UI branding, security hardening, SLA commitments, guardrail configuration, and deployment infrastructure

3. Statement of work — deliverables, timeline, and any incremental costs are documented and approved by the customer

4. Deployment & validation — Engineering deploys, customer validates in staging, then go-live

Troubleshooting

Security & Data Handling

• Knowledge Assistant operates within Schema App's secure, tenant-isolated infrastructure

• Logs are retained per account

• Conversation memory is client-side only (browser localStorage)

• Knowledge Assistant synthesizes responses strictly from the customer's structured Knowledge Graph

• No customer data crosses tenant boundaries

For customers evaluating NLWeb in regulated environments, coordinate with the CSM lead to review security and compliance requirements.

References

• Customer-facing — Evaluation Release Guide: Knowledge Assistant — Evaluation Release Guide

• Customer-facing — Product walkthrough: Knowledge Assistant — Product Walkthrough (Evaluation Release)

• Internal CSM playbook: NLWeb Knowledge Assistant — Enable, Evaluate, Publish (this article)

• GitHub — Trial activation / ProductSpecification (#23115): SchemaApp/SchemaApp#23115 (open)

• GitHub — GraphWrangler deployment trigger (#23116): SchemaApp/SchemaApp#23116 (open)

• GitHub — Pipeline template (#22145): SchemaApp/SchemaApp#22145 (open)

• GitHub — Multi-tenant deployment (#22257): SchemaApp/SchemaApp#22257 (open)

• GitHub — AppConfig for tenant config (#22256): SchemaApp/SchemaApp#22256 (completed)

• GitHub — S3 data ingestion (#22686): SchemaApp/SchemaApp#22686 (completed)

• Google Drive — NLWeb Healthcare Launch Priority: doc

• Google Drive — NLWeb Core Concept & Value Proposition: doc

• Google Drive — NLWeb Q2 FY2026 Planning Revisions: doc

• Repo (NLWeb codebase): SchemaApp/SchemaAppNLWeb

• Meeting notes — Activation architecture (2026-03-06): Granola transcript