The current Swoleby proof point is not another fitness dashboard screen.
It is a skill inside the SMS loop.
That distinction matters. A dashboard can show history, settings, charts, and account state. It is useful, but it is mostly a reporting and control surface. For behavior change, I want to remove as many barriers to action as possible. The moment that matters is smaller: “What should I do today?”, “I only have dumbbells”, “my knee feels weird”, “I did squats and bench”, or “I need a safer substitute.”
Swoleby should be able to handle those moments in the thread where the behavior is already happening: the conversation with the coach.
What I am rebuilding this week turns workout management into an engagement skill for Flex, the SMS accountability coach. The older workout flow grew up around a separate agent path from a time when the model/tooling boundary was rougher. With Flex’s current engagement harness, the cleaner shape is a small skill prompt plus deterministic support code for the parts that should not be improvised, mostly storage, normalization, and state updates.
That is the product architecture I keep wanting as a user too. I do not want to open a full app every time I train. I want to text or share the note I already wrote, have Flex understand it, save the useful parts, and keep the next check-in aware of what actually happened.
This branch adds the SMS skill path for the first practical slice:
- suggest a workout from the user’s time, equipment, pain, soreness, and constraints
- log a completed workout from a normal text reply
- remember durable workout constraints without forcing a full plan
That is the right level of ambition for SMS. The skill does not try to become a full training app inside a text message. It tries to make the next action concrete enough that the user can start.
The itch is personal. I have been tracking workouts in notes because that is the lowest-friction place to capture the truth: what I planned, what I actually did, what hurt, what moved well, whether I need a deload, and what the next mesocycle should probably respect. The product direction is to let me share that note to Flex over SMS and have the system turn it into useful memory instead of another pile of unstructured text.
That simplicity matters. Someone who already struggles with consistency should not need to master a tracking ritual before the product starts helping. Richer UI can come later for review, charts, editing, and planning. It should not be the required path for an app aimed at changing behavior. That is level ten for many people. Flex should offer a no-effort onboarding path where a user can dip a toe in and immediately make progress.
The product surface
The user-facing version is simple:
Text Flex something like “what should I do today, dumbbells only, knee hurts” and get back a short workout that fits the request.
Text “squat 3x5 at 185, bench 3x8, knee felt cranky” and have that become a workout log instead of disappearing into chat history.
Text “avoid overhead pressing this week, shoulder is irritated” and have future workout suggestions see that constraint.
That is the product surface I want Swoleby to keep earning. It is not “AI generates workouts” as a party trick. It is “the coach can turn messy, human workout context into a bounded action, and then remember the parts that should affect the next conversation.”
The skill contract is deliberately structured. Flex can return a workout_sms skill call with one of three actions: suggest_workout, log_workout, or update_constraints. A suggestion can include a title, summary, equipment, injuries, constraints, the original user request, and a list of exercises with prescriptions and notes. A log can include the completed work, injuries, notes, and exercises. A constraint update can persist information without pretending the user completed anything.
That separation is not just engineering neatness. It is product safety.
Schedule changes belong to the workout schedule skill, not the workout SMS skill. A future intention is not a completed workout. A vague pain report should not become a risky plan. If safety depends on missing information, the coach should ask a short question instead of inventing confidence.
Those boundaries are where AI product work becomes real.
The system behind the text
The useful pattern is model judgment plus deterministic handling.
The model gets the conversational task: understand whether the user is asking for a workout, logging one, or sharing a constraint. The executable handler owns the state changes. It normalizes the payload, caps the visible SMS-sized message, saves durable constraints like injuries, equipment access, and workout limits, stores a suggested plan under an SMS-specific name, records activity, and keeps a pending suggested workout pointer available for follow-up.
For workout logs, the handler saves progress as workout progress, records the activity, and can update injury context for future suggestions. For constraint-only messages, it updates the user’s workout limits without creating a fake workout or fake progress record.
That matters because an AI coach can sound helpful while quietly corrupting product state. The implementation pushes the model toward a structured claim, then makes the code decide what that claim is allowed to do.
The engagement loop also passes workout context back into the prompt: injuries or restrictions, equipment, constraints, and any pending suggested workout. That lets a later reply build on what the user already said without asking them to re-enter everything in a settings page.
Safety is part of the feature
Fitness advice is a domain where casual overconfidence is a product bug.
The skill prompt tells Flex to respect injuries and pain, avoid diagnosis, use safer swaps, and tell the user to stop if pain spikes. It also says to ask one short question when missing information makes the plan unsafe. The parser and handler reject malformed or incomplete workout skill calls: a suggestion needs actual workout content, a log needs a summary or exercises, and a constraint update needs a real constraint.
The SMS length limit is also a safety and usability boundary. A workout response that is too long for the channel is not helpful. The implementation caps the workout SMS and formats the plan as a small set of usable lines rather than a wall of generated coaching copy.
There is also an enablement boundary. Engagement skills are registered capabilities that can be enabled by default or blocked for a user. If the workout skill is disabled, dispatch returns a blocked message instead of silently doing work anyway.
That is the kind of boring product machinery AI features need. The model should not be the only thing deciding what happens.
Why SMS is still the better loop
For Swoleby, SMS is not a compromise UI. It is the behavior-change surface.
A dashboard is good when the user is already in planning mode. It can show progress, billing, settings, streaks, achievements, and deeper history. But most missed workouts do not start with a calm dashboard session. They start with friction: low energy, uncertainty, soreness, time pressure, travel, or the feeling that the day is already blown.
SMS is closer to that friction.
The user can reply with the actual constraint instead of translating it into app fields. The coach can turn “hotel gym, 25 minutes, shoulder cranky” into a next action. The same thread can handle “done” or a real log after the workout. If the user already wrote the workout in Notes, the ideal loop is just share, send, and let Flex extract the parts worth remembering. The loop stays small enough to survive normal life.
That is also why the feature is credible as an AI product proof. It forces the system to handle ambiguity, persistence, safety, tone, and state changes in a real workflow. There is no room for a beautiful but disconnected demo. The reply has to be short, specific, safe, and useful enough to act on.
What this proves
This build does not prove user outcomes, retention, production reliability, or the full note-to-mesocycle workflow I want. Those need real deployment evidence and real behavior data.
It does prove a narrower, useful product step: Swoleby’s SMS coach can be shaped as a tool-using agent with explicit workout-management skills, bounded state changes, and tests around the failure modes that matter.
The larger direction is clear. Swoleby should not just ask whether you worked out. It should help you decide what to do, remember what happened, adapt around constraints, and keep the next action close to the moment you need it.
The dashboard supports that loop.
The SMS thread is where the loop lives.
Related build notes: Swoleby project, why SMS beats another app, behavior-based agent evals, and agentic SDLC.