Our AI Assistant Framework: What it is and why we built it

Every client conversation about AI assistants starts in roughly the same place. Someone has seen a demo, read an article, or watched a competitor launch something. The question they bring to us is usually some version of: should we build something, or just buy one of the tools that are out there?

It's a fair place to start. But it tends to get stuck on the wrong things - like cost or integration challenges before anyone has talked through what the system actually needs to do and what you're going to learn from it once it's live. Those are the questions that actually determine whether it's worth doing.

We've spent the last few years working through this with dozens and dozens of clients. Trying to figure out how AI might play a role in their digital experience and what it should look like. What we built came directly out of that work and out of deploying it on our own site first, which taught us things we didn't expect.

The AI Assistant Framework

The assistant itself is a React-based application that embeds directly inside your CMS environment. It’s not an iFrame or some third-party widget bolted onto the side of your site. It lives inside your CMS and behaves like it belongs there, and is something your content and operations teams can manage without filing a development ticket every time something needs to change.

The knowledge base pulls from two places: your published site content, indexed automatically, and any internal documents you want available - things like internal PDFs, FAQs, call scripts, internal reference material. Both are queried at inference time, which means the assistant is drawing on what you've actually published and approved, not reaching for whatever it can find.

Agent configuration like identity, role and behavioral boundaries is defined in plain language through a UI your team controls. You're not writing prompts. You're describing how the assistant should behave, what it should and shouldn't do, and how it should handle specific situations. Conversational flows for specific intents (i.e. a product recommendation path or support escalation) are structured the same way. The content team owns this and they can update it without touching code.

Every response surfaces citations at the bottom, essentially which documents or pages were referenced to generate the answer. It's how you reduce hallucination risk in a system that's going to represent your organization in real conversations. Grounding responses in indexed, known content and showing your work is the right way to run this.

On the technical side: hosted in your tenant, AI model is client-selected (GPT-4, GPT-4o, and others, it can be swapped and even degrade gracefully), authentication configured to your role and permissions structure, and structured database logging backed by your own security and data retention policies. Ongoing costs are Azure hosting plus token usage. That's it.

The Agent Analytics and Insights Framework

The analytics dashboard is a separate .NET application that runs alongside the assistant. It's independently deployable, but the two are designed to work together: the assistant generates the data, the dashboard tells you what to do with it.

What it surfaces: conversation volume, resolution rates, average session length, sentiment across interactions (positive, neutral, negative, mixed), and outcome classification - whether a conversation was handled, deflected, failed, or escalated. Intent and topic tracking gives you an aggregated view of what people are actually asking about. Goal tracking lets you define completion targets and measure against them over time.

The piece most organizations underestimate is conversation flagging, the ability to pull unresolved conversations, escalations, and content-filtered interactions into a review queue. For organizations in regulated environments that need an audit trail, this is really a requirements and for everyone else, it's where a ton of useful signals live.

Search and filtering across the full conversation history by keyword, date range, sentiment, outcome means you can do both operational review and compliance spot-checking from the same interface.

What We Learned Running It on Our Own Site

The assistant on our site runs on the same framework. We deployed it on bluemodus.com before we deployed it anywhere else, because that was the fastest way to understand what we were actually building.

What it surfaced wasn't what I expected. I'm not talking about traffic patterns or engagement rates. I'm talking about questions. What people actually come to the site trying to figure out. Where they arrive and leave without finding what they came for. What they need that we weren't providing.

Analytics can tell you a lot about behavior. Conversation logs tell you intent stated directly, in the visitor's own words. That's a different kind of data point that we haven't really had before. Once you have it, it changes how you think about your content. We found gaps we didn't know existed. Topics we were underserving. We found lots of opportunities to improve our content and help our clients and prospects in better ways.

Why Not Custom

We know we could build fully custom AI assistants for every client from scratch. We have the capability and we've done it. But a comparable custom build runs 5–10x what we charge for the framework, and for most organizations at the stage they're actually at with AI, that investment is too hard to justify. You're asking them to make a significant bet before they've fully operationalized the thing they're betting on.

The framework gives clients a production-ready system without the timeline and cost of a ground-up build. For our clients, is enabling them to test the waters with AI with a safe, grounded framework (that they own) without a crazy investment.

Why Not SaaS

The SaaS platforms have gotten genuinely good. I'm not dismissing them. But the fundamental problem is structural: your configuration lives in someone else's system and when the vendor changes pricing or deprecates a feature - and this happens - you're the one stuck with a leased system.

Our clients have invested years in their digital infrastructure. A manufacturing company managing complex product content, a credit union with strict data governance requirements, an association with a membership base that expects a certain level of trust - none of them should be building a core audience touchpoint on a foundation they don't control.

Why a Framework

The framework is a middle path that doesn't get talked about enough. Production-ready scaffolding, delivered as source code, running in your environment under your security policies. You own it outright.

If our engagement ends, the system keeps running. Your team can maintain it, extend it, hand it to another partner. There's no licensing fee tied to whether the lights stay on.

Why This Model Works for our Client Relationships

BlueModus started because I believe that if you build relationships well, the business takes care of itself. That's not some grand positioning statement. It's simpler than that - it's the reason the company exists and it shapes how we build things.

The framework model reflects that directly. We know that for most of our clients a giant custom investment in AI isn’t a reality with their budgets. We also know that onboarding a new vendor to test something out could take months. But all of them are seeing that they need to do something with AI. They need to experiment and see if agentic interactions are something their end users want and expect.

We believe our framework serves a unique purpose here. It’s allowing our clients to try new technology and new experiences. And it’s allowing them to learn and adjust from them.

Obviously, this is also good for us. For most of our clients, the deployment is the beginning of something, not the deliverable. The content gaps the logs surface, the flows that need refinement as your audience's needs shift, the analytics that go from interesting to actually useful - that's the ongoing work. That's where the relationship lives.

We built this so clients can run it independently. The ones who get the most out of it are the ones who stay in the conversation after launch. Not because they have to, but because there's more to do, and it's worth doing.

Ultimately, If you're working through whether something like this makes sense for your organization, I'd rather you reach out too early than too late. Maybe now isn’t the time. Or maybe a big custom investment (or a SaaS bolt-on) make sense. Mostly, we just want to make sure you are able to make the right decision for you. And for our clients, increasingly a robust tool that they own and can build on is the answer.

The assistant on our site is live. Chat icon, lower right corner (and yes, we read the logs).