Adult language practice with a Kasamila conversation partner

A browser pilot for clarifying a changed meeting time and confirming the next step

A learner can recognize every word in a lesson and still hesitate when a colleague says, “Could we move our meeting?” The useful skill is more than producing a correct sentence. The learner needs to notice the change, ask about missing details and confirm what both people have agreed.

For an adult language provider, this is a focused place to explore a conversational avatar. Build a short practice task around an observable outcome, then test whether seeing a speaking partner adds anything to the same exercise delivered through voice alone. Kasamila would supply the browser avatar layer. The learning application and its educators would still own the lesson, dialogue rules and feedback.

This article proposes a pilot, not an existing Kasamila course, customer deployment or evidence of learning improvement. It uses fictional workplace details and excludes formal assessment, employment decisions and certification.

Start with a communication task

An open-ended conversation can be enjoyable but difficult to evaluate. A learner may speak for several minutes without resolving the misunderstanding. A tightly scripted drill has the opposite problem: repeating a model answer does not show whether the learner can handle a small change.

Choose one scenario: two colleagues need to reschedule a meeting. The fictional task card states the original time, two available alternatives and a location. The partner introduces one change. The learner must establish the new time and location, check one ambiguous detail and give a final confirmation. The application should accept different valid phrasings rather than demand one sentence.

This short practice activity can sit within a broader teacher-designed, action-oriented scenario. The Council of Europe describes purposeful language use and learner agency, while its assessment guidance uses descriptors to inform reflection on what learners can do. These ideas support a transparent practice rubric, not a claim that an AI avatar improves learning or provides a valid CEFR score. [4][5]

An educator should define the target language level, acceptable responses and difficulty before development. Keep a small set of reviewed variants. Do not allow a generated partner to introduce conflicting facts simply to keep the conversation going.

Follow the learner through one attempt

The opening screen explains the practice goal, identifies the partner as AI and offers text or voice participation. A brief audio check happens before a billable avatar session is created. The learner can inspect a plain task card and decide whether to start. Microphone permission is requested only when needed, with a visible recording indicator and a complete text alternative.

In the proposed exchange, the partner says the meeting must move from Tuesday to Wednesday. The learner asks, “Do you mean this Wednesday?” The partner answers from the scenario's fixed facts. When the learner proposes a time outside the allowed alternatives, the partner explains the conflict instead of silently accepting it. The practice ends when the learner confirms an available time and the agreed location, or chooses Finish.

Feedback should quote a relevant turn, describe one communication move and offer one next attempt. For example: “You confirmed the day and time. The location was still unclear. Try asking where you will meet.” Label this as practice feedback, not an official proficiency rating.

Speech recognition can mishear an answer. Let the learner review or correct the transcript before the application judges whether an essential detail was confirmed. Keep recognition failures separate from language errors. A retry can change the fictional day or location so that the learner has to transfer the skill rather than repeat a memorized line.

Figure 1. Concept illustration. Proposed learning journey, not a product screenshot or deployed course.

Give the lesson and the avatar different jobs

Kasamila's public integration guide describes browser-side avatar inference and rendering. A protected backend keeps the permanent API key and issues a short-lived token for the browser Runtime. The Runtime accepts documented audio inputs; the selected speech pipeline and device combination still need integration testing. [1][2]

The proposed learning application owns the scenario facts, turn state, task card, transcript correction and feedback rubric. A speech-to-text service transcribes the learner when voice is used. A dialogue component selects the next response, and a text-to-speech service supplies its audio. Kasamila drives the avatar from that reply audio. It does not, by itself, provide a curriculum, reliable pronunciation assessment or a validated language score.

For the first version, use deterministic scenario facts and a limited set of educator-approved response patterns. An LLM can assist with varied wording, but the application should check that the response preserves the current meeting state. If it cannot produce a grounded reply, offer a neutral retry or educator help rather than invent a new agreement.

Use one playback owner so the learner does not hear duplicate speech. Interruption should stop the old reply, discard stale queued audio and return control to the learner. The interface must distinguish “ready to listen,” “processing” and “speaking”; an animated face is not a reliable status indicator on its own.

Kasamila's MCP documentation covers a server-side integration and orchestration surface. Browser rendering remains the Runtime SDK's job. An MCP connection does not make a learning platform plug-and-play. Public examples and mocked tests are development references, not proof of a production speech-provider connection, native mobile SDK, PSTN service or universal hardware compatibility. [3]

Figure 2. Concept illustration. Proposed responsibilities and data flow. All application connections require implementation and testing.

Build a small pilot before a course platform

1. Define the task and rubric. An educator writes the fictional facts, accepted outcomes, clarification opportunities and feedback examples. Name the person who approves revisions. Start with adults and one language pair; additional populations and languages need separate review.

1. Build the text path first. Check that valid alternatives are accepted and contradictory confirmations are caught. Test the transcript-correction and Finish controls. Keep progress local unless the learner explicitly chooses an available saving option.

1. Add voice and the avatar separately. Establish the voice-only exercise before adding rendering. Keep permanent credentials on the backend, issue appropriately scoped short-lived tokens and use documented template-media delivery. Create runtime only when the learner deliberately starts the avatar experience. [1][2]

