Best-in-Class AI Site Search Without the Middleman

[00:00:00] Hi, everyone. Welcome to Best in Class AI Site Search Without the Middleman. My name's Hank VanZile, and I'm the senior director of customer experience at Tag1 Consulting. If you haven't heard of Tag1, we are the global engineering team behind some of the world's most demanding digital platforms. We help organizations like those you see here who can't afford for their technology to fail. So if you'd like to learn more about us, you can visit us at www.tag1.com.

[00:00:29] And just a little bit about me. I live just outside Boston, and as I mentioned, I lead customer experience at Tag1, which basically means making sure our customers get the value that they deserve and expect from working with us. I've been building the open source web for almost thirty years, and in that time I've had the opportunity to work with organizations of all sizes, from tiny nonprofits to some of the most prestigious universities and largest corporations in the world.

[00:00:56] And for most of those thirty years, across hundreds and hundreds of clients, I can tell you truthfully, the biggest pain in my ass has been trying to keep up with Google site search. Ever since Google Search was first released in, what, like 1998, people have wanted search as good as Google's on their own website. And why wouldn't they? Google search is an absolute rock star. The minute it stepped onto the stage, it redefined the game. An entire SEO industry was born to bend websites to how Google works.

[00:01:35] But worst of all, with its deceptively simple UX, it's made it look easy to provide that level of quality. And for more than twenty years, the rest of us have been left to explain why we can't just make it work like Google. So there have, of course, been endless products trying to meet those standards, and traditionally most of them have been pale imitations of Google's keyword search.

[00:02:02] Don't get me wrong, though, we've found ways to make some of them pretty good, and some of the ones released in the last few years are actually really good. But using these products comes with a ton of overhead. And if you want to host them on your own platform, you need a bunch of infrastructure and the team to manage it. And you don't have to do that, of course. There's always the SaaS route if you're willing to pay monthly or annually and make the compromises for being on a multi-tenant system. But either way, with a bunch of tuning, like synonym dictionaries, stemming, and spelling correction, we can get to a pretty decent keyword-based site search.

[00:02:45] But here's the thing. Google wasn't sitting still while the rest of us were catching up. They redefined search again when they rolled out AI summaries in 2024, and the people love them. Well, okay, a lot of people hate them because they're summarizing other people's content, cannibalizing click-through rates, and killing the monetization of websites as we know it. But your users have quickly come to expect them, and that's because, let's be frank, no user ever actually wanted keyword search.

[00:03:19] If I search, "Why is my website slow?" I'm not looking for the webpage that matches the words why, website, and slow the most times. I want useful, meaningful content that actually answers my questions. Google actually doubled down on this just a couple of weeks ago when they announced what they called, quote, "The biggest change in search in twenty-five years." And that includes more generative AI features and conversational follow-ups on their AI summaries.

[00:03:51] So today I'm going to show you how you can provide valuable and meaningful AI site search to your users, with both AI-enhanced keyword results and summaries created from your own content. In the next thirty or so minutes, you'll walk away with a four-stage architecture for trustworthy AI search that doesn't rely on SaaS or new search infrastructure. And I'll show you a demo of it running on a toolkit we call Scolta. It's open source, it's on GitHub, and I think you'll be impressed with what it can do.

[00:04:33] But first, let's quickly take a look at the standard AI site search playbook so we know what we're comparing against. To be fair, this diagram's a little bit simplified, for the sake of the presentation, but in general, most AI search setups revolve around the vector database. Getting content into the vector database and having it return useful results is complex. It starts with figuring out the right strategy for splitting your content into small little pieces. That's called chunking. And then putting those chunks through the embedding pipeline to convert them to a mathematical representation that AI can work with, and then storing them as vectors.

