HOW SMART CANA CHATBOT GET?BUILD WHAT THE JOB NEEDS.

A chatbot can be a little box that repeats your business hours.

It can also identify the replacement part a customer actually needs, check whether it is in stock, prepare a quote, ask a person to approve it, update the CRM, and tell the customer what happens next.

Both are called chatbots. That word is doing a lot of unpaid labor.

The useful question is not, “Do we need a chatbot?” It is: What should this conversation be able to know, remember, and do?

In this episode of Super Intelligence, I break the build into practical levels. We start with a text conversation, add business knowledge, connect live product data, then look at memory, voice, an animated face, and agent functions. You can stop at the level your business needs. You can also add agent capabilities without giving the bot a face or a voice.

Here is what each level actually requires.

The short version: eight levels of capability

This is a capability ladder, not a package ladder. A text-only interface can use the full agent system. Voice and a face are presentation choices.

Level 1: Build the text conversation first

Text is the foundation because it gives us the cleanest place to define what the system knows, how it should behave, and where it must stop.

A useful text chatbot needs:

• A chat interface. The message window, text box, send control, conversation history, loading state, and accessible keyboard behavior.
• A private backend. The browser sends messages to your server. The server holds API credentials, applies rules, and calls the model. Secret keys do not belong in the public page.
• A language model. This can connect through OpenRouter or directly to a model provider. The model is one component, not the entire product.
• Instructions. The bot’s role, tone, scope, boundaries, response format, and escalation rules.
• Session context. Enough recent conversation for the bot to understand follow-up questions.
• Operational controls. Rate limits, input validation, timeouts, useful error messages, usage tracking, and tests.

The basic path is:

Visitor message → server rules → model → checked response → visitor

That creates a working conversation. It does not yet create a reliable representative of your business.

Level 2: Ground it in approved business knowledge

If the bot needs to answer questions about your services, policies, manuals, or company, those sources need to become part of the system.

The common pattern is retrieval-augmented generation, usually shortened to RAG. When a visitor asks a question, the application searches an approved knowledge collection, retrieves the most relevant material, and gives that material to the model as evidence for its answer.

That process requires:

1. A defined set of approved sources.
2. A way to extract and organize their content.
3. A search index that can find relevant passages.
4. Retrieval rules that respect permissions and document status.
5. Answer instructions that separate known facts from missing information.
6. Source references when the answer needs to be checked.
7. An update process for replacing stale material.

RAG does not magically make every answer true. It improves the evidence available to the model. The system still needs to reject unsupported claims, expose uncertainty, and hand off questions the sources cannot settle.

The grounded path becomes:

Visitor question → retrieve approved sources → model drafts from those sources → verify the answer → respond or escalate

That is already much more useful than a canned FAQ. It can answer questions people phrase in ways you never anticipated, while staying anchored to material you control.

Level 3: Help customers find the right product or part

This is one of the requests I hear most often from businesses with large catalogs: “Can the bot help someone find the part that actually fits?”

Yes, but product matching should not depend on semantic similarity alone. Similarity is excellent for finding candidates. Verified compatibility data determines whether something fits.

Imagine a customer asks:

“I need a replacement pump for this machine. Which one works?”

A responsible product specialist should:

1. Identify the equipment by model, serial number, year, dimensions, or another required identifier.
2. Search product names, descriptions, specifications, part numbers, and documented replacements.
3. Apply compatibility and fitment rules.
4. Check live inventory, price, and lead time through the store or ERP connection.
5. Explain why the recommended item matches.
6. Ask for missing information instead of guessing.
7. Link the correct product, create a cart or quote when supported, or hand the case to a specialist.

Different information belongs in different places:

This distinction matters. A model may notice that two pumps sound similar. It should not declare them compatible unless the records establish the match.

Level 4: Add memory carefully

Conversation history helps a bot understand the current visit. Persistent memory lets it recognize useful context later, such as a customer’s equipment, preferences, previous orders, or an unresolved support case.

Useful memory requires more than saving every message forever. It needs:

• A reliable visitor or customer identity.
• A defined list of facts the system may retain.
• Permission controls for who can read or change that information.
• Retention and deletion rules.
• A way to correct bad or outdated memories.
• Separation between confirmed facts and model-generated notes.

For a parts specialist, remembering a confirmed machine model can save time on the next visit. Remembering an unverified guess can create a very efficient wrong answer. Store facts with provenance and status.

Level 5: Add voice without rebuilding the brain

A voice assistant is the same core chatbot with speech added before and after the text reasoning path.

The processing path is:

Visitor speaks → speech recognition → chatbot and retrieval → response text → generated speech

The voice layer needs:

