Skip to content

AI Systems Architecture • Product Engineering • UX

Clayton Baggett

I build products end to end — from the problem, through the system, to the interface people actually touch.

I own product development end to end: framing the problem, designing the system, and writing the software that ships. My current focus is adaptive AI systems — products that decide what to do from live signals rather than handing everyone the same fixed answer.

Selected work

Evidence, not a highlight reel

One deep case study, in the order the work actually happened: the constraint, the decision, the system, and the evidence that it behaves as designed.
In active developmentOngoing

SculptAI

An adaptive AI training system

A training system that keeps the plan aligned with what is actually happening — goals, training activity, recovery, measurements, consistency and progress evidence — so adaptation is the product's job rather than the user's.

Role
Product strategy, architecture, implementation, validation, and operations
  • Adaptive systems
  • Product architecture
  • Mobile-first UX
  • Internal observability
  • AI systems design

Read the case study

SculptAI Gym Mode on a phone, showing the session 'Back + Triceps (Weak Point) · 15min Cardio', 0 of 22 sets done, a seven-exercise pager, start and end movement blueprints for an assisted pull-up, and an 'Equipment busy? Swap exercise' action.
Gym Mode: the session the planner produced, running set by set.

How I work

A single thread from problem to interface

I don't hand the problem off between disciplines. The same person framing the problem is designing the system, writing the software, testing it, and answering for how it feels to use.
  • Frame the problem before the feature

    I get specific about who is struggling, with what, and what would count as evidence that the product helped. Scope follows from that answer instead of arriving before it.

  • Design the system, not just the screen

    I work through how the pieces relate: what owns which decision, what moves between them, and where the seams need to be visible when something behaves unexpectedly.

  • Build and ship the system

    I write the product, not only the plan — interfaces, application logic, data model, and the connective work between them. Building it myself keeps the architecture honest about what is achievable on a real schedule.

  • Design AI systems that can be trusted

    Adaptive behavior is only valuable if it is inspectable. I define the boundaries an AI-driven system runs inside — what it owns, what it may decide, what it must declare when it changes course — and build the validation that proves the behavior is the one I specified.

  • Treat quality as design work

    Edge cases, empty states, and failure modes are part of the product. I ask what happens when data is missing, the network is slow, or someone does something reasonable that I did not plan for — and I build the checks that catch it.

  • Connect the system back to the experience

    Architecture matters because of what the user feels: fewer surprises, clearer feedback, and interfaces that stay legible under real conditions rather than only in the happy path.

Contact

Let's talk about the parts that aren't written down

The architecture decisions, the trade-offs, the code, or where I'd take it next — whichever is most useful to you.