c127. Guide Chat

Stage 1, captured 2026-10-29. Not kicked off: initial thoughts only, no plan yet. Raised in c125's mcp-guide thread, after the unscripted guide worked over MCP. That thread (in ../c125.operations-wizard/mcp-guide-plan.md) built a map of the dashboard, a knowledge layer, and tools that walk the person to the right place. The person's own agent drives those tools from outside the app. This cycle asks what changes when the agent sits inside the app as a chat window.

Mark's prompts (verbatim)

how would it work if we added a chat window in the web app?

let's add a new cycle for this and outline some of the initial thoughts, but don't build a plan yet

Where it comes from

c125's mcp-guide built these pieces, and a chat would assemble them (mode: assemblage):

• The app map (app/data/app-map.ts): 29 pages, their regions and rows, in customers' words. searchMap finds pages, regions and rows, and explain answers concepts.
• The knowledge layer (app/data/guide-knowledge.ts): every policy and its everyday words, each framework's requirements and the policies that cover them, and a glossary of 17 concepts.
• The walk (useTourApi, window.qpTour): find, explain, readPage, openPage (rings the way there first) and point (a ring and a short callout, TourMarker in TourFloat). The person's own moves are reported, so the guide follows them.
• The rules (server/api/tour/mcp.ts instructions): find, open, point with a title only, read, then answer; never press anything; mention a nearby second policy.
• The tour panel: it already splits the screen or floats (c125 tour layer). A chat could be another mode of the same panel.

Initial thoughts

The page runs its own tools. With the agent inside the app, the tab that asks is the tab that answers. The relay (/api/tour/channel, SSE), the tab IDs and the "which tab did the person use last" rule aren't needed. The chat calls window.qpTour directly.

One new server piece. A route (say /api/guide/chat) holds the API key, forwards one turn of the conversation to the model and streams it back. If the model asks for a tool, the page runs it and sends the result. The server keeps nothing between turns. find-in-app and explain already run on the server against the map and the knowledge layer.

One set of tool definitions. Move the tools and their wording out of server/api/tour/mcp.ts into a shared file (say app/data/guide-tools.ts), so the MCP guide and the chat can't drift apart.

What gets better than MCP:

• It knows where the person is. Each message can carry the current page and its regions, so "what's this?" and "why is this red?" work without the person describing the screen.
• It can suggest questions per page from the map's regions ("What does Mode do?" on a policy).
• The answer and the pointer sit together: the answer streams in the panel, and the ring and callout are on the page.

What it loses: the person's own context. An outside agent knows their code, their repos, what they were doing a minute ago; the chat knows only the dashboard. Keep both: the chat for most people, MCP for people who live in their own agent. Same tools underneath.

Safety stays as it is. The tools only read, navigate and point. Nothing presses, stages or publishes.

Open questions

1. Where it runs once deployed. The design site and demo.qpoint.io are static, so the chat works on the dev server only, as the relay does now. Deployed, it needs a small Cloudflare function. In qdash the route belongs in the qdash backend.
2. The key in the lab. The dev server needs an Anthropic API key. Shelling out to claude -p, as scripts/tour-guide-ask.mjs does, works but takes several seconds per answer.
3. Customer data. In the product, the chat sends what's on the dashboard (findings, people, policies) to a model provider. For an AI governance product, which provider and how that data is handled are product decisions, and Qpoint should govern its own chat under its own policies (dogfood).
4. Speed and model. Sonnet answers a typical question in a few seconds with three to six tool calls. Haiku may do for "where is it". Cache the instructions and the map.
5. Where the window sits. A mode of the tour panel, its own drawer, or a launcher on every page? How it shares the screen with a running tour.
6. Does it remember? One conversation per tab, or a history across pages and sessions.
7. What it can read. The map and the knowledge layer are fixed. Should it also read live numbers (open findings, spend today), or only what's on the screen?