1. Test the actual setup. Verify the target desktop browser, graphics capability, microphone, headphones, network and media loading. Exercise denied microphone permission, quiet speech, background noise, interruptions, reconnects and tab closure. A functioning demo on one laptop does not establish compatibility across a school's device fleet.

1. Review feedback before exposing it widely. Compare system feedback with educators' judgments on consented examples. Inspect wrong corrections as carefully as missed errors. Provide a route to report an incorrect transcript or explanation without sharing unrelated personal information.

1. Run a supervised feasibility pilot. Agree on participant consent, data retention, spending limits and stopping criteria. Confirm that a failed startup returns to a useful text exercise and that no hidden session continues indefinitely. Do not connect an LMS gradebook, payment system or employee evaluation workflow in this first scope.

For adult practice, collect only what the exercise needs. Use fictional names and schedules. Make recording and retention choices explicit, avoid storing raw audio by default unless it is needed and consented to, and separate deleting the visible transcript from deleting stored records. These are proposed safeguards to implement, not claims about a ready-made Kasamila learning product.

Test the avatar rather than assume its value

The hypothesis is specific: a visible partner might help learners recognize conversational turns or stay engaged with the task. It might also distract them, increase device failures or add pressure. Neither outcome should be assumed.

Compare three versions: A, the text task; B, the same task with voice and text; and C, the same voice-and-text task with the avatar. Keep scenario difficulty, response logic, speech providers, feedback and time allowance comparable. C versus B is the central test of the avatar's incremental contribution. Text versus voice examines a different question and should not be used to credit the avatar.

Assign comparable learners to conditions where feasible, or counterbalance order with equivalent task variants. Repeating the identical task can create practice effects. Record baseline level and relevant access needs, and report the limits of a small feasibility sample instead of presenting it as a proven learning result.

The primary outcome can be independently reviewed task completion: did the learner establish a valid time and location and resolve the intended ambiguity? Use a short rubric defined before the trial. Have a reviewer assess de-identified transcripts without knowing the interface condition when practical. Do not equate an automated “success” flag with validated performance.

Secondary measures include clarification attempts, false feedback, recognition failures, abandonment and time to a correct agreement. Ask about confidence or comfort separately; satisfaction is not proficiency. A later, different task can test transfer, while a repeated task only shows performance on that task. Report sample sizes, failed starts and uncertainty for every comparison.

Figure 3. Concept illustration. Proposed comparison design with no measured uplift or customer results.

Budget for thinking time too

A learner may pause to find a word while the avatar remains visible. Under the documented standard API and SDK lifecycle, billing begins at session creation and follows server elapsed time, including listening, speech, silence and a hidden canvas. Thinking time can therefore consume runtime. LLM, speech recognition and text-to-speech services are separate costs. [1][6]

Keep the task briefing and post-session reflection outside an active avatar session where the design permits. Provide an explicit Finish control. The documented stop() method stops audio; destroy() or the authorized session-end operation ends the session. Explicit ending releases unused reserved lease time under the documented lifecycle; without it, the full lease is consumed at expiry. Test this behavior and reconcile lifecycle records with usage rather than infer termination from a quiet screen. [1]

Set a maximum practice duration, a visible inactivity warning and a recovery path when an end request cannot reach the server. Do not silently cut off a learner mid-sentence. Explain the limit before starting and offer text continuation if appropriate.

Track total cost per independently reviewed successful task, including unsuccessful starts and retries. Include avatar runtime, STT, LLM, TTS, hosting, template preparation, implementation and educator review. Compare the incremental cost of C against B alongside its measured benefits. Use current account rates when approving the pilot; this proposal assumes no price, free allowance or savings.

Decide what deserves another trial

A promising pilot produces an auditable answer to a narrow question: does the avatar improve this practice task enough to justify its additional cost, operational effort and accessibility trade-offs? Agree on acceptable error rates and decision thresholds before collecting results. If the visual layer adds no useful benefit, retain the simpler voice or text path.

Expand only after the task logic, feedback quality, session closure and target-device behavior are understood. The next lesson should be another observable communication task, not a larger collection of untested conversations.

Explore the public Kasamila chat showcase: https://www.kasamila.com/portal/apps/chat?lang=en

Sources

[1] Kasamila, API v1 Runtime integration guide. Browser Runtime, backend authorization and session lifecycle. https://github.com/kasamila/kasamila-dev/blob/main/docs/api_v1_runtime_integration_guide.en.md

[2] Kasamila, public developer repository. Runtime SDK and audio integration references. https://github.com/kasamila/kasamila-dev

[3] Kasamila, Runtime API, Web SDK and MCP integration guide. Server-side orchestration, separate from browser rendering. https://github.com/kasamila/kasamila-dev/blob/main/docs/api_v1_runtime_integration_guide.en.md

[4] Council of Europe, The action-oriented approach. Language use through purposeful tasks. https://www.coe.int/en/web/common-european-framework-reference-languages/the-action-oriented-approach

[5] Council of Europe, Assessment. Descriptor-informed reflection and assessment; not evidence of avatar efficacy. https://www.coe.int/en/web/common-european-framework-reference-languages/assessment

[6] Kasamila, current pricing and scope. External speech and conversational AI services are separate. https://www.kasamila.com/pricing

Sources checked 21 October 2026. Public documentation and proposed design are distinguished throughout; no production learning session or provider integration was tested for this article.