[00:05:07] And that's the part that's supposed to capture meaning. The embedding model has been trained on massive amounts of text, so it learns that things like performance issues and site speed are related concepts, and it places them near each other in the vector space. Now, the vector database is more than just storage. It's also the search engine. So when the user search comes in, the vector database finds its closest matches, and that's actually the search happening: finding what's mathematically closest.

[00:05:42] If that sounds complicated, it is. It requires ongoing tuning and management. It's not set it and forget it. Every time your content changes, it has to be re-embedded, and new queries will surface edge cases. And without constant care and feeding, the system slowly degrades. All of these complex aspects of an AI search implementation are generally underestimated. Industry research consistently shows AI projects take longer and cost more than buyers expect. In fact, Gartner finds it takes eight months on average to go from AI prototype to production, and that's just measuring the projects that actually make it. Often, the operational tail isn't budgeted for at all.

[00:06:35] But here's the worst part. We probably actually don't need all this stuff. Vectors are right for massive data sets, like millions or billions of documents. But for the rest of us, for most of us, it's overkill. So why don't we explore something a little more practical?

[00:06:56] Let me introduce Scolta. And just to start, because people always ask, Scolta is an old Italian word for sentry, or the lookouts who stood watch on the medieval city walls and were trained to notice what was important. Scolta isn't really a product, and this definitely is not a sales pitch. Scolta is an open source, platform-agnostic toolkit developed by Tag1 to implement our practical, no-middleman approach to AI site search. You can do pretty much all of what I'm about to show you without it, but Scolta gives you a head start, and frankly, calling it by a name makes it a lot easier for me to talk about. So I'm going to refer to it as Scolta throughout the rest of this presentation, and if it helps, you can think of it as the Scolta technique or the Scolta playbook.

[00:07:57] So what is it that makes Scolta different? Unlike the traditional playbook, Scolta adds intelligence at search time, not at embedding time. It uses progressive enhancement across a four-stage architecture to layer configurable result scoring, ranking, and artificial intelligence on top of keyword search. And it delivers it all progressively as the user waits, because we all know that two seconds of watching something happen appears way faster than two seconds of staring at a spinner. So we'll talk about each stage individually, and then we'll circle back to this end-to-end overview of how it works.

[00:08:40] So the first stage, as I mentioned, is keyword search. Now, Scolta ships with PageFind integrated. But as I've said, this approach can work with whatever keyword engine you plug in. If you're unfamiliar with PageFind, it's been around for about four years, and we chose it for Scolta because, first of all, it's open source, which matches our ethos. But also it's incredibly efficient at indexing large collections of site content. Your site's index gets sharded into these highly compressed static assets.

[00:09:16] PageFind also hits a real configuration sweet spot. It has all of the BM25 fundamentals that you'd expect, like term frequency and saturation and things like that, but it also has sensible defaults that work out of the box. I like to explain it as configurable enough for serious tuning, but simple enough that you can ship it without a search engineer. And then there's some extra Scolta config that really takes it to the next level, but we'll touch more on that in stage three when we discuss merging and re-ranking your search results.

[00:09:55] Maybe the most important thing is that PageFind is specifically architected to not need custom infrastructure. It runs client-side in the user's browser via WebAssembly, and that client-side architecture unlocks some really great benefits. First of all, speed. WebAssembly runs at near native speed in the browser, and what that means practically is that it's much faster than any equivalent JavaScript library. And in addition, you skip all of the trips to the server and getting results back and the query at the database level itself.

[00:10:31] It's incredibly reliable, and it's incredibly scalable. The WebAssembly module itself and those index files that I mentioned before, they're all static assets. Think like your CSS files or something along those lines. And that means they can be cached and delivered by your CDN. And then once they're retrieved, they can be cached locally in your web browser. It's also cross-platform. A WebAssembly binary runs exactly the same on Chrome or Firefox or Safari or Edge. It works the same on Mac, Windows, Linux, even iOS and Android.

