How I designed a Gemini-powered English tutor for airline-wide adoption

A Latin American airline had purchased 50K Gemini licenses and wanted to turn that investment into practical usage. The entry point was an English tutor for employees, but the real question was broader: how to activate the licenses through a useful employee experience.

The client already had an assistant developed with OpenAI technology. My first contribution was to frame the migration as a product and platform decision, not as a simple provider swap. The tutor had to create repeated usage, generate learning evidence and justify the new Gemini ecosystem through measurable adoption.

The challenge was not only to make the assistant work on Google technology. The client needed a system that employees would actually use, and a cost architecture that could survive tens of thousands of potential users.

I set a clear architectural objective: make the English tutor a compelling reason to use Gemini while reducing the cost of consumption. That meant designing for efficiency from day one: cache, routing, context discipline, RAG and an open-source path that could scale more cheaply when appropriate.

The target system separates the assistant platform from the voice engine. Channel, identity, orchestration, RAG, cache, evaluation, observability, security and deployment remain shared, while the voice route can change depending on cost, quality and delivery needs.

Via A uses Gemini Live as the primary route to activate the licenses with a strong real-time experience. Via B uses LiveKit with a cascading pipeline of VAD, STT, LLM and TTS to introduce an open-source scaling option. This gave the client a practical baseline and a strategic escape valve for cost optimization.

One of the main axes of the proposal was cost efficiency. A system with tens of thousands of potential users can generate a relevant economic impact if repeated prompts, long contexts and expensive model choices are not controlled from the beginning.

The solution combines multilevel cache, model routing by task, context control, a governed knowledge brain plus RAG, and the open-source Via B. These mechanisms work together: cache avoids repeated calls, routing avoids overusing premium models, context control reduces token load, RAG grounds answers, and LiveKit gives the client another scaling route.

The proposal also needed to be executable. I mapped the target architecture into a four-month delivery plan with a lean team, a fixed investment frame and clear phases for architecture, migration, cache, integration, security, evaluation, pilot and go-live.

This is where the work moved from solution design to delivery planning. I broke the investment into phases, clarified what was included, separated cloud consumption assumptions from project cost, and showed how pilot validation and adoption management would take the assistant from design to rollout.