-
-
GUI of Adaptr
-
personalized workout
-
CockroachDB storing my agent’s memory as embeddings, with a vector index for fast context retrieval.
-
Using ccloud CLI to connect directly to the live cluster and verify the agent’s stored memory data.
-
User training goals are saved in CockroachDB so Adaptr can keep adapting the plan across check-ins.
-
CockroachDB stores Adaptr long-term memory as searchable embeddings.
-
Workout Plans Stored in Amazon S3
Inspiration
Fitness advice on social media is easy to find, but turning scattered workouts into a safe, realistic routine is difficult. We built "Adaptr" to turn a user's goals, available equipment, recovery, and schedule into a plan that can adapt day by day instead of becoming another one-shot suggestion.
What it does
Adaptr is a conversational fitness planner. It collects a persistent profile and training goal, creates a validated date-based weekly plan, and supports daily check-ins for sleep, energy, soreness, pain, workout completion, and nutrition. It then calculates readiness, gives nutrition targets, and repairs only the current week's plan when recovery or availability changes. Users can also ask for a specific day, the whole week, or an Excel export without accidentally creating a check-in.
How we built it
Adaptr is built with Python, NiceGUI, Ollama, CockroachDB, and Amazon S3. CockroachDB stores profiles, goals, check-ins, dated workout sessions, nutrition targets, plans, and an audit trail of agent decisions. Its VECTOR support stores embeddings for fitness knowledge and relevant past context, which are retrieved before plan generation or repair.
Ollama interprets flexible user language and generates structured plan drafts. Deterministic Python code calculates readiness scoring, nutrition formulas, plan validation, scheduling, safety rules, and database updates. Every plan follows a retrieve → generate → validate → retry → store loop, so we will filter the unvalidated output.
Challenges we ran into
- Separating useful LLM flexibility from decisions that must stay reliable, explainable, and safe.
- Avoiding false precision in readiness scoring. Early hard deductions created abrupt threshold effects. By switching to personalized z-score and sigmoid-based penalties for smoother readiness adjustments.
- Ensuring plans use the user's sport, equipment, injuries, dates, and actual sets/reps rather than generic exercises.
- Handling safety-sensitive messages such as chest pain or sharp/worsening pain before any workout advice is generated.
- Balancing local and cloud Ollama usage in a hybrid setup, since fully local inference was too slow for responsive chat, while cloud inference improved response speed but required careful routing between generation and embedding workloads.
Accomplishments that we're proud of
- Persistent, date-based weekly sessions with visible dates, sets/reps, workout status, and current-week-only repairs.
- Context-aware chat routing: Ollama understands natural requests, while deterministic checks prevent unsafe or unintended state changes.
- CockroachDB-backed vector memory and decision logs that make each generated or repaired plan traceable.
- A strict safety gate that blocks unsafe workout advice and explains why users should seek appropriate help.
What we learned
An effective fitness agent is not just an LLM prompt. Retrieval only matters when it directly influences generation, and safety cannot depend on retrieval or model judgment alone. We learned to use LLMs for language understanding and constrained creation, while letting code handle formulas, validation, scheduling, and safety-critical decisions. This makes the experience more flexible without making it a black box.
What's next for Adaptr
We hope to have richer exercise variation, clearer progress summaries, deeper evaluation using real check-in and plan-repair scenarios, and wearable API integration for automatic activity check-ins, while keeping safety and auditability as core requirements.
Log in or sign up for Devpost to join the conversation.