[00:11:11] It is also private by design. The keyword query is processed locally in the user's browser by the WebAssembly module. It's not transmitted to a server. So in addition to the local privacy, that actually allows us to interject some things in ways that we'll talk about in just a minute. But finally, financially, it means cost benefit. Because there's no search server to host, the only thing you're paying for is asset delivery from your website, which you're already paying for, and an LLM endpoint that you're probably already using. Or frankly, if you wanted to, you could choose to host that yourself and make the price almost nothing. In stage two, we're going to start talking about that LLM, so let's check it out.

[00:12:05] Stage two is query expansion. So what that means is that the user's search query is sent to your LLM of choice along with a specific prompt instructing the LLM to return two to four alternative queries. The goal here is to use the LLM to find what the user means, not just what they type. And this effectively gives you a major semantic win without the embedding pipeline. It bridges the intent gap that keyword-only search really misses. And this is because LLMs are really good at knowing terminology you don't, and this is especially useful with specific domain knowledge.

[00:12:47] So here's an example. One of our Scolta implementations is for a regional healthcare system. And if you search their platform for "my tummy hurts," query expansion returns the alternative searches stomach pain, gastroenterology, digestive symptoms: language that you are far more likely to find in their actual content. Query expansion's also configurable to your business's needs, because an LLM that's trained on the whole internet knows a lot of things. But remember, this is searching your site's content, so there's value in teaching the LLM about your brand-specific terminology. Think of things like your specific acronyms or your project codes.

[00:13:28] Or how about making sure certain things don't go to the LLM? You might be surprised to learn, or maybe you wouldn't be, just how much personally identifiable information people put into search boxes. So you might want to strip that out. We've talked about those privacy benefits of client-side search. Well, this stage is the first time the user's query leaves the browser, which means that you probably want to exert some control over what's allowed to cross that boundary.

[00:14:06] Stage three is where the expanded queries from the LLM get run back through PageFind, and then Scolta merges and re-ranks the keyword results. There are actually two ranking mechanisms in action with Scolta: the initial PageFind configurations that we talked about in stage one, and the Scolta layer ranking configuration. And that adds another opportunity for your business rules to improve the outcomes for your users. Basically, PageFind says, "These are the results that are mathematically relevant," and then Scolta comes in and adds, "And these are the ones that are appropriate for my site's content."

[00:14:48] There are numerous ranking knobs that you can turn. I won't list them all, but just to give you a sense of a few: there's title and content weighting, things like how important is finding your term in the title versus in the content. How much does it matter if you match all of the keywords instead of just one or two? There's recency: how much do you want to surface the newest content? You can imagine types of content where that matters a whole lot, something like events or the most updated tax laws. Something like your evergreen product documentation, that might not be so important.

[00:15:26] And speaking of different types of content, there are options for things like priority pages. An easy example, let me go back to that healthcare client I mentioned before: if you search their platform for a doctor's name, the doctor's full profile page needs to be at the top of the list no matter what. That's what priority pages do. There's even an expansion balance setting, and that's how much do you boost the rankings of content that matches the original search versus the AI's expanded queries.

[00:16:02] So like any search tuning, you can really go down this rabbit hole. I mentioned earlier that we really like PageFind's sensible defaults, so we felt that Scolta would be much improved and much easier if we added our own. So there are scoring presets for different types of sites. You can start from those presets, or you can start from the defaults. Either way, you can tweak the weightings to best suit your content. So if you're not quite sure what the impact is of, say, increasing your recency boost from 0.5 to 0.8, I would recommend you just try it. Just change it, run your search again, and see what's different. It's not like you have to put all your content back through an embedding pipeline and hope that the opaque vector math moves the right embeddings closer to each other. Heck, in most cases, you don't even actually have to re-index the content. So just try it.

[00:17:07] All right. Stage four is the AI summary generation. This is simultaneously one of the most exciting stages, and it's also where a lot of AI search implementations stall. In many vector-first implementations, they pipe the retrieved content into kind of a generic LLM call and hope for the best, and that can be really challenging to tune. Scolta's approach, no surprise, is quite different. It's architected specifically to produce summaries your users can trust.

