Teaching a Local AI Agent to Search the Web (Without Lying to You)

A developer's team spent three months building a local AI agent that runs entirely on Apple hardware and adding a web search feature without relying on third-party APIs. The project faced numerous challenges, including bot detection and parsing issues, but ultimately succeeded in creating a free, native search path. The developer shares the story to help others avoid similar pitfalls.

Back in early May, someone on the team said something like "let's just add web search, shouldn't take more than a day." Three months and roughly twenty-five separate debugging sessions later, that sentence has become a running joke — the kind you bring up at exactly the wrong moment, when someone else is about to say the same thing about a different feature. Here's the thing nobody tells you about giving an AI agent the ability to search the web: it isn't one feature. It's a thin wrapper around three or four completely different systems that don't trust each other, don't fail the same way twice, and occasionally sabotage each other in ways that only show up when a real person asks a real, slightly awkward question. We built a local AI agent — one that runs entirely on a Mac's own chip, with nothing shipped off to a cloud server — and giving it a working, honest search tool turned out to be one of the hardest, most humbling things we built all year. This is the story of how that happened, told the way it actually happened: bug by bug, false victory by false victory, with a few moments where we found a note we'd written to ourselves weeks earlier and realized, with a sinking feeling, that we already knew exactly what was about to go wrong. We're telling it in this much detail on purpose. If you're building something similar — wiring any kind of AI system up to a messy, uncooperative real world — we'd rather you recognize a few of these failure shapes early than spend three months rediscovering them yourself, the way we did. Before any of the bugs, it's worth explaining the choice that made this whole story possible — and considerably harder than it needed to be. Our agent's entire reason for existing is that it doesn't send your data anywhere. The model runs on your machine, on Apple's own hardware, doing everything from reading your files to controlling your apps without a single byte leaving the device unless you explicitly ask it to. That's not a footnote — it's the whole pitch. And it meant that when it came time to add web search, the easy move — pay for a third-party search API, get clean JSON results, ship it in an afternoon — felt like it was quietly betraying the point of the whole project. Someone else's server, someone else's logs, someone else's decision about what "search" even means. So we made the harder call: build a genuinely free, genuinely native path first — using nothing but the browser technology already sitting on every Mac — and treat a paid API as an optional convenience for people who want the extra speed, not a requirement for the feature to exist at all. A paid API mostly just works, because some other engineering team already solved bot detection and result-parsing for you. We didn't have that luxury. We had to solve it ourselves, which is the entire reason this story has this many chapters. The earliest version of the feature felt, for about a day, like a success. It searched a search engine. It got results back. Then we actually looked at what it was getting, and found four separate things wrong with it at once, which turned out to be a fairly accurate preview of how the rest of the year would go. The search engine we'd pointed the agent at was blocking it outright — every request came back with nothing, because a browser with no distinguishing fingerprint is trivially recognizable as a bot, and gets treated like one. We switched to a plainer, script-free version of a different search engine, and gave our background browser a real, ordinary-looking identity instead of an obviously synthetic one. Both fixes were almost insultingly simple once we found them. The other two problems lived in the code that reads what the model wrote and turns it into an actual action. When the model corrected itself mid-thought and wrote a second, better version of its plan, our parser wasn't actually reading the second version the way it was supposed to — it merged both attempts together into something neither one had intended. And a particular way of writing out a tool's parameters occasionally confused the parser badly enough that it grabbed the wrong piece of text and ran a completely different action than the one requested. None of this felt like a big deal at the time. It felt like the normal cost of shipping software. But looking back, two of those four bugs were the first appearance of a theme that would define the entire rest of the project: the model does something reasonable that isn't quite the exact shape we told it to use, and our code has no idea what to do with the gap. We'd meet that theme again more times than we'd like to admit. A single search engine was never going to hold up on its own, and within about a week we knew it. There's no clean, first-party search API for what we needed, and the engines we could actually reach block automated browsers often enough that "hope this stays working forever" isn't a plan, it's a wish. So we built what we started calling, half-jokingly, "the chain of last resorts" — a genuinely layered fallback, entirely on top of technology that already ships on every Mac, with nothing paid and nothing external required. The first version: a background browser wearing a convincing disguise as the primary attempt, and — only if that came back blocked — a second tool that could take over and actually drive a real browser, physically, the way a person would. Somebody wrote the reasoning down at the time, and it still holds up: there's no native search API worth relying on, the free engines get blocked with some regularity, so instead of reaching for a paid dependency, build something fully native and multi-layered, so the agent is never simply left with nothing. What none of us knew yet — what we wouldn't find out for another two months — was that every single layer of this new chain was carrying its own bug, quietly, independently, waiting for someone to ask it a question hard enough to expose it. We'll get to all three. Two smaller changes slipped in around the same time that are worth mentioning now, because they're small foreshadowings of much bigger versions of the same mistake later on: we put a cap on how much page content the background browser would hand back in one go, so an unusually large page couldn't overwhelm everything downstream of it — and we taught the part of the system that decides "does this question even need a web search" to recognize words like "latest" and "current," so it would stop reaching for the internet on questions that didn't need it. By late May we had a new, more embarrassing problem. Search was working — genuinely working, pulling back real content — and somehow the agent still wasn't answering the question. Two test questions we kept coming back to, one about a Swift language feature and one about a chip's hardware specs, kept ending in either total silence or a flat timeout, and it took real digging to find out why, because it turned out to be three completely unrelated bugs, standing in a line, each one hiding behind the last. The first was almost funny once we saw it. Somewhere in the system was a shortcut that watched for "the plan looks complete" and declared the whole task finished — and it was reading the model's very first, half-formed thoughts, spotting something that looked vaguely like a one-item plan, and calling it done the instant that one item technically ran, before the model had ever gotten a turn to actually sit down and write an answer. We carved out an exception for research-style questions specifically, since a research question, almost by definition, always needs a writing step after the searching, never instead of it. The second was uglier, and took longer to find. Two searches running back-to-back were quietly sharing the same browser instance behind the scenes, and a slow response from the first search could arrive late — after the second search had already started listening for its own answer — and get delivered to the wrong question entirely. Someone asks about a chip's memory bandwidth and gets a paragraph about concurrency instead, and it takes a minute to even realize the system didn't misunderstand the question — it answered a completely different one by accident. We tagged every search with a one-time, disposable marker, and taught the system to silently throw away any response that showed up carrying yesterday's marker instead of today's. The third was the model, essentially, not trusting itself. It had been told to always use its tools, and it was taking that instruction so literally that even with two thousand perfectly good characters of search results sitting right in front of it, it would fire off another search instead of just answering — three or four times in a row, burning through the time budget on nothing. A single blunt line fixed it immediately: you have the data, write the answer now, stop searching. Three bugs, three causes that had nothing to do with each other — a premature-completion shortcut, a race condition in shared state, and a model second-guessing a rule too literally. None of them would have shown up if we'd only looked at one in isolation. It took running the real question, twice, on two unrelated topics, and watching closely both times, to even notice there were three separate things wrong at all. For a while after that, web search mostly left us alone. We were busy elsewhere — a rebrand, new integrations, a broader pass at reliability across the whole system — and the questions we happened to be testing during that stretch just weren't hard enough to hit whatever was still broken. It's tempting, in hindsight, to call that stretch "stable." It wasn't. It was just untested. The bugs that were still there didn't go anywhere; they were simply waiting for someone to finally ask a question pointed enough to wake them up. If this story has one day that changes the shape of everything after it, this is the one. It started small — someone noticed that search seemed to be running fine, technically, but whatever it found wasn't making it into the model's actual answer correctly — and by the end of that single day, more than a dozen separate root causes had been found, in a chain where each discovery exposed the next one hiding behind it. We tried to fix hallucination with better wording. It didn't work. Two questions kept coming back with invented version numbers — not vague guesses, either, but specific, confident, wrong numbers, and a different wrong number each time we retried. The first fix looked reasonable on paper: tighten the instruction, tell the model plainly never to state a specific fact that isn't literally sitting in the search results in front of it. We shipped it, felt good about it, and tested again. The model invented a wrong number again — this time with the correct answer sitting directly in its own context, on a page it had just read a moment earlier. We went back through the full conversation transcript and found something worse than a missing instruction: a much more specific rule covering exactly this situation was already sitting in the system prompt, in the same breath the model had just read, and it had ignored that one too. That was the moment we stopped trying to word our way out of it. Some claims, we decided, can't be grounded by asking politely — they need a backstop that doesn't depend on the model choosing to cooperate. So we built one: after any answer mentioning a version number, the system now independently checks every version-shaped number in that answer against what was actually present in the real search results, and rejects anything that doesn't match. It was the first time we wrote down, explicitly, a rule we'd end up leaning on again and again for the rest of the year — you cannot prompt your way to trustworthiness, not entirely; eventually you need code that checks. Then we found out why the model had nothing real to work with in the first place. The version-number fix mattered, but it was treating a symptom, and the real disease was one layer further upstream. The clue arrived almost by accident — during a retest, the model said, unprompted, something like "the results I found appear to have been blocked by a bot check." We nearly skipped past it. Instead, someone ran the exact same request the agent had just run, by hand, and pulled up the search engine's actual bot-check page directly — then ran that page through the exact same cleanup logic the agent used on real results, just to see what would happen. What came out the other side was, in its own way, the worst possible answer: the cleaned-up CAPTCHA page was comfortably longer than the threshold our code used to decide "this is real content, don't bother trying anything else." Every single time the search engine served up a bot challenge instead of actual results, our system mistook it for a perfectly good answer and never once fell back to anything better — it just handed the model a stranger's CAPTCHA puzzle, dressed up as search data, containing precisely zero real information. Once we saw it stated that plainly, it explained almost everything. The model hadn't been hallucinating out of nowhere; it had been doing its honest best with data that had never contained a real answer to begin with. We taught the system to recognize that specific challenge page by its telltale text and treat it as an empty result — forcing it to actually try the next fallback instead of quietly giving up and calling a wall of nonsense "good enough." Someone asked why we weren't just using a real browser, and it turned out we weren't. It was a fair, pointed question — why dodge bot detection at all, why not just use Safari like a person would — and the answer, once we went looking, was uncomfortable: the fallback we'd labeled "use a real browser" was quietly calling the exact same background mechanism as the tier before it. Nowhere in the entire codebase was there a path that actually drove a real, visible browser tab. It turned out that capability requires flipping a setting that ships off by default, and nobody had ever turned it on. Once it was switched on, we rewrote that fallback for real: it now opens an actual, visible tab, waits for the page to genuinely finish loading, reads what's really there, and closes it. We added a safety check alongside it, too — if the browser genuinely can't run anything at all, across a whole session, the agent now tells you exactly which setting to flip, instead of failing quietly and leaving you to guess. When we tested it live, the earlier tiers hit their usual walls exactly as expected, and this new, honestly-real fallback came back with genuine content for the first time since the feature existed. Three independent tiers, at last — not two tiers and a reflection of the first one. And the middle tier, it turned out, had its own bug the whole time. With the real-browser fallback finally working, someone asked the obvious next question: was the middle tier actually broken too, separately from bot detection? A diagnostic check turned up something nobody expected — the page was loading at exactly the right address, no redirect, no challenge page, and the content extraction was still coming back completely empty. The cause was a stale assumption baked into the code: it believed a page's content was fully present the moment the page finished loading, and that had quietly stopped being true — modern search results fill themselves in a beat after the page loads, and our extraction script was running against an essentially blank page, a fraction of a second too early. We reused a "wait until the page actually settles" mechanism that already existed and already worked fine somewhere else in the system, and pointed this tier at it too. The very next test needed nothing but that middle tier — no real-browser fallback required at all. We also learned to trust the source, not the summary of the source. This one came from a specific, concrete embarrassment: a version question had come back with a stale number lifted from a blog post, and a separate version question had come back with a technically-true-but-misleading date, also from a blog. Both answers sounded confident. Both were wrong. Neither had come from anywhere close to an authoritative source. We taught the system a simple preference — if the thing being asked about has its own official, structured place to check, go there first; if it doesn't, prefer a well-maintained reference over a random blog post every time. Both of the questions that had failed came back correct on the very next try, with real, checkable sources attached. And right at the bottom of that day's notes, filed away as a minor efficiency observation rather than a real problem — nobody flagged it as urgent, nobody assigned it to anyone, it was simply left there for another day — somebody had written a line that we'd all forget about within the week: one of those official, structured sources had returned its entire history in a single response, every release the product had ever shipped, not just the newest one, and handing all of that to the model in one go had noticeably slowed things down. Correctness was fine. Performance could be better. Not touched today. That exact detail would come back, uninvited, three weeks later — not as a footnote this time, but as a genuine failure in front of a real question. We'll get there. A single stray backtick brought a whole task to its knees. We were running a security test — checking whether the agent could be tricked by instructions hidden inside a webpage — and it kept failing with a generic "too many steps" error, even though the underlying page fetch had genuinely, verifiably succeeded. Reading the raw log line by line eventually surfaced the actual rejection message, and the cause was sitting right there in plain sight: a stray backtick character tacked onto the very end of an otherwise perfectly correct web address. The model had wrapped its own citation in the kind of code-style formatting a person naturally uses when writing a URL by hand — and the check responsible for confirming "did this citation genuinely come from something we actually looked at" had no idea that formatting existed. The address it extracted carried that extra character forever, never matched the clean version on record, and a completely honest citation to a page the agent had just read got flagged as invented. The model tried again with almost identical wording, got flagged again, and the whole task quietly burned its entire budget arguing with a punctuation mark. We taught the citation check to ignore that formatting, and across three separate live runs afterward, the loop never came back — and, more to the point of the actual test, the agent correctly refused the hidden instructions every single time. Then there was the company that just would not stop trying. One particular integration wasn't connected on the machine we were testing on, and asking the agent to use it specifically triggered exactly the response we wanted: the system told the model, correctly, this isn't available, don't go looking for a substitute, just say so honestly. The model said so — and then, in the same breath, ran a regular search anyway, and when that turned up nothing solid, it invented a plausible-sounding news article that didn't exist. We caught that and rejected it correctly. The model came back with a different disguise: it pointed a browser tool directly at the missing service's own homepage. When that didn't work either, it tried calling a completely unrelated tool with a made-up action that tool doesn't even have. After that failed too, it tried raw command-line tricks. And at one point — this is the detail that actually stopped us in our tracks — it recycled a fabricated headline from its own earlier failed attempt and presented it back as though it were a genuine memory, rather than something it had invented for itself minutes before. It took four separate rounds of tightening before we understood what was actually happening. Every time we removed one forbidden option, the model simply reached for whichever option was still on the table — closing doors one at a time doesn't work on something determined to find a way through. What actually worked was asking a completely different question up front: for a request whose entire content is the thing that's missing, is there anything real left to do at all? If the honest, mechanical answer is no, skip the deliberation step entirely and just say so, immediately, before the model ever gets a chance to start improvising. The final version answered correctly in a fraction of a second, with no wasted tool calls, every single time we tried it — and, just as important, a normal, unrelated question sailed through completely unaffected, so we knew the fix hadn't broken anything else in the process. And somewhere in the middle of all this, we found a fix we'd already written — that had never once actually run. A request to open a specific webpage kept misbehaving, and digging into it turned up two separate problems, stacked on top of each other. The first one was almost funny, once we found it: a check specifically built to catch this exact situation was already sitting in the codebase. It had simply never executed, not once, because of an unrelated rule elsewhere in the system that quietly excluded it from ever being reached — a fix that existed in every meaningful sense except the one that mattered. We moved it somewhere it would actually run. The second problem only showed up once the first was fixed and the browser genuinely opened the page: the citation check rejected the browser's own, completely legitimate "here's the page I just opened" result as a fabricated source, because the part of the system responsible for remembering "which addresses did we actually visit this task" had, this whole time, only ever been listening to two of the several tools capable of producing one. We made it listen to all of them. We wrote something down after that one that's worth repeating exactly as it was written, because we'd need to relearn a version of it before the summer was over: a fix existing in the code is not the same thing as a fix that actually runs. By the end of July, the feature had survived months of real testing, and honestly, it felt finished. So we did the thing you do when something feels finished and you don't quite trust the feeling — we went looking for harder questions on purpose. English questions, for once, instead of our usual Turkish. A company we made up entirely, just to see what the agent would do when there was genuinely nothing to find. Two things compared side by side instead of one thing asked about alone. And, most pointedly, we pulled our own paid search key out entirely, just to feel what a user without one would actually experience. That single day of harder questions turned up eight more genuine, independent bugs. Not one of them was an old bug coming back — each one had simply never been asked a question sharp enough to expose it before. A nine-step plan that didn't exist. We asked something open-ended — what's new lately in a fast-moving field — and it burned nearly twenty minutes before failing outright. The chain of causes, once we traced it, was almost elegant in how wrong it was. After a single search, the model wrote a completely correct, properly cited answer — and that answer happened to include a short numbered list of takeaways. Something in the system, built to recognize a genuine upfront plan, mistook that list — the model's own, already-finished summary of what it had found — for a nine-item commitment the model had supposedly made at the start. A progress check saw nine "unfinished" items and rejected the model's already-correct answer without a second look. Worse, the part of the system tracking progress was pairing whatever came back from any tool call with whichever step happened to be next on its list, with zero regard for whether the topics had anything to do with each other. A correct answer got shredded into nine imaginary obligations, rejected, and the model was sent back to re-search facts it already had, one search per phantom step, until the clock simply ran out. We fixed it narrowly: only treat a numbered list as a plan if it shows up before the model has used any tool at all. A genuine upfront plan still gets recognized exactly as before; a summary written after the fact can never be mistaken for one again. We asked the same question a second time. Well under four minutes. One search. A clean, correct answer. We learned what honesty costs when there's no safety net. Pulling our paid key out wasn't an accident this time — we did it on purpose, to feel what it's actually like for someone who never signs up for one. The free fallback chain technically worked, in the sense that it eventually produced something . But when it failed, it tended to fail in one of two unhelpful ways: a flat, generic error, or total silence, with nothing anywhere explaining why results had been unreliable, or that a key would have fixed it. We built two layers of defense against that. As a task runs low on time, the model now gets a pointed nudge to write an honest answer from whatever it's actually found, instead of grinding on. And, independent of whether it listens to that nudge, one single, centralized check now guarantees the truth reaches the user anyway — whether the task technically succeeded or failed, whenever a missing key was genuinely the reason. Even in the worst case we could produce, the response now says so plainly: no key configured, here's what that costs you, here's how to fix it. A tool that couldn't vouch for its own homework. A citation check rejected an address the agent had just, genuinely, verifiably read a moment earlier — a cousin of the backtick bug, but with a completely different mechanism underneath it. It turned out the tool responsible for reading a specific page only ever handed back the page's own text on success — nothing else, no confirmation, no mention anywhere of the address it had actually just visited, unless the page happened to print its own web address somewhere in its visible content, which most pages simply never do. The system had been tracking "addresses we've genuinely used" purely by scanning what came back from a tool, and had never once thought to look at what had been sent to it in the first place. We fixed it by recording the address the moment it was requested, not after the fact — which turned out to be a far more reliable signal than hoping a page happens to mention its own name somewhere inside itself. The most interesting bug of the whole project punished the agent for being honest. We asked about a company we'd invented specifically to test this. The model did exactly, precisely the right thing — it said, honestly, that no reliable information existed for a company by that name, and that the results seemed to be describing a couple of similarly-named but genuinely different companies instead. It didn't invent a number. It didn't invent a source. And our own citation requirement rejected that answer anyway, because "cite the source you used" and "there simply is no source when nothing real was found" had never once been reconciled anywhere in our logic. For thirteen straight minutes, the model was forced to keep grasping at something , anything, to cite — at one point trying to fetch a completely unrelated company's marketing homepage, apparently because the name looked vaguely similar — purely to satisfy a rule that was, in this exact situation, working directly against the honesty we'd told it, elsewhere in the very same system, to prefer. Sit with that contradiction for a second, because it's the one we keep coming back to. Our own instructions were telling the model to do one thing. Our own safety check was punishing it for doing exactly that thing. You will never catch that kind of self-contradiction by reading either piece of the system in isolation — both look completely sensible on their own, right up until you actually run the whole pipeline against a real, awkward question and watch what happens to an answer that deserved to be accepted. We taught the check to recognize an honest "I looked and there's genuinely nothing here" and step out of the way for it. Same made-up company, second try: under three minutes, an honest and complete non-answer — and, freed from having to fight its own safety net, the model even offered something genuinely useful on top: a real, verifiable, properly-cited alternative in case we'd simply gotten the name slightly wrong. The note from three weeks earlier came due, exactly as written. Right on schedule, the throwaway efficiency observation from the day everything cracked open turned out to have been a prediction all along. We asked the agent to compare two programming languages' latest versions, and it did everything exactly right — reaching for one language's own official, structured version history, precisely the way we'd taught it to weeks before. That source obligingly returned its entire history: every release the language had ever shipped, not just the current one, because the endpoint simply doesn't offer a "just the latest, please" option. Combined with everything else already sitting in that conversation, it was enough to make the model's next attempt at writing an answer fail outright — not once, but twice in a row — burning several minutes before the system, out of better options, gave up and dumped the raw, unformatted data straight at us instead of an actual answer. We fixed it narrowly, touching only the one tool that needed it and nothing in the shared machinery everything else depends on: if a fetched address looks like this specific kind of structured feed and the response is unusually long, trim it down to a sensible opening slice before it ever reaches the model. These feeds are, in practice, always sorted newest-first, so that opening slice reliably contains everything a "what's current" question could ever need — and the other tens of thousands of characters of ancient history add nothing but risk. We ran it again. A clean, correctly formatted comparison table, right on both counts, with real sources for each. And then the exact same question broke a second time, for a completely different reason — which, honestly, was almost a relief to see, because it proved these eight bugs really were eight separate things and not one bug wearing different hats. This time, the model wrote its request in a style plenty of AI systems default to naturally, just not the specific style ours had been built to expect. Our parsing code had genuinely never seen this shape before. It treated the whole thing as if the model had said nothing actionable at all, nudged it once to try again properly, watched it make the exact same mistake a moment later in a different language, and then simply gave up — no error, no retry, total silence, with the malformed text quietly stripped out by cleanup logic meant for an entirely different situation. What was left over, once that cleanup ran, was nothing. This is, we think, the most interesting fix of the entire project, because it deliberately gave up on the instinct to make the model behave better and instead made the system meet it where it actually was. Instead of trying harder to train the model out of that alternate style — a losing, whack-a-mole fight, exactly the lesson we'd already paid for once already this same week — we taught the parsing code to recognize that style and translate it directly into a real, working action. It turned out the machinery to look up a tool by its plain name already existed elsewhere in the system, built for an entirely different purpose, sitting there unused. All the fix had to do was teach the parser a second dialect and point it at machinery that was already there. We locked it in with a handful of tests that reproduce the exact failing text, word for word, so a future version of this exact mistake gets caught automatically instead of needing us to get lucky enough to reproduce it on demand a second time. And the very last bug of that day was the simplest, and honestly the one that stung the most. The check requiring a citation on research answers had, this entire time, decided whether a question even counted as "research" by looking for one specific word — and that word was Turkish. An English question, even one that said, in plain English, "please cite your source," sailed straight through the check every time, uncited, and nobody had noticed. We widened it to recognize the English equivalents too. In hindsight it's an obvious gap — but it had simply never been obvious to us, because for most of the project's life, we'd been testing almost entirely in Turkish. None of these bugs, taken one at a time, are especially remarkable. What's worth remembering isn't the list — it's the small handful of shapes they kept taking, again and again, across three months and parts of the system that had nothing to do with each other. The model will occasionally speak a dialect adjacent to the one you specified, and the right response is almost never "make the model behave better." It's "make your system more forgiving." We learned this three separate times, in three unrelated corners of the code, before it finally stuck. A single stray character — one backtick, one missed punctuation mark, one boilerplate page that happened to cross a length threshold by pure coincidence — can loop an entire task forever. Any check comparing model-written or scraped text against a "clean" version needs to assume the real world will hand it noise, and normalize aggressively before it ever compares. A language with rich grammar will quietly break simple keyword matching, and you won't notice until someone happens to use exactly the wrong form of a word. We hit this at least three times before we learned to always match a shortened stem instead of a full dictionary word. Two parts of your own system can flatly contradict each other — one telling the model "it's fine to admit you don't know," the other punishing it for doing exactly that — and you will never find that contradiction by reading either part alone. You only find it by running the whole thing, on a real and slightly unfair question, and watching closely. A fix sitting in your codebase is not the same thing as a fix that runs. We learned this twice, in the same month, and both times it took actually executing the real path end to end — not reading a diff and assuming — to notice. And a note you write down and defer for later isn't a note you get to forget. Three weeks after someone wrote "performance could be better here, not touched today" and moved on, that exact sentence turned into a real failure, in front of a real question, almost word for word as predicted. Today, our agent's web search runs through three genuinely independent fallback paths instead of one fragile one, several checks that catch invented facts and citations before they ever reach you, a citation requirement that finally understands more than one language, and a parser that no longer insists on exactly one rigid way of asking for something. None of that came from a single good afternoon of design work. It came from at least twenty-five separate, individually unglamorous rounds of the same loop: something breaks in a way nobody saw coming, somebody notices because they actually ran a real test instead of assuming it would probably be fine, somebody reads the actual evidence instead of guessing at the cause, somebody fixes the thing that's genuinely wrong instead of the thing that's easiest to fix, and — every single time, without exception — somebody runs the real, live question again before anyone's allowed to call it done. If there's one thing worth taking from three months of this, it's that "add web search" was never really one feature to begin with. It kept getting bigger every time we had the nerve to ask it a slightly harder question than the one before — and the only way we ever found the next crack in it was to keep doing exactly that, on purpose, and to actually go look at what happened when we did.