A team chatbot beside the onboarding notes

Daily workEN2026-10-26

Start with a question your team answers repeatedly: where to request access, who owns a service, or which onboarding checklist is current. This walkthrough builds a small internal chatbot around approved notes, a server-side endpoint, and a simple chat page. Keep the first version read-only. Its job is to help colleagues find an answer, not change company systems.

§ Step 1: Choose one useful boundary

Use onboarding as the initial scope. Gather a small set of documents that every pilot participant may read. Leave out private personnel records, credentials, customer data, and anything whose sharing permissions are unclear.

Write down the acceptance rule before building: an answer should identify its supporting document, or say that the supplied notes do not contain the answer. Assign one person to maintain the source collection.

§ Step 2: Connect the backend to Vana API

Create a Vana API account and obtain a key for the application. Use the OpenAI-compatible interface for this walkthrough, with the /v1 base path and the official OpenAI SDK. Vana API documents this path for OpenAI-style clients; its other protocol interfaces are not needed here. ([vanaapi.com](https://vanaapi.com/))

Choose Gemini 3.1 Pro for the first implementation, using the exact API model identifier shown in your account rather than guessing it from the display name. Keep that identifier in a server-side configuration variable so you can change it without editing the chat interface.

Load the API key from an environment variable or secret manager on the server. Never put it in browser JavaScript, a public repository, or a frontend build variable. The browser should contact your backend, which makes the authenticated model request. ([developers.openai.com](https://developers.openai.com/api/reference/overview?utm_source=openai))

§ Step 3: Build one narrow chat route

Add a POST /chat route to your existing internal application. Accept a message and a conversation identifier. Require company sign-in, validate the message length, and reject requests from users outside the pilot group.

Inside the route, load the approved context, assemble the model request, and return the answer with source titles. Begin with ordinary request-and-response handling rather than streaming. Set a timeout and return a clear temporary-error message when the upstream request fails.

Keep recent conversation history on the server, scoped to the signed-in user. Add a visible reset control. For this pilot, retain only the turns needed for follow-up questions rather than preserving every conversation indefinitely.

§ Step 4: Supply a small amount of evidence

For a short handbook, begin with a curated context bundle. Once that becomes unwieldy, split documents by heading and retrieve a few relevant sections for each question. Preserve the document title, section heading, revision date, and an internal source identifier alongside each excerpt.

Apply access checks before selecting excerpts, not after generating an answer. Only send material that the requesting employee is allowed to read. Confirm your organization's approval for sending that material through the relay and upstream provider.

Keep application instructions separate from retrieved text. Treat document contents as untrusted reference material, not commands: a document can contain instructions designed to redirect a model. Prompt wording is one defensive layer, not a substitute for backend permissions. ([developers.openai.com](https://developers.openai.com/api/docs/guides/agent-builder-safety?trk=article-ssr-frontend-pulse_little-text-block&utm_source=openai))

§ Step 5: Make uncertainty visible

Give the assistant a short instruction: answer from the supplied notes, identify supporting source identifiers, and state when evidence is missing or contradictory. Ask for concise answers and a relevant document title, not invented policy details.

Before rendering sources, verify that every returned identifier belongs to the excerpts supplied for that request. Display source titles as plain text beneath the answer. Do not describe an answer as verified merely because it includes a citation.

§ Step 6: Test before widening access

Ask questions with clear answers and compare them with the source text.
Ask an unanswered question and check that the bot acknowledges the gap.
Test a restricted document and confirm that its contents never enter the request.
Include an excerpt that tells the assistant to ignore its instructions.
Check timeouts, repeated submissions, conversation isolation, and reset behavior.

Record latency, token usage when returned, and failure categories. Avoid logging full prompts or sensitive document contents by default; SDK diagnostics can contain sensitive data and need careful redaction. ([github.com](https://github.com/openai/openai-node/blob/main/.github/CONTRIBUTING.md?utm_source=openai))

Launch with a handful of colleagues and review missed questions with the document owner. Expand the source collection only when the small version consistently answers its original questions. A useful first release is a modest interface to reliable notes, with clear limits and someone responsible for keeping them current.