[00:17:41] So first of all, the AI doesn't generate the summary from the LLM's training data. It rephrases the top search results from stage three. And what that means practically is that the summaries are bounded by your content, not by what the LLM happened to memorize. Additionally, the summary's governed by some really important rules. The most important one is no fabrication: don't make things up. Rules in the underlying prompts reiterate pretty much at every step that the only sources of information the LLM is allowed to summarize or cite are the search results. It specifically calls out never to use the training data alone.

[00:18:31] I mentioned citing sources. The summary is prompted to include inline citations pointing back to the source content. And first of all, this provides an immediate trust signal to your users. They can see where the summary gets its information, and they can really easily verify it. But you may know this already: requiring an LLM to cite sources is kind of a massive cheat code. It literally changes how the model generates its response, because you're telling it it has to go look things up, not just work from its memory and training data.

[00:19:04] Also, Scolta is allowed, well, actually encouraged, to say, "I don't know." Because Scolta's responses are grounded in your content and they're governed by that no-fabrication and cite-your-sources rules, it's actually quite likely that Scolta will have to negotiate some searches that don't have good results. So we encourage it to acknowledge that gap, even suggest alternative searches, but again, never to invent answers.

[00:19:43] What to do when there isn't a good answer is actually another excellent place for you to configure what's important to your business. On tag1.com, we point people to our contact page. That's what we want them to do if they can't find an answer to their question. Your recommended user journey might be really different.

[00:20:05] And speaking of places that it's important to customize, I highly recommend that you add behavioral guardrails appropriate to your company or your industry. There are rules in Scolta around using professional language and communicating directly and confidently, because LLMs tend to use a lot of hedging language. But it's important to consider whether they're guardrails you need in place. Don't forget that at the end of the day, you are inviting an LLM to speak for your business and for your brand, and you need controls.

[00:20:38] To go back to that healthcare customer, it's incredibly important that an LLM doesn't diagnose or recommend treatment as part of its summary. Because when all the LLM knows is "my tummy hurts," it's just as likely that I ate too many buffalo wings as it is that there's something terribly wrong with me. But the LLM can find valid content all over their site that says that a stomach ache is a symptom of appendicitis or pancreatitis or stomach cancer. So to put it plainly, they don't want their users jumping to the worst possible conclusion. That's what WebMD is for.

[00:21:15] All right, one more feature that I refer to as four plus, even though it's really part of stage four, but it really enhances your users' search experience. And that's that every query includes conversational follow-up, and that gives users the ability to dig deeper, ask questions, clarify, provide feedback. Each follow-up runs through the same four-step architecture that we just talked about but maintains the shared context of the search before. So all those same trust rules apply. It's also cost-controlled by design. You get to configure how many follow-ups are allowed, and the UI is really clear in letting the customer know.

[00:22:10] So let's quickly walk through those four stages one more time. Obviously, it starts when the user types a query. In stage one, PageFind runs the keyword search in the browser. In stage two, your LLM expands that into related searches. In stage three, your original results and the expanded results are merged together and then re-ranked using your business's rules. And in stage four, the AI summary is generated based on your content. End-to-end, that whole experience takes about 2.65 seconds, which means that Scolta does in two and a half seconds what it just took me fifteen minutes to talk about.

[00:23:00] All right, and that's enough talking about it. Why don't we see Scolta in action? Welcome to our Scolta demo site. It's called Fork and Find. As you can see, Fork and Find works differently than the usual recipe websites. It lets you search using plain language to describe what you're looking for and ask follow-up questions to change or refine your results. In full transparency, Fork and Find is built using WordPress. Scolta, like I said, is platform-agnostic, so that's not going to have any impact on the results that you see. But I'm bringing it up because, A, WordPress is one of the platforms that we've released an open source Scolta connector for, and also because I'll be using WordPress's native keyword search on the first couple of examples for the sake of comparison.

