Inspiration

Most AI tutors can correct an answer, but they forget the learner when the conversation ends. The next session starts from zero, even when the learner keeps making the same mistakes or has already discovered a practice method that works.

We built WeakSpot because language improvement should compound over time. A useful coach should remember recurring weaknesses, understand which exercises have actually helped, and create opportunities to apply a skill independently in a new situation—not simply show the same correction again.

What it does

WeakSpot is an AI English coach with learner-controlled, cross-session memory. It remembers goals, preferences, recurring language weaknesses, effective strategies, and practice outcomes.

A deterministic scheduler evaluates what is weak, due for review, uncertain, relevant, and not recently over-practiced. GPT-5.6 then transforms that bounded evidence into a realistic speaking or writing mission.

Learners can practice through five formats:

  1. live situational roleplay;
  2. picture-based description and storytelling;
  3. listening and retelling;
  4. open-ended situational decisions;
  5. vocabulary used in a realistic message.

WeakSpot can also introduce practice naturally during an ordinary conversation. It responds to what the learner wants to say first, then creates an appropriate opportunity to reuse a previous weak point without interrupting the conversation with an obvious test.

For every generated mission, the product shows why the task was selected, which learning evidence was used, how the learner's available time, energy, and response mode affected the task, and what successful language transfer will look like.

Learners remain in control: they can inspect, edit, pin, or forget any stored memory.

How we built it

WeakSpot uses a Next.js frontend and a FastAPI backend. Cross-session learner memories and practice outcomes are stored in DynamoDB.

The adaptive mission-planning flow is:

learner-controlled memory and outcome evidence
    → deterministic practice scheduler
    → bounded mission context
    → GPT-5.6 Sol through the OpenAI Responses API
    → structured mission and evidence explanation
    → learner response and feedback
    → new evidence for future practice

We use gpt-5.6-sol with medium reasoning and Pydantic Structured Outputs. The model returns both the practice mission and a typed plannerInsight object containing whyNow, evidenceUsed, adaptation, and evaluationFocus.

The deterministic scheduler decides what should be practiced, while GPT-5.6 decides how to turn that decision into natural communication. This separation keeps the learning strategy consistent while allowing the exercises to remain varied and realistic.

For privacy and reliability, the OpenAI key remains on the backend, requests use store=false, and the planner receives a bounded evidence summary instead of the learner's complete history. The integration also uses a hashed safety identifier and fails closed if the configured model is not part of the GPT-5.6 family.

Codex was our engineering collaborator throughout the Build Week extension. It helped audit the existing architecture, design the isolated OpenAI runtime path, implement the backend and frontend changes, add tests, verify the production deployment, create and merge pull requests, and produce the final demo video. Codex is not embedded as the product's runtime backend; the deployed application calls GPT-5.6 directly through the Responses API.

Challenges we ran into

One major challenge was adding a meaningful GPT-5.6 feature to an existing multi-provider product without presenting pre-existing functionality as new Build Week work. We solved this by creating a dedicated, opt-in OpenAI mission-planning path with visible runtime metadata and a clearly documented implementation boundary.

Another challenge was balancing deterministic learning decisions with generative flexibility. Letting the model choose everything could make recommendations difficult to reproduce, while relying only on fixed templates would make practice repetitive. We addressed this by keeping prioritization deterministic and using GPT-5.6 to generate the natural scenario and explain the adaptation.

We also needed to prevent the explanation from inventing learner history. The planner is allowed to reference only the supplied evidence and must explicitly acknowledge when evidence is limited.

Finally, producing a clear demo in under three minutes required careful coordination between real production interactions, narration, subtitles, and evidence screens. We generated sentence-aligned audio and captions, recorded the running product, and added automated checks for duration, dynamic frames, silence, and audiovisual timing.

Accomplishments that we're proud of

We are proud that WeakSpot is not just an “AI tutor with memory.” Memory directly changes which task is selected, how that task is presented, and what the coach observes afterward.

The production application successfully generates missions through gpt-5.6-sol and the Responses API, displays the model returned at runtime, and gives learners a transparent evidence trail for every recommendation.

We are also proud of the learner-control and privacy boundaries: compact context instead of full-history forwarding, server-only credentials, no-store requests, editable memories, and a fail-closed model guard.

The final implementation includes backend contract tests, frontend type validation, public capability health information, real production validation, and a 174-second demo featuring actual product interactions.

What we learned

We learned that memory becomes valuable only when it changes a future decision. Storing more conversation history is not the same as building a better learning strategy.

We also learned that personalization becomes more trustworthy when it is visible. Showing the evidence and adaptation behind a recommendation helps learners understand why a task matters and makes incorrect assumptions easier to identify.

Structured Outputs were especially useful because the mission, rationale, evidence, adaptation, and evaluation criteria needed to remain consistent across the API, backend validation, and frontend interface.

Finally, we learned that Codex is most valuable as an engineering collaborator across the entire workflow—not only for generating code, but also for architecture decisions, testing, deployment verification, browser-based QA, documentation, and demo production.

What's next for WeakSpot English Coach

Next, we want to strengthen the outcome-evidence loop so the coach can measure whether a weakness transfers across different situations, response modes, and levels of prompting.

We also plan to add consent-based pronunciation and spoken-fluency evaluation, richer progress explanations, and longitudinal evaluations that compare adaptive missions with fixed practice sequences.

Longer term, WeakSpot could become a general adaptive communication coach for workplace English, interviews, presentations, travel, academic communication, and other learner-defined goals—while keeping memory transparent and under the learner's control.

Built With

  • agents
  • ai
  • alibaba
  • api
  • audio
  • cloud
  • codex
  • docker
  • dynamodb
  • fastapi
  • generative
  • gpt-5.6
  • next.js
  • openai
  • pydantic
  • python
  • qwen
  • react
  • realtime
  • responses
  • rest
  • typescript
  • vercel
Share this project:

Updates