The Algeverse Assistant
An NSF-funded project teaching algebra in virtual reality hired me to build its website. I left it with a retrieval-augmented AI assistant that answers a visitor's questions from the project's own research, grounded so it cannot invent an answer, on infrastructure that costs almost nothing when no one is asking.
Hired for a website, not a chatbot
Algeverse is an NSF-funded research project, a recipient of the NSF Award for Broadening Participation in STEM, that teaches algebra in virtual reality to close equity gaps at HBCUs. The research is real and it is working: a context-aware AI supports students inside the VR experience, and the pilots have logged thousands of events with high action accuracy.
I was brought in for something more ordinary. The project needed a public-facing website that explained the work to funders and collaborators, and a way for the team to publish updates as the research progressed. I designed and shipped that, and set up a publishing workflow so the team could post news on their own without routing every change through me.
Then the project got under my skin. This is a serious AI effort aimed at a problem I care about, run by people doing it for the right reasons, and building a plain brochure site for it felt like leaving value on the table. The whole premise is applying AI to help people learn. So I added some AI of my own.
If a project is about using AI to help people learn, its website should use AI to help people understand it.
A research site asks too much of a visitor
A research project's substance is scattered by nature: across landing pages, blog updates, quarterly progress reports, and annual findings, much of it in PDFs. A funder checking in, a collaborator evaluating a partnership, or a student who is simply curious has to read most of it to find the one answer they came for. Most people will not. The work is excellent and largely unread.
The question I wanted to answer was narrow: could someone get a trustworthy answer in one sentence instead of thirty minutes of reading? On a research project, "trustworthy" is the entire difficulty. An assistant that answers confidently from thin air is worse than no assistant at all, because here the content is the credibility.
On a research project, a chatbot that guesses is a liability, not a feature.
Retrieval first, generation second
"Retrieval-augmented generation" is two problems sharing one name: find the right context, then write a careful answer from it. The system solves each on its own path, and they meet at a single store.
Retrieval-augmented generation
Ingestion splits the site's content into passages, turns each one into an embedding (a numeric fingerprint of its meaning) with Amazon's Titan model, and stores it in a vector index. When the team publishes or edits something, it flows into that index.
A query embeds the visitor's question the same way, matches it against the index to pull the handful of most relevant passages, and hands them to a language model with a strict instruction: answer using only this context, and admit when it is not enough. Retrieval is what keeps the answer honest. Generation is what makes it readable. The model itself is the least interesting part of the system.
The intelligence that makes this trustworthy lives in the retrieval and the constraints, not in the size of the model.
Serverless, and silent when idle
The entire backend is serverless and event-driven. There is no server to keep running and nothing billing by the hour when no one is chatting.
The stack at a glance
One decision is worth naming, because it is invisible when it works. The chat widget in the visitor's browser never holds the credential that talks to the backend. The browser calls WordPress, WordPress attaches the secret key on the server side and forwards the request. That same server-side hop is where the assistant quietly picks up which page the visitor is on, so it can answer in context. The key stays off the client, and the answer gets smarter. Both fall out of one choice.
The credential never reaches the browser, and the visitor still gets a context-aware answer. Both come from the same design.
The decisions that actually mattered
The interesting part of a build like this is not the parts that worked. It is the handful of forks where two reasonable options pulled in opposite directions, and I had to pick one and own what it cost.
On-demand models over always-on endpoints
The default way to serve embeddings is a dedicated inference endpoint, which bills around the clock whether or not anyone uses it. For a research site with uneven traffic, that is money burned on silence. I moved embeddings and generation to on-demand Bedrock calls. Cost scales with questions asked, not with time elapsed. The trade is a little cold-path latency, which a chat can absorb and a trading system could not.
A pay-per-use vector store over a managed cluster
The usual home for embeddings is a managed search cluster with a monthly floor in the hundreds of dollars before the first query. For one site that is indefensible. I used S3 Vectors, which has no idle cost at all. At rest, the whole system costs effectively nothing. The trade is a newer service with fewer knobs, which this workload simply does not need.
A small model, made reliable by retrieval
I did not reach for the largest, most expensive model. Because every answer is grounded in retrieved passages, a lean model like Nova produces accurate, on-topic replies at a fraction of the cost. Good retrieval lets a small model punch well above its weight. The trade is less open-ended reasoning, which a factual Q&A assistant never exercises.
Grounding over fluency
A bot that answers everything confidently is easy to build and dangerous to ship on a research project. I constrained the model to the site's own content and to saying "I don't have that" when the content runs out. I traded a little polish for the only thing that matters here: answers you can trust.
Every one of these traded a capability I did not need for a cost I refused to pay.
The admin panel is the product
A chatbot only I can maintain becomes a liability the day I move on. Algeverse is run day to day by a rotating group of volunteer research students, most of them not engineers. So the hardest design target in the whole build was never the AI. It was the admin experience.
From the WordPress dashboard, a student connects the site once, then clicks a single Sync button to pull every page and post into the assistant's knowledge base. Publish a new update and it flows in on its own. To add something the site does not already say, a policy, an FAQ, a one-page explainer, they drag a PDF into an uploader and it becomes part of what the assistant knows. A dashboard shows exactly what is indexed, and a test box lets them try a question before anyone else can. No command line, no keys to paste, no retraining to schedule.
That was the deliberate inversion: take the genuinely complex part, the generative AI, and make it feel like one button to the people who own it, then spend the engineering effort on making that button trustworthy.
The measure of this system is not how clever the model is. It is that a student can keep it current without ever thinking about embeddings.
Live, maintained by the team, nearly free to run
The assistant is live on algeverse.com today. The team keeps it current through the same dashboard they publish with, the answers stay anchored to what the project actually says, and the infrastructure sits near zero cost whenever no one is asking. A marketing website became something a visitor can have a conversation with.
What I carried out of it was less about any single model and more about the shape of a good AI feature, which I would put this way.