👇 After this module

You have a live assistant on your own site. It answers from your published pages, in your voice, refuses anything off topic, and offers a call when it cannot help. You own it, and you can see every question it gets and what each one cost.

One root feeds all 🌱

Everyone is bolting a chatbot onto their site right now, and the shape is always the same. You upload a pile of documents, you train a stranger on them, you write a personality prompt, and then you pay by the message while the whole thing lives on someone else's platform. It answers in a voice that is not yours, from a frozen copy of your content that goes stale the day you change a price.

You are going to build the opposite. An assistant that is a native output of your root system. It already knows your work and your voice, because it reads the same root that runs everything else you have built. There is nothing to train, because the root is the training.

That is the whole idea, and it is worth saying plainly. One root feeds all. The content that runs your business also answers your visitors. Change a page, and the assistant changes with it on the next deploy.

The three things that make it different

Grounded only. Every answer is built from passages pulled out of your own content in the moment the question is asked. The model is never asked to know anything. It can only speak from what it was just handed, and it shows the page each answer came from. A coach's brand does not survive one confidently wrong answer or one invented price. This is how you make that impossible.

Scope-locked. If nothing in your content matches the question, it refuses, warmly, and offers a call instead of guessing from general knowledge. It is not free ChatGPT wearing your logo: a question about the capital of France costs you a fraction of a cent to refuse, and nothing more.

Owned and private. It runs on your own database and your own code, with a hard wall between the assistant and any of your business data. You pay no rent per message, you keep terms no outside platform can change, and it cannot leak a customer's details, because it never holds them. The Wall lesson shows you exactly why.

The five pieces

The rest of this module is one piece per lesson. Here is the whole map on one screen, so you always know where you are.

Decide three things before you build

You make three calls once, and everything after is assembly.

What it can see. Your published pages, minus anything private. The list of what to skip is the on and off switch for the whole assistant.

Who it serves. Free visitors now. Paying members later, from the same engine, with the last lesson showing how.

The voice it speaks in. Yours. The same voice already written into your root.

Mark complete Next: The Library

The Library: your content, made searchable 📚

An assistant can only answer from what it can look up. The Library is that lookup. It is your published pages, cut into small passages, with each one turned into something the computer can search by meaning rather than by keyword. When a visitor asks a question, the assistant searches the Library, pulls the handful of passages that actually match, and answers from those.

Three steps build it: chunk, embed, store. None of them needs you to write much. You point a script at your site and it does the work. But understanding the shape is what lets you trust the answers, so here is each step in plain terms.

Chunk: cut the pages into passages

A whole page is too big to be one searchable unit. So the Librarian splits each page at its natural breaks, a heading, a section, a paragraph block, into passages of a few sentences each. Each passage carries its page title and link, so the answer can always point back to where it came from.

One rule matters more than any other here, and it was learned the hard way. Two different prices must never land in the same passage. The first version flattened each page into plain text, and the price of one offer bled into the passage about another. The assistant started quoting the wrong number. Splitting cleanly, and keeping prices apart, fixed it. The lesson is bigger than prices: how you cut the content directly controls how accurate the answers are.

Embed: turn words into a position in meaning-space

Each passage is run through an embedding model, which turns the text into a long list of numbers. Think of it as giving every passage a position on a vast map of meaning, where passages that mean similar things sit close together. The question gets a position on the same map. Finding the right passages is then just finding the nearest neighbours. This is what lets a visitor ask "is this right for someone just starting out" and match a passage that never uses those exact words.

You do not need to follow the math. You need to know that this is why the assistant understands meaning, not just keywords, and that it costs almost nothing per page.

Store: keep it in your own database

The passages and their positions live in one new table in your Supabase database, the same project that already runs your business. It is locked down: nothing on your public site can read it directly. Only the assistant's Brain can search it, and only to answer questions. The Wall lesson covers exactly why that is safe.

The Librarian is also incremental. It remembers what it has already processed, so on each deploy it only touches the pages that changed. The assistant stays current with your site without re-doing the whole thing every time.

The pack also ships a small tester, kb-search.py. Ask it a question and it prints the passages the assistant would retrieve, so you can see what it will answer from before a single visitor does.

Mark complete Next: The Brain

The Brain: the function that answers 🧠

The Brain is one small function that sits between the question and the answer. It is the only piece that talks to the model, and it does five things in order, every time. None of them is complicated on its own. Together they are what make the assistant accurate, scoped, and safe.

The five steps, in order

1. Check the question. Reject anything empty, anything that is not text, and anything over the length cap (about 2,000 characters). This is the first guard against abuse.

2. Place it on the map. Turn the question into a position in meaning-space, the same way each passage was placed in the Library.

