Zota: From YouChannel to Memory-Led Practice Surfaces

Zota is the project I built after YouChannel.

YouChannel treated an authentic YouTube video as the object of learning. The product had a concrete source, a transcript, derived study material, and a loop that turned media into practice. That was useful, but the media object also became the ceiling. The learner still had to translate a video lesson into the room they actually cared about.

Zota keeps the useful part of that architecture and changes the object. Instead of a YouTube video, the product starts from a real upcoming scene: an interview, client meeting, presentation, thesis defense, sales pitch, panel, or difficult conversation. The job is not to summarize content. The job is to remember the learner’s situation and keep generating practice surfaces around it.

From YouChannel to Zota

The product change is small in wording and large in architecture.

This is why Zota is not mainly a “language tutor chat.” The chat is only one surface. The durable product is the combination of scenario state, session memory, tool outputs, feedback rows, artifacts, and Live summaries.

Memory Is the Product Boundary

The biggest Zota design choice is that the model is not treated as the database.

There are two different memory surfaces:

That split matters because a long UI thread is not the same thing as useful context. A training product needs to preserve facts like “the interview is next Thursday,” “the learner softens ownership language under follow-up pressure,” and “the Live drill exposed weak metric answers.” It does not need to resend every old sentence forever.

Context Compaction

Zota uses a bounded model window and a durable memory document at the same time.

The current policy:

• keep the last 32 UI messages for normal advisor input,
• after a compact run, keep a smaller 16-message tail,
• trigger compact when estimated full UI message JSON reaches 100,000 input tokens,
• write older findings into session memory instead of replaying the whole thread.

agent_threads.messages can still keep compact cards and folded rows for the UI. The advisor model does not need to see all of them. It should see the recent tail plus the session memory that was intentionally extracted.

This is the YouChannel lesson in a different body. The model should read selected state, change selected state, and write back the parts that matter. It should not be asked to remember the whole product by having every old token pasted into every future request.

Model-Generated Frontend Surfaces

The second important design is how Zota lets the model create product UI without letting the model own the UI.

The model does not generate arbitrary React components. Instead, it generates structured objects with known schemas. The frontend owns rendering, spacing, permissions, empty states, and navigation. This keeps the product inspectable and avoids turning every model response into an unsafe mini application.

The pattern appears in several places:

This is the core frontend idea: the model generates page material, not page code. The component boundary stays deterministic. The generated material can be cached, persisted, searched, audited, and rendered in multiple places.

Orchestrator, Tools, and Pages

Zota still needs an agent loop, but the loop exists to protect product state.

An advisor turn is split into:

1. A shared context build: session, scenario, recent messages, memory, simulation state, timezone.
2. An orchestrator plan: the model returns an ExecutionPlan that chooses capabilities and tone.
3. An executor prompt: selected capability files and context become the main advisor instructions.
4. A tool loop: tool calls write scenarios, memory, feedback, artifacts, or drill briefs.
5. A frontend render: stable React components turn those writes into cards, panels, and pages.

Live Voice as Memory Input

Live voice is where the memory design gets tested. A spoken drill is useful only if the next advisor turn knows what happened.

The handoff is intentionally narrow:

1. The advisor creates a drill brief, or the server generates a thread brief from recent context.
2. The server mints a short-lived Gemini Live token with constrained instructions.
3. The browser runs the voice session.
4. On end, transcript segments are summarized into a Live Session markdown block.
5. That block is appended to session_memories.raw_markdown and shown as a card in the advisor thread.

The voice call is transient. The memory result is durable. That is the product boundary.

Deployment and Documentation

I also organized the Zota repo so the implementation can be handed off without relying on old notes.

The app runtime is a normal Next.js deployment with Supabase and model provider secrets. The static explanation page is separate, so the project can have a public readable page even when the real product is authenticated.

What Is Still Fragile

These are product risks worth naming because they point to the next work: stricter schemas, better plan validation, memory review UI, trace inspection, and cost controls.

The Useful Lesson

Zota is not interesting because it is another AI language-learning chat.

It is interesting because it treats memory and frontend generation as product primitives. The model remembers by writing selected state, not by owning every old turn. The model generates surfaces by emitting structured data, not by owning the React tree.

That is the line I wanted to draw after YouChannel: keep the real object, keep the practice loop, but make the learner’s upcoming room the center of the product.

The code is public at github.com/larry-xue/zota. The static explanation page is packaged in static-site/, and the canonical project reference on this site is Zota AI Communication Practice Console. The earlier YouChannel static archive is at youchannel-product.pages.dev.