From prototype to product

Four days ago Foxhole Web was a search box that ran a query, handed the results to a model, and streamed back a cited paragraph. It worked. It was also, quite plainly, a prototype: one thing, done one way, for every question you could possibly ask it.

That is the stage most AI search projects never leave. The demo is easy. The part that follows is not, because it is not one problem, it is a hundred small ones that only show up once real people ask real questions.

Not every question wants a paragraph

Ask what time it is in Tokyo and a paragraph is the wrong shape of answer. So is a five-sentence essay about the weather. You wanted a number, and you wanted it before you finished reading the first line.

Foxhole now recognises six of these and answers them directly, in a card that appears above the written answer:

• The weather where you are or anywhere you name, with the next five days
• The time, date and offset in any city, and how far that is from your own clock
• The definition of a word, with senses, examples and near synonyms
• A translation, with how formal it is and what it says literally
• A live or finished score, with the record, the venue and who is carrying it
• A business, with its hours for every day and whether the door is open now

None of these are the model guessing. The weather is a forecast service. The scores are a scoreboard. The definitions are a dictionary. The model's only job is working out which of the six you meant, and it is given the question alone to decide, not the whole web.

The part that was harder than the widgets

Building the cards took a day. Making them coexist with the answer took longer, and it is the more interesting problem.

The first version was worse than having no card at all. You would ask about the weather, get a card saying 83 degrees and clear, and then a paragraph underneath explaining that it was 83 degrees and clear. The model could not see the card, so it answered the question it had been given, exactly as it should have. Two answers to one question, the second one redundant.

The fix is coordination. The model is now told what the card already says, and told that answering the question again is the one thing it must not do. Its job becomes the paragraph that comes after an answer, the part a card cannot hold: what the day will actually feel like, how a phrase lands with a native speaker, what decided the game. The heading above it changes from "Answer" to "More on this", because that is what it now is.

The same coordination fixed a bug we would not have found otherwise. If you were in Charlotte and asked how cold it was in Denver, the system used to insist on Charlotte, because it had been told to localise. The card knows the question was about Denver. The card now wins.

Three views instead of one

Results, Media and Shopping now sit as tabs under the search box. Pictures get a full wall instead of a cramped strip, and places to buy get a page rather than a box wedged between the answer and the sources.

Both load only when you open them. A search that never touches the Media tab never pays for the image search behind it. That restraint is the whole reason this can stay free.

What this stage actually is

A prototype answers the question you designed it for. A product answers the question in front of it, in the shape that question deserves, and gets out of the way. The distance between those two is not one clever idea. It is a long sequence of small decisions about shape, cost and restraint, most of which nobody notices when they are made correctly.

Foxhole is not finished. The business hours are read off the open web and can be wrong, so the card says to check before you go. The gallery depends on what an image index happens to hold. Every answer still carries a note reminding you a model wrote it and the sources are there to be read.

But it is no longer a demo of an idea. It is starting to be a thing you could use on purpose, every day, and not feel the seams. That gap is the one worth closing, and it is closing fast.