3. Find the nearest passages. Pull the handful of passages from your Library that sit closest to the question. These, and only these, are what the answer can be built from.

4. Check the scope. Look at how close the best match actually is. If even the nearest passage is too far away, the question is off topic. The Brain stops right there, returns a warm refusal with an offer to book a call, and never calls the model at all. This is the gate that keeps it from answering about anything and everything.

5. Answer, grounded. Hand the model the matched passages and the question, with one instruction: answer only from these, in this voice, and cite the page. The answer comes back, the visitor sees it with links to the real pages, and the exchange is logged.

Why the scope gate matters most

Step four is the difference between an asset and a liability. Without it, your assistant will cheerfully answer questions about tax law, your competitors, or the weather, in your brand voice, from general knowledge it should never be speaking for you. With it, the assistant has a clean edge: it is an expert on you, and politely useless on everything else. That edge is what makes it trustworthy, and it is what keeps the running cost near zero, because off-topic questions are turned away before any expensive work happens.

The gate has one number behind it, a threshold for how close a match has to be. You will learn to tune that number in the Make it yours lesson. For now, know that it exists and that it is doing the most important job in the whole system.

Where it runs

The Brain is an edge function, the same kind you built in Part 2 for your webhooks and your daily brief. It lives in your Supabase project, it holds the keys to the model in its own private environment, and your website calls it the way it calls any other function. You already know how to deploy one. This is just one more.

Mark complete Next: The Wall

The Wall: why it cannot leak your data 🧱

Putting an AI on your site in public raises one fair question. Could someone, by asking it the right thing or poking at it directly, get to your customer list, your revenue, your private notes, or your keys? The answer is no, and not because you are trusting the model to behave. It is no by design. This lesson is the guarantee, so that you can run it without worrying.

The trick is that the assistant is built so there is nothing private for it to reach in the first place. Here is each path someone might try, and why it dead-ends.

The model never holds your secrets

The keys that pay for the model and the search live in the Brain's own private environment, never in the text sent to the model. Even a model that has been talked into misbehaving cannot reveal a key it was never given. There is no secret in its hands to spill.

The model cannot reach your database

The model receives exactly two things: the passages pulled from your published Library, and the visitor's question. It has no connection to your database and no tools. The worst it can ever do is repeat content that is already public on your site, or make something up. There is no private data sitting in its context, so there is nothing to leak.

The function cannot read your business

The Brain talks to your database with the same public key your website uses, which by your own rules from Part 2 cannot read your contacts, your purchases, your leads, or any other private table. Its single database ability is to search the Library, and that search can only ever return published passages. A determined person calling the function directly hits the same wall a visitor does.

No way in through the side doors

No injection through the question. The question becomes a position on the meaning map and a parameter to a fixed search. There is no place where a cleverly worded question turns into a command.

No injection through the history. A visitor could try to smuggle in a fake instruction dressed up as part of the conversation. The Brain strips the history down to plain questions and answers before it forwards anything, and sets the real instructions itself, server-side, every single time.

The one thing a determined person might squeeze out is the assistant's own instructions, the lines that tell it how to talk. That contains no secret and no customer data, only its manners. Nothing private is exposed even in the worst case.

Mark complete Next: The Face

The Face: the widget your visitors see 😊

Everything so far has been the engine. The Face is the part a visitor actually meets: a small character in the corner of every page, a place to type, an answer that arrives in your brand, and a link to the page it came from. This is where owned-and-on-brand stops being a principle and becomes something a person can see.

A character, not a chat box

A plain chat box says generic rented tool. A character says someone built this on purpose. The assistant gets a face that belongs to your brand, made from your own colours and textures, with a small greeting when someone hovers. It is the same warmth you put into the rest of your site, in the one spot most tools leave cold.

For this system the character is a small textured figure built from the brand's own shapes. Yours can be anything that is recognisably you. The point is that it is made, not picked from a menu.

One question at a time

The widget does not pour out a wall of chat. It shows one question and its answer at a time, with a calm step-forward and step-back, so a visitor reads instead of scrolls. The first screen greets them and offers a few starter questions, the ones you most want a new visitor to ask, so they are never staring at an empty box.

Every answer points somewhere real

Each answer arrives with small links to the actual pages it was drawn from. A visitor can read the short answer and then click straight through to the full page. And when the assistant cannot help, or when a question is really a buying signal, it offers a call. It is never a dead end. The worst outcome is always a warm hand-off, never a shrug.

Loaded once, everywhere

The widget is loaded site-wide by the same shared script that loads the rest of your site furniture. You add it in one place and it appears on every page, desktop and mobile, without touching each page by hand. On a phone it opens to fill the screen so it is comfortable to type into.

Mark complete Next: Make it yours

Make it yours: voice, scope, weighting 🎛️

