Founder letter

Capability as the shared thesis

Capability as the common thread

One question underneath everything

At some point in building several things at once, you are forced to answer a question you would rather defer: what connects all of this? Not for a pitch deck. Not for a headline. For yourself. Because without a real answer, you are not building a portfolio: you are accumulating projects. And accumulated projects are not an institution. They are a distraction with a coherent calendar.

The answer we kept arriving at, across product work and research and services, was not a market category. It was not a technology stack. It was not even a philosophy in the abstract. It was something more functional, and in a way more demanding: capability.

Not capability as an aspiration. Capability as a constraint. Every product, every engagement, every research direction had to pass through one honest question: does this make the person on the other end more capable than they were before? If yes, proceed. If not, if the thing being built merely created the feeling of capability, or substituted for it, or obscured the gap between knowing and doing, that was grounds to stop and ask harder questions.

That is the thesis Mustard Seed Group was built around. It is not sophisticated. It is almost uncomfortably plain. But plain theses are the ones that hold across time.

Why capability, not intelligence

The word that tends to get used in environments adjacent to where we operate is intelligence. Smart systems. Intelligent tools. AI as a shorthand for something smarter than the person using it.

The problem with intelligence as a thesis is that it positions the system as the protagonist. The user becomes, at best, a beneficiary of the system's cleverness and, at worst, a bystander. There is a meaningful difference between a tool that makes a person more capable and a tool that performs on behalf of a person. One builds something durable in the human. The other creates a dependency.

The distinction matters practically. A research assistant that summarises everything a person reads might save them time in the short term. But if they stop reading carefully because the summary is always there, the tool has not increased their capability: it has substituted for it. The person is not better. The system is busier.

Capability as a thesis keeps the person at the centre. The product is not the point. The product is a lever. What matters is what the person can do, think, decide or build after having used it, not during, not in aggregate, but after. Did the engagement leave them with more than they arrived with?

The problem with domain-specific theses

The alternative to a thesis like capability is to organise around a domain. Build tools for marketing teams, or for athletes, or for software engineers. Serve one audience with increasing depth.

There is nothing wrong with that model. But it was not the right model for what we were building, because the things we were learning did not stay within domains. Patterns from building commercial software turned up inside research. Research questions that started in the context of agents had direct implications for how coaching software ought to be designed. The shape of a great performance feedback loop is not fundamentally different whether the person receiving it is training physically or closing deals or making creative decisions.

A domain-specific thesis would have required us to ignore those crossings. We would have had to discard lessons that were genuinely relevant, or force them into a narrower frame than they deserved.

Capability, by contrast, is domain-agnostic. It applies equally to a founder trying to think through a strategy, an athlete trying to hold a standard, a researcher trying to build a reasoning system, or a services team trying to pattern-match across client engagements. The thesis travels. It does not need translation at each new context: it is already native to all of them.

What it looks like in the portfolio

The clearest illustration of this is how the different parts of the work relate to each other.

Benediction Lab is the research end. The work there is concerned with agents, memory, reasoning, and the fundamental architecture of systems that can operate with sustained coherence. That sounds abstract, but the underlying question is still capability: how do systems remain capable across time, across context changes, across complex sequences of action? The research is not adjacent to the thesis: it is an attempt to understand it at a level of depth that products cannot reach on their own.

Orbit sits on the commercial side. It is a B2B operating system for the full workflow from lead to launched product. The capability question it answers is about execution: can a team move from knowing what to do to actually doing it, without losing context, without fragmenting across tools, without the overhead of coordination eating the work itself? The value it delivers is not data or dashboards: it is the ability to act with clarity on what actually matters.

TUXX operates as a services and commercial software division. The particular value of that division is that it lives close to real environments: real clients, real constraints, real feedback loops. Research can be proven in theory; services prove things in practice. The patterns that survive contact with a live engagement are worth more than the patterns that survive only in controlled conditions. TUXX is where we test whether the ideas hold.

All Purpose and CheekyGains represent the consumer expression of the same thesis. CheekyGains is explicitly built around the question of what it takes to hold a standard, physically, habitually, over time. The capability at stake is not just performance in the athletic sense. It is the capacity to commit, to track honestly, to use feedback without being defeated by it. Naira, as the coaching intelligence inside that product, is the most direct embodiment of what it means for an AI system to serve capability rather than replace it. A coach does not run for you. A coach helps you become the kind of person who runs.

Why 'increase capability' is more durable than any feature

Product features have a shelf life. The interface pattern that is novel in 2015 is assumed by 2018 and invisible by 2021. The integration that felt premium becomes table stakes. The AI feature that differentiates a product today becomes part of the baseline operating assumption in a few years. Features are perishable.

Thesis is not perishable. The question of whether the people using what you build are more capable afterwards is the same question whether the year is 2016 or 2026. The tools that answer it change. The answer itself, the product of whatever work you are doing, can be measured against the same standard indefinitely.

This has practical implications for how we make decisions. When a new technology emerges, and in this period new tools are emerging constantly, the question is not whether we should use it. The question is whether using it serves the capability thesis or undermines it. That framing immediately eliminates a large class of things that would otherwise consume energy: the impressive things that do not actually increase what a person can do. Impressiveness and capability are not the same thing. The portfolio needs to be built on the second.

The hard version of the thesis

It would be easier to say: increase capability, except in cases where the thing is clever enough that users might not notice the gap. Or: increase capability, but revenue comes first, and sometimes revenue requires building in dependency. Or: increase capability as a general philosophy, applied loosely.

None of those are the thesis. The thesis is not a principle for press materials. It is a filter for decisions. Which means it cuts. There are products that could be built, services that could be offered, research directions that could be pursued, that would not survive the filter. The thesis is only useful insofar as it is genuinely restrictive: insofar as saying yes to it means saying no to some things.

What this group is trying to do is build systems that leave people more capable than they were before they encountered them. Not more entertained. Not more reliant. Not better marketed to. More capable. That is the thread that runs underneath everything, from the research to the commercial software to the consumer products to the services work. It is not a product category. It is a standard.

The portfolio will keep growing. The tools available will keep changing. The thesis will not.