[00:23:58] All right, let's start with a few examples of the AI knowing words you might not, and using query expansion to help you out. I'm going to start with "meatless recipes" because I'm having guests over for dinner. And it doesn't find anything. That's probably because keyword search likes to combine the words. So let's go ahead and just try "meatless." All right, cool, we've got six results. You might notice that literally all of them specifically say meatless in the title or in the body. That's what we would expect. But let's go back and see what Scolta comes up with.

[00:24:32] All right, so I'm going to go ahead again and search "meatless recipes." And you can see with Scolta, I actually have four hundred and ninety-two recipes. And you can see up here the "also try these" little pills. That's actually the query expansion that we were talking about, and it suggests things like vegetarian meals and plant-based cooking. Again, words that make a ton of sense based on what I'm talking about, but we might not have thought to search for. And if I click on one of these, like vegetarian meals, I can actually dial in specifically to those results. And you can see three hundred and ninety results for vegetarian meals, including all of my expanded terms, including some like this recipe for veggie pizza, which doesn't actually say vegetarian anywhere in the recipe. The LLM just intuits it from the fact that there are no meat ingredients.

[00:25:27] All right, let's try WordPress one more time because I probably should have just searched vegetarian; that's a much more common term. And if I do it in the WordPress native search, you can see I get a hundred and two results, which is actually not too bad at all, but it's significantly less than what we found using Scolta. All right, let's go back. That was a pretty basic example. So let's go back and try something a little more complex. I'm going to use a term that includes a lot in it, and we're going to see if it can unpack the hierarchy.

[00:26:09] So if I go back to the native WordPress search here, I'm going to search for "traditional dishes from Southeast Asia." But we know that keyword search struggles when you use too many words, so I'm just going to search "Southeast Asia" and see what it comes up with. All right, I get three results. That's not bad, although it does seem like a few of these are really more inspired by Asian flavors than they are traditional Southeast Asian dishes. So let's go see what Scolta does with this. Scolta can handle a bit more of the context, so let's go ahead and try "traditional dishes from Southeast Asia." And notice how the LLM immediately unpacks that regional hierarchy. It's identifying various countries that are part of what we consider Southeast Asia, including Indonesian food, which I don't know that I've ever had before, and that sounds delicious.

[00:27:05] All right, super. You could argue, by the way, that I should probably be comparing this to something a little more enterprise, like a system like Elasticsearch, and that's fair. But I didn't want to pay for extra SaaS or infrastructure either, so we'll try a few more. Let's move on to a few examples where the AI is really illustrating that it understands what you mean. So I'm going to type, "I'm out of eggs. What can I still bake?" And instead of telling it exactly what I want, I told it what I don't have, and that's one of my constraints. And the LLM understands that "I'm out of eggs" means I'm looking for recipes without eggs in them. It inferred that constraint.

[00:27:51] And yeah, you might spot that the first keyword search is for a baked omelet that literally contains eight eggs, but that's a great example of the progressive enhancement in action. Scolta understood that as well, and it purposefully didn't surface it in the summary. There are ways that I can try to improve that at the keyword level as well. There are a lot of settings, as I said, and my PageFind settings are probably a bit too heavily indexed on the fact that it found multiple of my keywords in the recipe. So I can adjust that if I wanted to. But either way, the AI overview understood what I meant, and it filtered that out, even though it was the top result.

[00:28:39] Another one here for you: "recipes for someone just learning to cook." And I love this. Notice I never said easy. I just said someone learning to cook, and Scolta translated that, or the AI LLM translated that, into easy recipes all on its own. It surfaced terms that the user never typed, and then it's returning recipes appropriate to that skill level, like easy orange smoothie or easy nachos or easy scrambled eggs.

