Russ Foltz-Smith posted something last week that I've been sitting with.
Russ and I have worked together. He's not a hype person. When he says something plainly, it's worth reading carefully.
His argument, condensed: coding agents now write software reasonably well. So the amount of software goes way up. But the amount of software where humans are the users goes down — collapses into a handful of foundational AI interfaces. The market that explodes is software for AI agents and systems. And what does that software consist of? Fact data. Knowledge sets. Real-time signal streams.
Data is the only marketplace.
A reply from Kristofer Stover added a layer Russ left implicit: skill files and workflow definitions. The instructions that teach AI how to perform domain-specific work. He pointed at Skills files and markdown propagation as early evidence. His bet: whoever defines the canonical skills for a domain, and whoever controls how those skills get discovered and ranked, is sitting on something structural.
I want to say something honest about where we sit relative to this.
We didn't start building KNWN.TO because we predicted this.
We started because youth athletes don't have a systematic way to build self-knowledge over time. Because most AI tools that touch sport are generic — they know the prompt, not the athlete. Because the practitioners who would actually help — CMPCs, sport psychologists — aren't accessible at scale.
The infrastructure thesis came from working the problem, not from the thesis itself.
But when I map what we've built to what Russ is describing, the fit is uncomfortable in a good way. The deeper value proposition is that we're building a fact/knowledge/signal layer for athletic mental state that agents will consume.
He says the durable market is three things: structured knowledge, real-time signals, and domain-specific workflows.
Here's what we've built, named honestly against each one.
Structured knowledge. The ACSI-28 is a validated instrument — a published baseline for athletic mental performance that we use as foundation. What's proprietary is how we interpret and map those results: a taxonomy that translates ACSI outputs into a state-space architecture. The athlete.md is the portable expression of that — a structured psychological profile, in the athlete's own language, owned by the athlete, loadable by any AI system. That's not content. That's machine-readable knowledge.
Real-time signals. Athletes are already on SMS, chat, Discord. They check-in. The system receives. Those inbound check-ins produce activation × regulation coordinates — a real-time position in a two-dimensional state space. LaRue reads that before every interaction. The goal is for that signal to be queryable beyond our own platform, by any agent that needs to know where an athlete is right now.
Domain-specific workflows. We building real-time intervention protocols — routing logic that maps state coordinates to the right response at the right moment. The FSM underneath it is what makes that routing consistent and machine-predictable across interactions. And yes — the skill files in our project are early instances of exactly what Kristofer is pointing at. If those protocol definitions become the canonical workflows for athletic mental performance, that's a structural position.
Most platforms in our space are building the human-facing app layer.
That's the layer Russ says collapses.
We're building below it — not because we predicted this, but because the infrastructure bet made sense on its own terms.
Coaches don't need another interface. They need systematic signal. Athletes don't need another chatbot. They need a structured record of themselves that travels across tools, seasons, and systems.
That happens to be exactly what an AI agent needs too.
The direction has a name: Readiness-as-a-Service. An API layer that makes athlete mental state queryable — norm-referenced, state-positioned, and accessible to any agent or platform that needs it.
Per-request pricing. Machine-readable responses. The readiness signal as infrastructure, not just as a feature inside one product.
We're not there yet. The numbers are still small. We're proving the product with coaches one at a time.
But it's useful to name where this is going while we're still early enough that the naming matters.
Russ's post is worth reading in full.
Our build continues at knwn.to.
— Robert | Founder, KNWN.TO / Mettle