• Microphone permission, recording, mute, and clear listening indicators.
• Speech recognition that handles the names and terminology your customers use.
• Speech generation with the right voice, pronunciation, pacing, and tone.
• Audio playback that can start quickly and stop cleanly.
• Turn detection so the system knows when the visitor has finished.
• Interruption handling so the visitor can stop a long answer.
• Echo protection so the bot does not listen to itself and begin a meeting with its own voice.
• A text fallback when audio is unavailable, unwanted, or inappropriate.

Latency becomes part of the design. Transcription, retrieval, model reasoning, and speech generation all take time. Common answers can sometimes use approved prerecorded audio. Live answers need streaming and a response path designed for conversation rather than a long report.

Level 6: Give it a face

The face does not make the chatbot smarter. It gives the conversation a character, visible attention, and emotional cues.

For ACE, the face is a custom Three.js and WebGL system running in the browser. A comparable character needs:

• A visual design that can support mouth and expression movement.
• A renderer that performs well on the devices visitors actually use.
• Lip synchronization tied to the generated audio.
• Expression cues such as curious, amused, concerned, or thoughtful.
• Coordinated blinking, gaze, head movement, listening, thinking, speaking, and idle behavior.
• A graceful fallback when the face cannot render.

Audio amplitude can produce approximate mouth movement. Timed speech sounds can drive more precise mouth shapes. The audio and animation must share the same timing source, especially when different voices pace the same sentence differently.

If the face renderer fails, the chat and voice should remain available. A crisp still image is a better fallback than replacing the character with a technical error message.

Level 7: Put an agent behind the conversation

This is where the chatbot stops being only an answer box. It becomes the front end of an agent.

The customer still speaks or types naturally. Behind the interface, the agent can use defined tools to complete work. Those tools might include:

• Direct APIs for the CRM, store, inventory system, calendar, quoting tool, support desk, or another business platform.
• Zapier for workflows across supported applications.
• Telegram for updates and human approval outside the website.
• Email, SMS, or phone services for follow-up and notifications.
• Background jobs that continue after the visitor closes the chat.

A request might look like this:

“Find the compatible replacement, confirm stock, prepare a quote, send it to me for approval in Telegram, and update the CRM after I approve it.”

That workflow needs authentication, user permissions, validated tool inputs, approval before consequential actions, execution records, retry rules, duplicate protection, and clear status reporting.

The agent should not receive unlimited access and a motivational speech. Each tool should have a narrow job, defined inputs, and a clear authority boundary.

Level 8: Build the advanced system around the agent

Longer, higher-value work benefits from a layer that coordinates tasks instead of asking one model to improvise the whole process.

An advanced system can:

• Break a request into defined steps.
• Select different models or ordinary software for different jobs.
• Run independent checks before accepting an answer.
• Continue work in the background.
• Pause at approval checkpoints.
• Retry a bounded failure without creating an endless loop.
• Record cost, latency, sources, tool calls, and final status.
• Escalate with the conversation and work record attached.

The phrase Super Intelligent Bot is useful positioning. The actual product is a knowledgeable, connected agent with memory, tools, verification, and a good interface.

No cape is technically required. It does help with the launch video.

Controls every serious chatbot needs

Capability is only half the build. A customer-facing system also needs operating rules.

The bot also needs tests built from real questions, difficult edge cases, unsupported requests, conflicting records, and the phrases customers actually use. The goal is not a clever demo. It is predictable behavior when the visitor is vague, hurried, or wrong.

A practical build order

I would usually build in this order:

1. Define the business job, approved facts, boundaries, and handoff.
2. Build the text conversation and test the basic behavior.
3. Add business knowledge with sources and update controls.
4. Connect structured data and live systems only where the use case needs them.
5. Add memory with identity, permissions, and retention rules.
6. Add agent tools one at a time, beginning with read-only access where possible.
7. Add approvals, execution records, failure handling, and cost controls.
8. Add voice if speaking improves the experience.
9. Add a face if a character improves attention, trust, accessibility, or the brand experience.

Each phase should work as a finished product. That gives the business something useful sooner and makes failures easier to isolate.

You can walk through my customer chatbot workflow to see how business knowledge, live product data, model routing, verification, text, voice, expressions, and human handoff fit together.

What should your chatbot become?

Start with the conversation that matters.

What is the customer trying to accomplish? Which facts settle the answer? Which systems contain those facts? What can the bot do by itself, and what requires a person?

Answer those questions before choosing a face, a voice, or a favorite model. Then build the smallest complete version that solves the job.

If you have a catalog, service process, or customer conversation that should work better, tell me what you want the system to do. I design and build custom chatbots, agents, workflows, and the business connections around them.

You can also meet ACE on adamcagle.com and ask him about my services. He has opinions. Most of them are billable only after I agree.