Knowledge work is the last large category that has not yet been automated, and the returns to automating it well compound for decades. That is the bet.
It is not a bet that an AI will replace a CEO this quarter, or a partner this year, or a senior analyst by 2030. Those framings make for good headlines and bad strategy. The bet is narrower and more durable: that judgment, the part of expert work that survives translation into a sentence, is portable into a system that can hold it, refine it, and put it to work without exhausting the original mind.
The reader who came here from a different decade would call this a digital twin. We use the word, but we do not love it. A twin connotes copying. What we are building is closer to an apprentice that survives its master and continues to improve.
The unit of return is decades, not quarters
Most software companies are built on quarter-to-quarter math. Acquisition cost, retention curve, payback period — all measured in months, sometimes weeks. Product decisions follow the math.
A digital twin is a different instrument. The version a customer hires this year is not the version that will compound the most value for them. It is the version five years from now, after thousands of conversations have refined its memory, the customer has corrected its mistakes, and the system has learned which decisions to defer and which to handle. The economic argument for owning a twin only really works if the customer expects to be running it in 2036, not 2027.
This forces a different kind of engineering. A two-year retention horizon lets you cut corners on data architecture; a twenty-year horizon does not. The choices we made early — versioned memory snapshots, on-chain identity primitives, a four-field namespace contract that tolerates organizational change — only make sense if we believe customers will hold their twin long enough for those choices to pay back. We believe it.
The family office is our design customer for that reason. Family offices already think in 50-year cycles. Their question is not "will this AI work next quarter" but "will my great-granddaughter still be able to consult the version of me my grandchildren raised." If we cannot answer that question with a straight face, we are not building the right thing. The discipline of writing for that customer informs every product decision, including the ones that look like they should be easier.
What we are willing to be wrong about
Strategy that does not name what it is willing to be wrong about is decoration. A few of the things we might be wrong about, in rough order of consequence:
We might be wrong that judgment is portable. It is the central premise of the company. If, after enough careful work, we find that what makes a great advisor great is irreducibly embodied in their unrepeatable presence, we will have built an interesting set of tools and not the product we intended. We do not think that will happen. Twenty thousand conversations into the project, the evidence is going the other way.
We might be wrong about the time horizon. Customers may not, in fact, want a 50-year tool. They may want a sharper version of last year's productivity software and find the long view alienating. If that turns out to be true, the family office anchor stops being a forcing function and becomes a niche.
We might be wrong about the moat. The moat we are building is not the model — models are commodities and getting more so — but the corpus of judgment captured per customer over years of use. If a future model architecture can absorb that corpus in a single afternoon, the switching cost we are designing for collapses. We are watching this carefully. The current evidence is that good judgment in any specific domain is much harder to ingest than to demonstrate, and that gap is widening, not closing.
What we are not willing to be wrong about is the duty of care. The cost of a system like this giving bad advice to a person making a real decision is not zero. We have built privilege bits, audit trails, and explicit "this twin will not answer that" failure modes for a reason. If we ever find ourselves arguing for a feature that erodes that, we have stopped being the company we want to be.
The three forces that make this possible now
A version of this product was not buildable in 2018, was barely buildable in 2022, and is plausibly shippable in 2026. Three forces converged.
The first is technical. Long-context models, durable agent memory, and inference latency low enough to feel like presence rather than waiting. Each of these was a research curve we watched cross a usable threshold within the last 24 months. None of them, individually, would be enough.
The second is structural. The legal and regulatory infrastructure for treating an AI agent as something other than a search engine — a fiduciary, a record-keeper, a carrier of attorney-client privilege — is being written in real time, in court rulings and EU regulation and state-level professional ethics opinions. We are not waiting for that infrastructure to settle. We are building product that will fit into the version of it we expect, and engaging with the bodies writing it where we can.
The third is human. There is a generation of senior advisors, academics, executives, and operators who, looking at the curve of demand for their judgment versus the curve of their own remaining decades, are willing to encode what they know into something that will outlast them. That willingness is new. It did not exist in this form ten years ago, and the historical examples we can point to — Drucker's late writings, Buffett's annual letters, the master classes that show up in academic libraries — are evidence the demand has been latent for a long time.
What the moat actually looks like
The moat is not a model, and it is not a clever prompt. It is the per-customer corpus of judgment, captured under a privilege regime the customer trusts, indexed against a knowledge graph the customer can audit, and refreshed by a memory architecture designed to survive the kind of organizational disruption that destroys most software stores of value.
That corpus is hard to build for two reasons. The first is that it requires the customer to hand over the kind of context they have spent careers being careful with. They will only do that for a system whose privilege guarantees are credible — which means the privilege architecture has to be in place before the corpus exists. Build order matters. The second is that a corpus is built one conversation at a time, over years, and there is no shortcut.
We have ninety patents filed against the mechanisms that protect, structure, and refresh that corpus. The patents are not the moat. They are the written documentation of the engineering discipline required to build the moat — a side effect that happens to be enforceable.
One thing the reader can do this week
If you are evaluating a digital-twin product — ours or anyone else's — ask the team this question: what does this system look like in 2046, and what specific decisions you have already made are designed for that version of it.
The answer will tell you whether you are buying a tool or an instrument. It will also, more usefully, tell you whether the team building it has thought about it for more than the next quarter. Most have not. The ones that have are the ones to bet on, regardless of which logo is on the page.
The 50-year question is not a marketing question. It is a build-order question, and the answer is in the architecture, not the pitch deck.
