From workout tracker to workout system

Argilzar Workouts started with a simple goal: make workout execution easier.

Not planning. Not coaching. Not analytics. Just the thing that matters in the gym: open the program, see the next movement, record the set, and keep moving.

That first version was intentionally narrow. It solved the immediate problem. It turned repeated workout logs and program structure into a phone-first interface that could be used during training without getting in the way.

But once an app is actually used, the next layer becomes visible.

The problem is no longer only “can I record a workout?” The better question is: what should happen after the workout is recorded?

The first version was about execution

The current app is mostly focused on the active session. That was the right starting point.

A workout app used during training has to be fast, readable, and forgiving. The interface cannot feel like a spreadsheet. It cannot require too much typing. It cannot bury the next action behind navigation.

The first version of Argilzar Workouts focused on that layer:

• start a workout
• follow the planned structure
• record sets
• keep progress visible
• reduce unnecessary interface noise
• work well on a phone

That made the app useful. But useful is not the same as complete.

The next version needs memory

A workout is not an isolated event.

Each session says something about the program: what was completed, what was skipped, where the load moved up, where it stayed stuck, which movements created friction, and which parts of the program should change next.

Right now, much of that context still lives around the app rather than inside a larger system.

The next step is to give the product a durable backend so workouts and plans can become part of a longer-running loop. That means adding login, storing workouts and plans centrally, and making the product usable by more than one person.

The app should still feel simple during training. But behind that simple interface, the data should become more useful over time.

The shape of the system

The UI remains the place where workouts happen. Flowcore becomes the durable layer for sessions, plans, and workflow events. Usable chat becomes the place where the user can reason about training, generate new programs, and ask for adjustments based on actual history.

That split matters.

The app should not try to become a full coaching conversation. The chat should not try to become a workout execution interface. Each layer should do the thing it is best at.

Flowcore as the workout backbone

Flowcore fits this next step because workouts are naturally event-shaped.

A completed set is an event. A skipped movement is an event. A changed plan is an event. A finished session is an event.

Once those events are stored and routed properly, the product can do more than show the current workout. It can support questions like:

• What changed between the plan and the session?
• Which exercises are consistently progressing?
• Which parts of the program are being skipped?
• When should the next program update happen?
• What context should be passed into a program-generation flow?

That is where Flowcore Pathways become useful.

Instead of treating the app as a static frontend with local state, the system can treat training as a stream of meaningful updates.

Usable chat as the planning layer

The original product already came from a chat-based workflow.

Workout sessions were logged. Patterns became visible. A PRD was created from the expert workout context and the logged sessions. Hermes, Codex, GitHub, and AWS turned that into a deployed app.

The next version should bring that loop closer to the product.

A user should eventually be able to ask for things like:

• generate a new four-week program
• adjust this plan based on the last few sessions
• reduce volume on movements that are causing problems
• keep the same structure but change the progression
• explain what changed from the previous program

That kind of interaction belongs in Usable chat. But it becomes much more valuable when the chat has structured workout history behind it instead of relying on manually pasted context.

The product direction

The direction is not “add AI to a workout app.” That framing is too vague.

The direction is more specific: build a workout execution app that records structured training history, stores it in a durable system, and uses that history to support better program decisions over time.

The app should stay practical. The training screen should stay clean. The system behind it can become more capable without making the user interface heavier.

That is the product line I want to keep following:

• simple execution in the app
• durable memory in Flowcore
• workflow routing through Flowcore Pathways
• program generation and reflection through Usable chat
• agentic implementation through Hermes

The first version made workouts easier to run.

The next version should make training easier to evolve.