[00:29:12] One more, and this is my favorite for this section. We're going to do "crispy on the outside, soft on the inside." You might notice there are zero food words in that search. It's just textures. But the LLM helps Scolta really understand what that means, and because of that, it provides some really great recipes: crispy roast potatoes, crispy chicken burgers, things that really match that textural concept.

[00:29:50] All right, time for my favorites. Let's see some of the conversational follow-up in action. And this will allow us to combine a lot of the features from the previous examples. So we'll start with, "I need to use up overripe bananas." And as I search that, I get some really on-the-money nice results for baked goods. You can see banana bread and banana nut muffin and banana chocolate chip muffins. But unfortunately, as I mentioned earlier, I'm totally out of eggs. So let me go ahead and follow up: "Can I make any of those without eggs?"

[00:30:40] And you'll see that as the LLM sends that back out within the context of the original search, not only does it filter down those recipes for me, and I get some very naturally specific egg-free recipes, but it also provides me with some fantastic options for adapting my recipes to be egg-free. Things like mash banana into cooked oats, or substitute with flax eggs or commercial egg replacers. And that's just really helpful to somebody who is out of eggs.

[00:31:18] All right, let's do a couple more here. Let's do, "it's cold and I want something spicy for dinner to warm me up." Which is hilarious because it's actually 88 degrees in Boston today. But you can see it returns a really great diversity of options, and all of them are appropriate for dinner, and that's the AI helping us make judgment calls, meal planning decisions, not doing keyword batching.

[00:31:54] All right. "I like the idea of a soup, but it has to be vegetarian." We'll give the AI just a moment here, the LLM a moment to respond. So first of all, it limits the list to the two soups, and that's pretty obvious. But check out the details that it surfaced out of the chickpea soup recipe: if you swap the broth with vegetarian stock, it becomes a vegetarian dish, or a vegan dish. And that's really helpful. That's above and beyond just searching for things that are tagged with vegetarian.

[00:32:33] All right, one more here. "I'm in a rush. How long does it take to make?" And this is where it gets to bring in a little bit of its additional intelligence. Neither of these recipes give a time estimate for how long it actually takes to make. It doesn't say how long it takes to prep the ingredients or things like that. The LLM is able to estimate the prep time and adds it to the info that it does have, which is the simmering time. And it can clearly compare the two and say that if I'm in a rush, the spicy chickpea soup is my best bet because it only takes four or five minutes to make. For the record, I'm not really sure how good this soup would be.

[00:33:18] All right, last one, and this is one I actually really enjoy. "My son can't have gluten. What can I make for dessert?" Yeah, I said desert, and that's because dessert is literally one of those words that I always misspell, but the LLM's really good at compensating for that kind of thing. And you can see the query expansion really at work here as well. The LLM understands that not being able to have gluten means that you need celiac-safe recipes or wheat-free recipes. And because it understands that, in addition to things that are specifically mentioning gluten-free, it also offers up some recipes that are naturally gluten-free, things like apple tapioca.

[00:34:09] Some of these seem a little adventurous, so I should probably be a little more specific about what I'm looking for. "Which of these would a five-year-old actually eat?" And as you'll see, I actually really love this. The LLM understands the implications of the son being five, and it does a great job at narrowing down the list to recipes that are likely to be enjoyed by little kids. And that's just a wonderful example of some audience-specific reasoning that we're getting from the LLM. Look at "skip these for a picky five-year-old," including that apple tapioca recipe.

[00:34:54] All right, and we'll go a little bit deeper because he really likes to help, so I need to know which ones he can safely help me make. And the keyword here really is no trick. It's "safely." So it really zeros in on the chocolate chip cookies. And it specifically says which tasks are safe for the little kid to help: measuring the ingredients, mixing the dry ingredients with a spoon, things that kids truly love to do. But it also makes sure that I recognize I need to handle the oven and the knives and things like that. It even gives me a little extra bonus by saying there's no overmixing this recipe. So as a recipe, it is particularly forgiving for little kids.

