Soma creates a personalized plan based on your profile and an onboarding conversation. That plan contains the basic structure and intent of the plan, the sessions, exercises, the intensity and rep range of each set, etc. It also generates personalized copy: a name for the plan, highlights, forecasts, and more in-depth explanations of why this plan is right for you.

After that’s done, a smaller model classifies each exercise that was generated to answer questions like what muscles it targets, if the weight is total or per limb, whether we should count bodyweight in the load, and more.

When you open the app, your next session is ready for you, with context for why you’re doing what you’re doing, and you can chat with Soma if you want any changes or have questions.

How Soma sets targets is a real shift from the average fitness app. There’s a deterministic core which updates an estimate of your one-rep max for each exercise after every set. It uses a Kalman filter, and with more observations the noise and variance decrease, and the confidence increases. It even learns your endurance per muscle group so that it can model your reps to failure for multiple sets.

These generated targets are used as input for Soma, but it’s Soma that ultimately decides the targets. This way we get the best of both worlds. Math and code for building an estimate of the user’s strength, and Soma can consider the qualitative data, trends, and read between the lines. For instance, Soma will know you’re recovering from a shoulder injury, or may decide to not progress the load on both squats and leg extensions, or it can see the signs in your data that you may need a deload.

Soma has a cold-start problem: How can you set good targets before you know how strong the user is?

Soma uses a process called calibration. If the confidence level in a user’s strength for an exercise is low, it gets flagged. When Soma sets targets, it decides whether that exercise should be calibrated. It may decide against it if it’s easy and low risk to set targets based on data for other exercises.

If Soma decides the exercise should be calibrated, the exercise’s schema is overwritten, and Soma sets conservative targets for one feeler set. The user does the set, reports how many reps in reserve they had, and another set is generated. This repeats until their strength can be calculated with high enough confidence.

Under the hood, Soma is similar to coding agents like Claude Code or Codex. There are multiple agents that are bound to a particular phase of the flow, each with their own context, tools, and skills. There are also sub-agents, which are agents scoped to and optimized for a single task, like setting targets, classifying exercises, and more.

Agents manipulate state like your workout plan, a workout session, an exercise, your injuries, your profile and memories about you, and more using tools. Some tools like editing the workout or changing targets require the agent to learn a skill first. I chose this approach because these tasks require a lot of context to do well, and these tasks are done infrequently. The agent calls the tool to learn the relevant skill, receives relevant instructions and data, and then it can use the now unlocked tools.

The team at Alta had built a strong foundation but the information architecture and mental model of the app was confusing. They also lacked a coherent visual language for both the product and the brand.

Over the course of 4 months, I redesigned Alta from the ground up, creating an intuitive experience, and a clean design system for the product and brand. AI models were just starting to get good enough to reliably reproduce an avatar and clothing, so the user's avatar became a cornerstone of the new experience.

The only way to offer instant, private, global transfers and user-owned assets while keeping the experience as simple as Cash App, Opus had to be non-custodial. In crypto, this typically means that the user is responsible for a "secret key" that unlocks their account, but that there's no recourse if they lose that key or if someone gets access to it.

To make Opus easy to use yet secure, we had to a multi-factor authentication system with redundancy. We solved this by creating three layers of keys, where two out of three where needed to access your account. The first was a key saved in the user's iCloud Keychain. This key could be decrypted by a key that Opus controlled, it was on our HSM and it unlocked when you confirmed your phone number and email. As a backup, we designed a system we called Backup Buddies: friends and family who can save a backup decryption key in their iCloud Keychain for you.

The experience was simple. To sign in, you'd just confirm your phone number and email, just like in any regular app.