Adding an AI Assistant: Design, Costs and Connections

The idea in one sentence: an optional AI assistant needs clear boundaries around what it can know, say and do—and a useful route when it cannot help.

This paper describes a proposed design, not a catalog of shipped integrations or an assurance of regulatory compliance. The workshop example needs no AI model. Waypost's answer helper uses scripted replies; it does not demonstrate the quality or cost of a live model.

First decide whether a conversation helps

A clearer page, search result or form may answer a question faster than a chat window. Do not add an assistant because the website is being called “aware.” Identify the task it should help with and the ordinary alternative.

Here, an assistant is software that answers a person's questions. An agent may also use tools or take actions. The distinction matters: explaining how to book a meeting is different from actually booking it.

A large language model (LLM) generates responses from text and other inputs. It can produce a convincing wrong answer. Connecting it to company information does not remove that risk.

Separate the website's decisions from the answer service

The platform is the software coordinating the experience. The model service produces an answer. A backend is the server-side part that supports the interface a visitor sees.

Keep their responsibilities explicit:

Do not send the person's complete browsing history by default. A question and the current page may be enough. Keep a person's stated need separate from a system's guess about that need.

Automatic invitations and learning when to display them are advanced proposals, not prerequisites or capabilities established by the examples on this site. If you offer help proactively, explain the offer, allow dismissal and keep the original task accessible.

Four implementation options—not a required ladder

These options describe different responsibilities. They are not current product tiers or price commitments, and the fourth is not automatically the best.

1. A hosted assistant using approved public content

A provider runs the model; the assistant draws on selected material the organization has approved. This may suit a narrow set of common questions.

Someone still needs to choose the content, check answers, handle changes and review provider terms and data flows. “The website is public” is not a reason to send private questions or unrelated visitor context without review.

2. An assistant that looks up approved information

Retrieval-augmented generation (RAG) means finding relevant source material and giving it to a model to help answer a question. In plain language: look up the facts before drafting the answer.

For example, a visitor asks about a course date. The system retrieves the current course record and uses it to answer. It should not guess a date from an old brochure.

Only retrieve information that this visitor is allowed to access. An internal document does not become suitable for public use just because a search system can find it.

3. A model selected or customized by the organization

An organization may need a particular model or behavior. Fine-tuning means additional training intended to change how a model responds. It is not a guarantee of factual accuracy, and it does not automatically keep product or policy information current.

Use evaluations tied to the task, including questions the model should refuse or route to a person. Specialist topics need appropriate professional review; a customized model is not a substitute for it.

4. A model run in infrastructure the organization manages

Self-hosting can give a team more direct operational control. It also makes that team responsible for capacity, updates, access, monitoring and recovery.

Map every actual recipient: the browser, application servers, model server, search service, logs, backups and support providers. A model running on a private server does not prove that the rest of the conversation stays there.

Optional technical detail: how a lookup-backed answer works

A practical sequence is:

1. Receive the person's question and only the permitted context.
2. Check what sources this person may access.
3. Find relevant, current information.
4. Give the model the question, those sources and the response rules.
5. Check the proposed answer and show appropriate source links or uncertainty.
6. If the answer cannot be supported, offer the ordinary content or an appropriate human route.

An API is a defined way for one software system to request something from another. The request and response need an agreed format, limits, authentication and failure behavior.

Some retrieval systems use embeddings—numeric representations that help compare the meaning of text—and a vector store, a database that searches those representations. These are implementation choices. They do not establish that a retrieved document is correct, current or authorized.

Treat source documents as information, not instructions that can override the application's rules. An imported document must not grant an assistant permission to reveal data or perform an action. Keep authorization outside the model's judgment.

Keep the source material current

Assign an owner to each source, record its update time and define how changes or removals reach the retrieval system. Check stale prices, withdrawn offers and conflicting policies. A scheduled refresh is useful only if its failures are visible.

Retrieval may transmit excerpts to a model or application provider. Do not claim that source material “never leaves” a database if it is copied into the request. Review actual processing and retention, including caches and logs.

Bound the costs and the work

Model usage is a cost even when it produces value. Measure the actual expense and outcome; do not assume a long conversation is a qualified lead or that automated service replaces a human hour for hour.

Set a total budget, a conversation limit, a maximum request size, timeouts and allowed tools. Explain what happens when a limit is reached. The site should offer useful content or a suitable contact route, not a broken input or an unapproved paid overage.

Latency is the wait before a response. Test that wait, answer quality and failure handling together. A fast wrong answer is not a successful result, and a cheap model may create costly review or support work.

Sensitive uses need a deployment-specific review

Health, financial, legal and public-service settings can involve sensitive information and consequential decisions. This paper does not determine which laws, certifications or contractual arrangements apply.

Before enabling an assistant, have the appropriate legal, security and professional owners review the actual task, information, recipients, actions and fallback. Hosting location or a custom model is not a compliance certificate.

Make the role clear to the visitor. Do not present a fictional demo, generated explanation or administrative routing tool as professional advice. Do not collect sensitive details merely to demonstrate the interface.

Connecting an answer to another system

A CRM is a customer relationship management system—a place where a business manages contacts and sales activity. A webhook is a message one system sends to another when an event occurs. Neither connection should automatically export every conversation.

A reviewed handoff might work like this: the person chooses to contact the team, sees a proposed summary and recipient, edits or removes details, then confirms the request. The system records whether delivery actually succeeded. It does not promise “sent” merely because a model drafted a message.

For bookings, purchases or other consequential actions, enforce permissions and confirmation outside the model. Prevent duplicate actions on retries. Give failures an understandable recovery path and a human owner.

Reporting should answer a defined question, such as whether the assistant helped resolve a task. Keep necessary operational information separate from optional analytics, and do not quietly reuse conversations for another purpose.

Before choosing a provider or a model

Write down the task, approved sources, allowed actions, data recipients, budget, fallback and success criteria. Start with the narrowest useful case. Test unsupported questions and attempted misuse as well as friendly examples.

The first-build guide shows a simpler change that needs no assistant. The handoff paper explains the people and information involved when a conversation moves to staff.