The easiest way to describe Layers of Us would be to point at one feature — a matching function, a reflection tool, a mediation aid — and call that the product. It would also be misleading.
What a tool is, and what it isn't
A tool does one job. It's judged by how well it does that job, today, for the person using it right now. Most software is built this way, and for most software, that's correct.
Infrastructure is different. It's judged by whether many different things can be built on top of it without each one having to rebuild the same foundation. Roads don't care what kind of vehicle drives on them. Payment rails don't care what's being purchased.
What that means for Layers
Underneath any single Layers-based application sits the same structural core: modeling identity, relationships, health, time and context; interpreting those states rather than reading them literally; routing through multiple intelligence components instead of trusting one model's output; and holding all of it inside governance that doesn't disappear under commercial pressure.
A healthcare application and a team-development application can both be built on this core without duplicating the hard parts. That's the entire point of calling it infrastructure — and the entire reason a single feature description will always undersell it.