Context
A business that puts an AI agent in front of customers — on the phone, in a web widget or on a messaging channel — needs three things at once: answers that come from its own approved material, actions that actually happen (a booking, an order, a quote) and a way to prove, before launch and every week after, that the agent stays inside its boundaries.
The hard part is not the first demo. It is running the same runtime for many different businesses, each with its own knowledge, tools and audience, and keeping the whole thing measurable: what the agent answered, what it did, what it cost and whether the conversation was actually resolved.
What we built
One runtime serves many business profiles. Each profile declares its identity, boundaries, knowledge collection, allowed tools and audience (public or internal), so a dental clinic, a hotel and a B2B sales desk run on the same code with different configurations.
- Grounded retrieval — documents are chunked and embedded into a vector store per profile, retrieved using score thresholds, and assigned public or internal visibility, so an internal agent can see margins and a customer-facing one cannot.
- Tool execution — intent routing, tool planning and an iterative executor with hard caps on calls and iterations, so a booking or an order is a real, bounded action rather than a hallucinated confirmation.
- Customer memory with provenance — every remembered fact records its source and intended audience, is filtered per agent, and is injected as explicitly untrusted quoted data, so recall never becomes an instruction channel.
- Simulation and QA — LLM personas talk to the real chat runtime and are scored by an LLM judge plus deterministic leak detectors (system prompt, tool schemas, credentials, internal figures) that no persuasive answer can override; a QA dashboard scores live conversations the same way.
- Outcome metering — conversations are classified deterministically as resolved or escalated and priced accordingly, so pay-per-resolution billing is reproducible, alongside cost imports from every provider.
- Agent-to-agent over MCP — the business agent exposes its tools through a Model Context Protocol server, so another assistant can negotiate a booking through the same interface, within call, turn and time caps.
Stack
TypeScript on Node with Fastify and WebSockets, React and Vite for the operator console, Postgres with Prisma for conversations and cost data, Qdrant for vectors with local embeddings, and one LLM provider interface with hosted APIs, local models and CLI agents behind it. Voice runs through several realtime runtimes (telephony, WebRTC and browser speech) with provider-agnostic speech-to-text and text-to-speech. An extensive unit test suite blocks live provider calls by default.
Status
Internal product, used as the base for client agent deployments. A live demo across several business verticals is available on request.