Build an AI Product

The chat box on this site's home page is a small, complete AI product — and it's the thing we're going to build together in this series. Not a toy that works in a demo and falls over on the first odd question, but the real one, with the unglamorous parts that make it survive contact with strangers.

You're already talking to the project. This is part 0: the map, before we lay a single brick.

What the project actually is

The agent on the home page answers visitors as a stand-in for me. Ask it what I'm building and it opens a few threads; pull one and it goes a level deeper with a real number and something concrete to point at. Underneath that friendly behavior is a full stack: it picks a model, it answers from a fixed body of facts instead of making things up, it refuses questions outside its lane, and it degrades to a polite message instead of a crash when something breaks.

That last sentence is the whole series in miniature. Anyone can get a model to say something. The work is in the instead — answers grounded instead of invented, a graceful message instead of a 500, a typed result instead of a string you have to guess at.

The map: build it layer by layer

An AI product is a stack of layers, not one clever model call. I drew the whole anatomy (the two planes, every box, where DSPy fits) in anatomy of an AI product; that diagram is the map for this entire series. Each part here takes one box and builds it for real.

Here's the route we'll take:

1. The brain — typed steps with DSPy, so the model's job is a contract you can test, not a paragraph you keep re-tuning.
2. Decide what "good" means — the eval. We build it early, because everything after it becomes measurable once it exists.
3. Grounding — make the agent answer from a corpus and stop it from inventing facts.
4. Serving — run it on a local model, then a hosted one, and let the visitor choose — with a hard cap on spend.
5. Reliability — the guardrails that mean a visitor never sees a crash: validation, repair, fallback, off-scope handling.
6. Conversation design — the open-a-thread, go-deeper, re-open rhythm that makes it feel like a conversation, not a form.
7. The offline plane — keeping the agent's facts fresh on a schedule, and running the evals automatically.
8. Knowing it works — the funnel and cost numbers that tell you the truth about a live product.
9. Ship and operate — putting it together and keeping it up.

How each part works

Every part is built the same way, because theory without practice doesn't stick and practice without theory doesn't transfer:

• The idea. The concept and why that layer exists, kept short.
• How the twin does it. The real decision I made on this product, with the trade-off, so you see it in a shipped thing and not a tutorial vacuum.
• Your turn. Build that same layer into your own version. The project grows one box per part, so you're never staring at a blank file.

By the end you'll have a working, measured AI product you own — and, more usefully, the mental model for where every piece goes the next time you build one.

One honest boundary

I'll show you the architecture and the real decisions — including the ones I got wrong first and had to fix. What I won't print is the exact wording of the guardrails: the prompts, the refusal patterns, the injection defenses. The agent itself will tell you why if you poke at it — the system that runs it is kept private on purpose, because for a public agent that privacy is part of the security. You'll learn the pattern and build your own locks. That's the right way round anyway.

Part 1 is next: the brain — turning a model call into a typed, testable step with DSPy. Bring a small idea for your own agent; you'll want something real to build as we go.