The assistant ships with sensible defaults, and then it has three dials you can turn to make it truly yours. Voice, how it sounds. Scope, how strict it is about staying on topic. Weighting, which of your content leads the answers. None of the three needs new building. Each is a small adjustment you make once you have watched it answer a few real questions.

Voice: how it sounds

The Brain carries a short instruction that tells the model how to speak: second person, warm, plain, the same rules the rest of your writing already follows. This is where you decide the assistant sounds like you and not like a help desk. If the answers come back a little stiff, or a little too eager, you adjust those few lines and the whole assistant shifts with them. Your voice is already written down in your root, so this is mostly a matter of pointing the assistant at it.

Scope: how strict

Remember the scope gate from the Brain, the check that turns away off-topic questions. It runs on one threshold: how close a match has to be before the assistant will answer. Set it tighter and the assistant only speaks when it is on very firm ground, refusing more and booking more calls. Set it looser and it stretches to answer more, at the risk of reaching. You tune this by watching real questions. If it is refusing things it should handle, loosen it a little. If it is answering things it should not, tighten it. It is one number, and it controls the whole personality of where your assistant stops.

Weighting: what leads

Not all of your content should answer with equal weight. The same question can be answered well from different pages, and weighting is how you choose which one leads. For this system the public website and the client stories were pushed up, and the dense course pages pushed down, because early on the assistant answered "is this for me" with philosophy instead of plain value and examples. A small nudge to the weighting fixed it. You decide what leads: your offers and outcomes for a buyer, your teaching for someone going deeper. It is a dial, not a switch, and you turn it by reading the answers you are getting.

Mark complete Next: See what people ask

See what people ask: analytics and cost 📊

Every question your assistant gets is a small piece of market research you used to never see. Someone arrived at your site, wondered something specific enough to type it, and either got an answer or got turned away. The assistant logs all of it, and that log is one of the most useful things it produces. The numbers also tell you, to the cent, what it costs to run.

What gets logged

For each exchange the assistant records the question, the answer it gave, whether it refused, how many passages it found, and the size of the request. No more than that. It is the same kind of anonymous, write-only log you already use for sign-ups: it can be added to, but your public site cannot read it back out.

The questions themselves are the gold. They show you the exact words real people use for what you do, the things they worry about before buying, and the gaps where you have no page good enough to answer well. That last one is a content to-do list written by your own visitors.

The real cost, not a guess

Because the size of every request is logged, you can add up the true running cost rather than estimate it. A typical real answer costs a few cents. Refusals and searches are effectively free, and the database is already paid for. So the figure you read is the whole bill, and for most solopreneurs it is a rounding error, a few dollars a month for an assistant that works around the clock.

Bring it into your rhythm

This belongs where you already look, so put it in your daily brief. Once it is wired in, your brief shows you each day how many people asked, what they asked, how many were turned away, and what it cost. After a week you can see which questions keep coming back. Those are the pages you have not written yet. The pack does not ship that wiring, because your brief is yours. The Go deeper below builds it.

Mark complete Next: Free and paid from one engine

Free and paid from one engine ⚙️

This last lesson is a look at where the assistant goes next. You do not have to build it today. The free assistant you just built is complete and worth running on its own. But the same engine can do one more thing: serve free visitors and paying members from a single system, where what someone gets depends on who they are. It is the difference between an assistant that markets your work and one that also delivers it.

The idea: teasers in public, the full thing for members

Each piece of paid material gets indexed twice. A short teaser, safe to say to anyone, that describes what a module covers and points to it. And the full content, marked members-only, that a public visitor can never retrieve. A stranger asking about an advanced topic gets the teaser and an invitation. A logged-in member asking the same thing gets the full answer. Same question, same engine, different depth, decided by who is asking.

How the engine tells them apart

The widget quietly includes the visitor's sign-in, if they have one. The Brain reads it, checks what they have actually bought against your own records, the same trusted check you used to gate your course pages, and decides what they are allowed to see. Then it searches only within that. Anonymous visitors are held to public passages and teasers. Members get the paid passages added in. No one can ask their way past it, because the limit is enforced at the database, not by asking nicely.

Why this is safe by construction

The reason "the full build lives inside the module" stays true is that the public assistant is never handed the full text in the first place. The teaser is a different, deliberately shallow passage. The paid passages are walled off at the database, reachable only by a verified member. So a stranger, no matter how they phrase the request or whether they call the function directly, simply cannot reach members-only content. It is the same wall from earlier, now doing double duty as your paywall.

When to build it

Build the free version first and let it prove itself. Add the paid layer when you have paying members and enough material worth gating. It is the same five pieces you already know, with one extra check and a second pass over your content. Nothing here is new infrastructure. It is the free assistant, grown up.

Mark complete