Conviro is the AI customer-support platform I designed, built, and operate as its sole engineer. It brings web chat, WhatsApp, and Instagram into a shared support workflow, with a knowledge base, AI assistance, and handoff to a person.
My responsibility includes the backend, integrations, deployment, and the behavior customers encounter after a release. That has shaped how I evaluate the system: a convincing answer is only one part of a successful support interaction.
A conversation crosses several boundaries
An incoming message belongs to a tenant and a channel. It needs to be accepted reliably, associated with the right conversation, and processed under that tenant’s permissions and usage policy.
If AI is involved, the request then crosses retrieval, model routing, response validation, and delivery. Any of those stages can fail independently. A provider can be unavailable while the inbox remains healthy. A source can be irrelevant while the model itself responds successfully.
I therefore keep those states visible in the architecture. A received message, a generated answer, and a delivered answer are separate facts. Treating them as one status would hide the information needed to recover an interrupted conversation.
Retrieval quality changes the answer more than polished wording
Conviro uses PostgreSQL and pgvector for hybrid retrieval, combining dense search with full-text signals and reranking. The purpose is to retrieve useful evidence across the wording and language differences that appear in real support conversations.
I also built a post-generation grounding validator for concrete claims such as links, prices, product identifiers, and warranty terms. The validator checks claims against the retrieved material and applies stricter behavior where unsupported commerce information could mislead a customer.
These checks have limits. A validator can miss a semantic error, and an outdated source can be consistently reproduced. I use evaluation cases and source management alongside validation; no individual component proves that every answer is correct.
Provider flexibility needs a consistent policy
The LLM layer supports multiple vendors through a shared adapter contract. Routing considers the task, quality mode, and configured data region, with fallback behavior and circuit breakers around provider failures.
One concrete boundary mattered enough to change: the internal assistant received its own circuit breaker so its failures would not unnecessarily fail customer chat. That is the kind of detail that appears when the system is operated as a product rather than demonstrated as a single request.
Usage accounting and tenant budgets sit alongside routing. A fallback should preserve the customer’s policy and spending constraints. Reliability does not mean continuing to call providers without regard to those limits.
Tool use makes authorization part of the AI path
The support copilot plans a turn as a structured choice: use a tool, answer, ask for clarification, or decline. Tools carry permission and risk information, and execution is authorized on the server against the user’s role.
The initial execution scope is read-only. Tool results are redacted before they reach the model, and the turn has a bounded budget and an audit trail. These boundaries let the application remain in control even when the planner proposes an unsuitable action.
For asynchronous work, transactional outbox records, broker redelivery, idempotent consumers, and dead-letter handling address different parts of the delivery lifecycle. I do not rely on a queue alone to make a business operation safe to repeat.
Ownership continues after the code is written
Building the platform alone makes operational clarity especially valuable. When something fails, I need to determine which tenant and request were affected, which stage failed, whether any external action completed, and which recovery action is safe.
I evaluate through the production router and validation path, maintain regression checks, and keep deployment and rollback behavior part of the engineering work. The application is a combination of model behavior and ordinary software boundaries; both need attention.
More about the product is available at useconviro.com. The engineering questions I continue to work on are practical ones: how to expose uncertainty, how to grant useful autonomy, and how to recover safely when a dependency or an assumption fails.
Updated 25 September 2026.