One AI agent, two specialized roles: how Ven routes every customer turn

One customer identity, one router, and one owner per turn

The single-agent model protects continuity. A greeting can belong to Customer Support, the next message can reveal that the visitor needs an electrician, and Front Office can take over without changing the visible identity or forcing the customer into another flow. The transcript, visitor, channel, and active request remain shared context. What changes is the authority behind the response: the support role can use approved knowledge, while the operational role can use only the service and action permissions configured for it.

Customer Support is the broad conversational layer. It handles greetings, product or process questions covered by approved content, and safe handoff when the source set cannot support an answer. It never needs permission to alter a Service Request simply to explain how the business works. Its knowledge can grow from a minimal Starter Coverage pack into a full help center, but every answer remains bounded by content the workspace controls.

Separate knowledge and permissions for Support and Front Office

Front Office owns clear service intent. It matches the request against active catalog services, extracts only fields defined by the selected service template, and recommends the next operational state. In Qualify mode it may create a request for a confident match, record high-confidence answers, and send one catalog-approved clarification at a time. It cannot invent services, change corrected values silently, schedule work, or perform a handoff unless a later mode explicitly grants the required tool.

Starter Coverage prevents an awkward gap when a workspace enables Front Office before building a full support knowledge base. The starter material lets Ven greet the visitor, explain that it can help collect service details, ask enough to route the conversation, and acknowledge the transition. It deliberately does not answer product, price, policy, or availability questions. The Content screen makes that limited coverage visible so a business never mistakes minimum continuity for a configured support operation.

Starter Coverage keeps the handoff coherent without pretending to know everything

Deployment is controlled at two levels. A global schedule and channel list decide where Ven is available. Each role can then be set live or paused independently, with Front Office carrying its own autonomy level and service readiness checks. When Front Office is enabled without full support coverage, the setup flow recommends Starter Coverage rather than silently leaving general questions unanswered. The owner can still choose a narrower deployment and sees the consequence before saving it.

Deployment controls let a workspace expand role by role

This architecture makes expansion easier to reason about. New roles do not become separate bots competing for a conversation; they become specialized owners behind the same router. Each role receives the smallest knowledge and permission set it needs, every turn records why it was routed, and operators can inspect the result in the inbox. The measure of success is not how many roles exist. It is whether one customer message produces one accountable response and one safe next action.

Test the boundary with a five-turn role-routing script

Start a fresh visitor conversation with a greeting, then ask a general process question, then describe a supported service need. Confirm that Customer Support owns the first two turns and Front Office owns the service turn, while the customer continues to see one Ven identity and one uninterrupted transcript.

Next send an ambiguous service message and an unsupported product or price question. The ambiguous message should receive clarification without a random request being created. The unsupported question should use approved content when it exists or hand off cleanly; Starter Coverage must not invent an answer simply to keep the conversation automated.

Finally pause each role separately and repeat the script. The deployment screen should explain where the unanswered category will go, the audit should record the routing reason, and no two roles should publish from the same inbound message. This small test proves ownership more effectively than a long demonstration in which every question happens to be easy.