Talk to customers in their language
Optional. Listening and speaking are included only when voice is part of the agreed scope.
A customer can ask a question aloud in a supported language and hear the answer in that language. The assistant can use your approved information and pass the conversation to your team when needed. We agree which languages and channels to support, then test them with your customers’ terminology.
Discover technical details about voice
How it is built
Three designs are valid. The project uses one of them, only where the chosen provider supports it. A text model is not treated as a native voice model unless its current documentation says it accepts live audio. This is a customer speaking with the assistant in a supported language. It is not a live interpreter translating between two people. Not every language, accent, provider, or phone connection is available.
Direct voice. One speech-to-speech or live model listens and speaks in the same session, and can also do the reasoning when the provider documents that. Turn-taking and interruption can feel more natural. Provider support varies.
- Getting started with the Realtime API, OpenAI API
- GPT-Realtime-2.1 model, OpenAI API
- Gemini Live API overview. This page documents multilingual conversation and interruption.
- Getting started with Amazon Nova 2 Sonic speech-to-speech
- Microsoft Voice Live API overview
A hybrid live conversation. Getting started with GPT-Live, OpenAI API describes a spoken conversation that continues while a separately chosen backend handles the business task. GPT-Live listens and speaks. The backend model or agent looks up approved information, follows the playbooks, and uses tools. Delegation and tools in GPT-Live is the guide for that split. The backend does not have to be a voice model, so this design keeps the wider choice of reasoning models used for text.
A modular pipeline: speech recognition, then the selected text model and business workflow, then speech generation. Recognition turns speech into text. The text model and the same playbooks, knowledge, and approval rules used in chat prepare the reply. A separate voice then speaks it. This also keeps a wider choice of reasoning models, including models that do not handle audio themselves. Latency and interruption handling are usually less seamless than a live API.
ElevenLabs Agents overview describes a voice-agent platform and a voice option for this kind of design. ElevenLabs language configuration sets the languages that agent can use. ElevenLabs language detection is the separate guide for switching language during a conversation. Neither page is evidence that every language model behind the agent accepts audio directly.
Languages and switching
Multilingual support and language switching are different commitments. Multilingual support means the assistant can answer in a language agreed for the project. The customer may choose that language at the start, and the conversation stays in it. Language switching means the customer can change language during the same conversation. Switching is included only when that behaviour is configured and tested. Listing more than one language does not, by itself, turn switching on.
What can go wrong
- A language, accent, or product term the provider has not been tested on is misheard or spoken poorly.
- The customer cannot interrupt, or the assistant talks over them, because interruption handling was not part of the chosen API.
- The phone path, the browser, and the app do not behave the same way. A phone channel in particular is a separate connection, not a default.
- A native voice model answers from general speech behaviour instead of the approved knowledge, or a tool call speaks a change that a person was supposed to approve.
- A recording or transcript is kept without a retention rule, or the microphone starts before the customer has agreed.
What we decide together
- Browser, app, telephony, or more than one of those. Phone is included only when that connection is in scope.
- Which languages are supported, whether the customer chooses one at the start, and, separately, whether they can switch during the conversation.
- Captions and transcripts: whether the customer sees the words, and who can read them later.
- Interruption handling and the latency the channel has to meet.
- The same approved knowledge and the same permission rules as text, where the selected architecture supports them. A consequential action still waits for a person.
- Microphone consent, and how long a recording or transcript is kept, corrected, or deleted.
- A test set in the client languages, using the terminology customers actually say.
A sample conversation, from an answer to a handoff
Harbour and Pine is a fictional garden-delivery shop created for this page. It is not a client, and the delivery note is sample text. Nothing here is sent to a real dispatch desk.
1. A question answered from an approved source
Customer
Do you deliver to Bristol, and what is the cutoff for a Saturday drop-off?
Harbour and Pine assistant
Yes. The approved delivery note says Bristol is on the weekly route. A Saturday drop-off needs the order placed before 2pm on Thursday.
Source: Harbour and Pine delivery note, sample page 2, marked approved 12 March 2026. Fictional text written for this example.
I do not have the live van schedule, so I cannot confirm a time window. If the note does not cover a place, I should say so instead of guessing.
2. A change prepared for a person to review
Customer
Please move order HP-1842 to Saturday.
Harbour and Pine assistant
I can prepare that request for the dispatch desk. I will not change the order from this chat.
Not sent · waiting for a person
Request prepared for review
- Order
- HP-1842
- Ask
- Move delivery to Saturday
- Reason
- Customer asked in chat
- Status
- Waiting for a person to approve
White-label preview
A picture of how a finished chatbot can look under a company name. Change the sample name and accent colour to see the frame update. The exchanges below use the same fictional shop, including two short voice recordings.
Illustrative preview. This uses sample data for a fictional company. It does not contact live customer systems, save a preference, send a message, or change an order. Editing the name or colour only changes what you see in this browser.
These are written examples. They do not call a live assistant.
Sample address https://chat.example.com
Sourced answer
Customer
Can I return an unused pot within 30 days?
Assistant
Yes. The sample returns note says an unused pot can be returned within 30 days of delivery, with the receipt. Cracked or planted pots are listed as not returnable.
Source: Harbour and Pine returns note, fictional sample. If the note does not cover the item, the assistant should say it does not know.
Approval handoff
Customer
Please send a replacement for order HP-1842. The pot arrived cracked.
Assistant
I can draft that for the shop to review. I am not sending a replacement from this chat.
Draft only · not submitted
Replacement draft for review
- Order
- HP-1842
- Draft
- Customer reports a cracked pot and asks for a replacement
- Next step
- A person at Harbour and Pine approves or declines
Opt-in memory preference
Customer
Please remember that I prefer the side gate, not the front door.
Assistant
I can keep that for next time only if you want me to. That note would be separate from the delivery policy and separate from this conversation. You could ask for it to be corrected or deleted. This preview will not store it.
No preference has been stored. These buttons only change this sample sentence.
English sample · illustrative recording
Customer. Do you deliver to Bristol on Saturday?
Assistant. Yes. Bristol is on the weekly route. A Saturday drop-off needs the order before 2pm on Thursday.
Spanish sample · illustrative recording
Customer. ¿Entregan en Bristol el sábado?
Assistant. Sí. Bristol está en la ruta semanal. Para el sábado, haga el pedido antes de las dos de la tarde del jueves.
Illustrative recordings. These clips use sample voices for the fictional shop Harbour and Pine. The written lines are the same words as the audio. Pressing play does not listen to this browser, call an assistant, or contact a customer system.
https://chat.example.com is a picture of an address. example.com is reserved for examples and is not your website. This preview does not open that address and does not contact a customer system.
Branding and deployment can be adapted to an agreed company subdomain, a path on an existing site, an embedded widget, or an application. Which of those is realistic depends on the client infrastructure and is settled in the project, not assumed up front.
How it works
Each step starts with the buyer version. Open it for the technical note.
- Agree who the chatbot is for, and which jobs it may handle.
- Choose the approved sources it may use, and what it should do when those sources do not answer the question.
- Decide which connections, playbooks, and memory rules are in scope.
- Choose a model provider whose capabilities and terms fit the project.
- Test answers, citations, missing-source behaviour, and the points where a person must approve.
- Deploy on the agreed address, then hand over operation, access, and how to change the sources.
Answers from approved material
Before the chatbot writes a reply, it looks up passages from material you have approved and uses those passages as the context for the answer. Citations, and what happens when nothing relevant is found, are designed and then tested. The lookup cannot promise that the answer is correct: a passage can be old, incomplete, or applied to the wrong question.
Discover technical details about retrieval-augmented generation
This pattern is called retrieval-augmented generation, or RAG. A retrieval step selects relevant approved material and supplies it to the model as context. It does not give the model a new store of guaranteed facts. Citation format and fallback behaviour, including a refusal or a handoff when retrieval finds nothing useful, are product decisions. RAG cannot guarantee correctness.
A public explanation of the idea: What is retrieval-augmented generation, AWS Prescriptive Guidance.
Connected tools
A tool is a constrained connection to an application, not a general permission to use the business. The project names the tools that exist. Reading a record, drafting a change, and executing a consequential action are separated, and a person approves the consequential ones unless the scope explicitly says otherwise.
Discover technical details about tools
In this design the application defines the tools. The model can ask to use a tool; it does not receive open access to inboxes, databases, or payment systems. Permissions decide which tool calls exist at all.
- Reading data returns information, such as an order status, and does not change it.
- Drafting a change prepares a message or a record for a person to review.
- Executing a consequential action sends, pays, refunds, or writes to another system. That waits for human approval unless the agreed scope says otherwise.
One vendor description of the same general pattern: How tool use works, Claude platform documentation. A Tyon project uses the tools the scope permits, whichever model provider is chosen.
Skills as playbooks
A skill packages how a job should be done: the instructions, a few examples, the resources to consult, and the rules for when to stop. Teams reuse that playbook instead of re-explaining the job in every conversation. It can be combined with tools the project has already permitted. It is not a switch that makes the model newly capable.
Discover technical details about skills
Technically, a skill is reusable instructions, examples, resources, and workflow rules. It may call the tools that are allowed for that job. It is not a magic model capability, and it does not override an approval rule or a permission.
One public description of this packaging: Agent skills overview, Claude platform documentation. That page is an example of the idea. Using it as a reference does not mean a project includes that vendor product.
Memory, kept separate from company knowledge
There are three different stores. The current chat is the conversation happening now. Optional persistent memory is a note a person agrees to keep for later, such as a delivery preference. The company knowledge base is approved business material, and it is not a record of one customer. Retention, who can access a stored note, how someone corrects it, and how it is deleted are explicit design decisions. They are not side effects to discover after launch.
Discover technical details about memory
Current-chat context lives for that conversation and follows the retention rule you set for transcripts. Persistent memory, if it is in scope, is a separate store with its own access and deletion path. The knowledge base used for retrieval is a third store. Putting a customer preference into the company knowledge base, or treating a policy document as personal memory, mixes those stores and should be rejected in design.
These public documents show how different products describe memory. They are references, not a statement that a project includes those products:
Model choice
The chatbot does not have to be locked to one AI company. A later model change is a supported migration: the application can stay in place only after compatibility checks and testing. Providers do not offer the same features, and their contracts and data terms differ. The choice belongs in the project scope, next to the job the chatbot has to do.
Discover technical details about model choice
The architecture is model agnostic where the application layer is separate from the provider. That separation does not make providers interchangeable. Context limits, tool support, data processing terms, latency, and price all differ, and they are checked for the specific build.
Suitable providers can include Claude, OpenAI API models used in ChatGPT, DeepSeek, Gemini, and others. Current catalogues:
Images and video, only if they are in scope
Pictures and video are not part of the text chatbot unless the project asks for them. They use separate services. Whether a service is available, and what it costs, is checked for that build. They are not assumed to be included.
Discover technical details about image and video APIs
Image generation and video generation are optional API integrations, separate from retrieval, tools, skills, and memory. Availability, moderation rules, and cost are provider-specific and are confirmed before they are added. Two current references:
What the project has to decide
This page is a proposal and a reference. It is not a quote, and it does not mean every option is included. A timeline is not a commitment until scope, access, and dependencies are confirmed.
Audience
Who talks to the chatbot: customers, staff, or a narrower group. What they are allowed to ask, and what must go straight to a person.
Knowledge sources
Which approved documents, pages, or records may be retrieved, who may update them, and how an old source is retired. See RAG chatbot development for the retrieval service in more detail.
Integrations
Which systems may be read, which may only be drafted into, and which consequential actions exist at all. Access has to be granted by the client. A missing login or API is a dependency, not a detail to improvise later.
Skills
Which playbooks are in the first release, who owns the wording, and what the chatbot must refuse. Related patterns are on custom AI chatbot development and the AI automation use cases.
Memory policy
Whether persistent memory exists. If it does: what may be stored, for how long, who can read it, how a person corrects it, and how it is deleted. Transcripts of the current chat need their own retention rule.
Provider choice
Which model provider fits the job, the data terms, and the budget. Image or video APIs are a separate decision. Provider terms are part of the agreement, not a default.
Voice and languages
Optional. Which languages the assistant may answer in, which voice, and whether customers talk on the website, in an app, or by phone. Choosing a language at the start and switching language during the conversation are separate decisions. This is a customer speaking with the assistant in a supported language, not a live interpreter between two people. The languages, voice, channel, and privacy rules are chosen and tested. Not every language, accent, provider, or phone connection is available.
Domain and hosting
Where the chatbot appears, and where the conversation data lives. A subdomain, a path, a widget, or an application are options to examine against the client infrastructure. Security and data handling describes how Tyon talks about access, deployment, and what it does not certify. Agencies comparing a reseller platform can read white-label AI agents, which is a different offer from this page.
Approval points
Which actions a person must confirm, who that person is, and what the chatbot may say while it waits. The sample conversation above is the shape of that handoff, not a feature already switched on.
Testing
Which questions must be answered from a named source, which must fall back, and which drafts must not be sent. Testing uses agreed material. It does not prove that every future question will be right.
Handover
Who can edit sources, playbooks, and access after launch, and how a change is reviewed. Handover is part of the scope. It is not an unbounded support promise.
Two worked examples of adjacent workflows, not case-study results for this offer: service business intake assistant and SaaS support documentation copilot. Commercial options are described on pricing. To talk through a chatbot for your own business, contact Tyon.
Questions buyers ask
Common questions.
Is this only our logo on a generic chatbot?
No. The aim is a chatbot that uses material you approve, rules you agree, and your brand. Putting a logo on a public chatbot does not add your knowledge or your approval steps. What is actually built is the project scope, not this page.
Will it know our products and policies?
It can answer from sources you approve, and it can show the source when citations are part of the design. It cannot promise every answer is correct. If the source is missing, old, or unclear, the fallback is designed and tested. That may be a refusal or a handoff, rather than a guess.
Can it change orders or send email by itself?
Only connections that are in scope exist. Looking something up, drafting a change, and carrying out a change are separated. Sending email, editing an order, or writing to another system is a consequential action and should wait for the approval point you agree.
What is a skill, in practice?
A skill is a playbook your team can reuse: instructions, examples, resources, and rules, sometimes together with a tool you have permitted. An example is “answer a delivery question from the delivery note, and prepare a change request instead of editing the order.” It is not an extra intelligence switched on inside the model.
Will it remember our customers?
Only if persistent memory is in scope. That store is separate from the current chat and from the company knowledge base. Retention, access, correction, and deletion have to be written down. The preview on this page does not store anything.
Which AI company does it use?
The application can be model agnostic, so it is not built for a single vendor only. Claude, OpenAI API models used in ChatGPT, DeepSeek, Gemini, and other suitable providers can be evaluated. Their capabilities and terms differ. The provider is chosen for the build. Changing it later is a supported migration and needs compatibility checks and testing. Image and video generation are separate optional APIs, and their availability and cost are checked if they are requested. They are not included by default.
Where will people see it?
On an address and in a form you agree: a company subdomain, a path, an embedded widget, or an application, subject to your infrastructure. The sample address on this page uses example.com, which is reserved for documentation and is not a deployment.
Can the chatbot speak with customers in different languages?
Yes, for supported languages, when voice is included in the scope. A customer can ask aloud and hear the answer in one of those languages. Supporting a language is separate from letting the customer switch language during the same conversation. It does not translate live between two speakers. Quality and availability are tested for the chosen provider and channel. Not every language, accent, provider, or phone connection is part of that test.
How long does it take, and what does it cost?
There is no single timeline and no price on this page. Both depend on audience, sources, integrations, approvals, access, and review cycles. Pricing describes commercial options. A date is not a commitment until scope, access, and dependencies are confirmed. Contact Tyon with the workflow you have in mind.
Is the preview on this page a live chatbot?
No. It is an illustration with sample data for the fictional company Harbour and Pine. Changing the sample name or colour only changes this page in your browser. It does not contact customer systems, and the scripted replies were written for the example.