[00:35:51] Awesome. So that's our demo. That's the examples of Scolta running real queries. So you're probably wondering two things: what does this cost for me to use, and how do I know it's working? So as we zoom in here to the end of our presentation, let's take those one by one.

[00:36:17] So with cost, first of all, it's important to realize that, like all of Scolta, cost works pretty differently from the standard playbook. With SaaS products, with vendor databases, things like that, you're paying just to have them. With Scolta, you pay specifically when users use it. And experience shows us that that's actually a lot cheaper than you probably think it is. To just give you a sense, I have been testing nightly Scolta builds for literally the last few months. I've run through the demo that I just showed you innumerable times, and through all of that, I've accrued less than 50 cents in token costs.

[00:37:06] If you want to try Scolta but you're not ready to commit budget to it, I think I mentioned this earlier, but it actually includes a free trial of the private AI gateway service from our friends at Amazee AI, which you can use out of the box to start to get a sense of the product. And as you use it, costs can be modeled using actuals. The easiest way is that your LLM dashboard will show you daily or monthly aggregates of the number of tokens that it used, and you can forecast simply by multiplying your LLM's token price by the amount of tokens used over a time period. There are no hidden costs or usage tiers or anything along those lines.

[00:37:52] In fact, to save costs, Scolta caches expanded queries by default for thirty days. And that actually has proven to be really powerful. After about a week of warm-up, we estimate that most implementations will see that about eighty percent of their queries are cache hits, not new queries. Because, as you probably know, people tend to search your site for the same thing over and over again. But if you need to, you can totally monitor your usage and set up any number of operational controls to manage those costs, things like rate limiting or queuing the queries. All of those can happen if you need to monitor a monthly budget or regular budget. Either way, no matter what, we actually recommend that you monitor, because in addition to managing cost, it's a great way to glean some intelligence from your usage patterns.

[00:38:49] In terms of analytics, this is probably not a surprise, but Scolta doesn't ship dashboards. It gives you search events, and you wire those events into the analytics tools that you already use. It's a tiny amount of code to glue it in there, just the same as adding a custom event in any analytics scenario. But then whatever analytics you already use become your search analytics. And that provides you some really cool signal. It measures things like what are your top queries? What queries are returning zero results, meaning what information are you not providing, or what questions are you not answering? The conversation depth: how many follow-ups does the average user need? If you find that every one of your users is maxing out their follow-ups, it's probably pretty indicative of a content problem.

[00:39:51] And you can even actually add in some custom code and add in some custom signal, things that allow you to go deeper. For example, on tag1.com we analyze sentiment for every one of our follow-up queries, because we want to evaluate if our site search is helping people or if it's frustrating them. That code's not in Scolta Core today. We're happy to share it if you want to reach out. But it's exactly the kind of thing that this sort of architecture invites you to build.

[00:40:25] So if you're thinking to yourself, "This looks pretty awesome, but there's no way I can eat this entire elephant in one bite," look, I totally get it. But I want to impress two things on you. First of all, I think you'll be surprised at how easy it is to implement Scolta. But second, if you're enhancing an existing search system, phased adoption is a totally legitimate approach. Remember, Scolta's whole thing is progressive enhancement. So if that's the direction that you want to follow, this is just the order of how we would recommend that you adopt the various different stages.

[00:41:11] So a few helpful links to help us finish up. Like I said at the very beginning, Scolta is completely platform-agnostic, but we have released a few open source connectors to make it even easier to integrate with platforms built on PHP or Drupal, WordPress, Laravel. For those of you who are deeply invested in your current keyword search solution, like I mentioned, Scolta's architectural approach of query expansion and result merging and AI summaries, that can all be applied to your current search. If you go to www.tag1.com/scolta, there are actually some self-guided demos on there that you are totally free to play with. So please feel free to go ahead and check those out, and you can contact us from there if you need any help.