This Conversational System

The Problem

Most company websites are brochures. We built ours as a live product demo.

The standard approach to demonstrating AI capability is a deck, a demo video, or a "book a call to see it in action" gate. None of those let a prospect experience the product before committing time. We needed visitors to interact with a working AI system the moment they land on the site.

What We Built

The conversational system at /ask is a full AI workflow implementation. Not a chatbot wrapper around a language model. A purpose-built system with structured knowledge, tool calling, streaming responses, and quality controls.

Multi-layer prompt architecture: The system prompt is assembled from structured JSON content, behavioral rules, tool definitions, and response templates. Not a single monolithic prompt — a composable architecture that separates personality, knowledge, capabilities, and guardrails.

Six tool-calling functions: The AI agent can invoke portfolio search, case study retrieval, capability lookup, conversation scheduling, chart rendering, and knowledge base search. Each tool has defined inputs, outputs, and error handling. The agent decides when and how to use them based on conversation context.

17-article knowledge base: Markdown articles covering services, methodology, manufacturing depth, case studies, and frequently asked questions. Searchable by the agent at runtime. Real operational knowledge, not generated filler.

SSE streaming with typed events: Server-sent events deliver thinking indicators, text content, chart data, contact forms, and error states as distinct typed message streams. The frontend renders each event type differently — no polling, no artificial delays.

Default response caching: Pre-built responses for the 20 most common questions, streamed word-by-word. Faster than API calls for frequent queries. Every cached response is manually reviewed for accuracy and honesty.

Architecture & Approach

The system runs on Next.js API routes with the Claude API. The architecture follows the same five-step methodology we use for client implementations:

1. **Design:** Mapped the visitor journey — what questions do prospects ask, in what order, and what response quality convinces them to take a next step.

2. **Build:** Multi-layer prompt system, tool definitions, knowledge base structure, streaming infrastructure, default response library.

3. **Test:** Ran hundreds of queries across different visitor personas — manufacturers, services firms, skeptics, technical evaluators, executives. Tuned response quality at every layer.

4. **Deploy:** Production deployment on Vercel with rate limiting, error handling, and monitoring.

5. **Retain:** Ongoing optimization based on actual visitor queries. Questions that surface gaps in the knowledge base become new articles.

The API route handles the full lifecycle: receives conversation history, constructs the system prompt from structured content, calls Claude with streaming enabled, and returns typed SSE events to the client. The API key never touches the browser.

What This Proves

This system handles open-ended business conversations, invokes tools based on context, renders structured data, and guides visitors toward next steps — all without a human in the loop. It is the same architecture pattern we build for client applications: CRM intelligence, customer-facing AI assistants, internal knowledge systems, workflow automation.

The difference between this and a chatbot is the difference between a workflow and a widget. The prompt architecture, tool integration, knowledge structure, and quality controls are what make it useful instead of impressive-looking.

Try /ask to see it in action.