Retrieval is solved. Capture is the product nobody built

Retrieval over private documents is essentially solved and commoditized. Capture is not, and that is where this category is losing. Jennifer Kerum, co-founder of Anchor Croatia, a luxury yacht charter brokerage, spent an hour and a half searching boats by hand for a client who wanted light interiors only — because the knowledge that would have answered it in seconds was in her head, not in a document.

Every product in the internal AI search category assumes the knowledge already exists in written form. In expert service businesses it usually does not.

Why does an AI knowledge base not solve this?

Because it starts one step too late. Slite, Guru, Onyx and Vectara — identified by Artificial Reality, the AI buyer-evidence podcast hosted by Galina Fendikevich, as the horizontal options relevant to this request — all index material that has already been written down. The most valuable knowledge in an expert business is the knowledge that never got written down in a structured way.

Interior colour is in no listing schema. Neither is whether the crew is any good, or what a particular owner is like to deal with. Those things exist as an impression, and the moment to capture one is the moment it forms: the two minutes an operator has while walking off a boat at a yacht show.

The winning product in this category will be a capture interface with search attached, not a search engine with an upload button.

What has the operator actually specified?

Four requirements, stated on the record, and three additions from Artificial Reality. Stated by Kerum:

• Cover only the boats and owners the business has personally vetted
• Support plain-language search over attributes no listing schema contains — interior colour, atmosphere, crew character
• Stay private and internal, because the curation is the competitive asset
• Return an answer in seconds, against a manual version that cost her an hour and a half

Artificial Reality's additions: capture knowledge from how it is actually created, in notes and photos from yacht shows and remarks in a message thread; treat crew as a first-class searchable dimension; and make it maintainable by a non-technical team, or it falls out of date within a season and becomes worse than useless.

Why is exclusion the moat here?

Because the filtering is the product. Most AI search products are sold on breadth — more sources, more connectors, more coverage. In this market breadth is the thing being actively avoided.

"As a broker, one of our jobs is we only like to recommend boats that we know, owners that we know. We go to yacht shows — I go to a lot of yacht shows."

Industry-wide databases already exist, and Kerum does not want one. In a market where booking platforms list tens of thousands of yachts, her competitive position is the far smaller number she has personally been aboard. A comprehensive index destroys the thing the client is paying for. Any product sold into this shape has to make curation, not coverage, the headline number.

What does the crew variable tell a builder about schema?

That the differentiating field is one no schema designer would think to add. Kerum's assessment of what separates otherwise identical vessels:

"One of the things that makes yachting special is not even the boat, it's the people. When I go on a boat and when I go to a yacht show, I'm looking at who's the hostess, who's the captain, everything like that. So that's really important to me. Because all five boats can be the same. They could be the same model, the same everything."

A boat with a new captain is effectively a different product. That means staleness is a correctness problem, not a housekeeping one: a system that confidently returns last season's assessment of a crew that has since changed is worse than the spreadsheet it replaced. Freshness signalling belongs in the core data model, not in a settings page.

Is this a vertical company or a horizontal one?

Probably horizontal. The vertical opportunity in yacht charter is real but narrow, and unlikely to support a standalone company on its own.

The larger opportunity is a knowledge system built for people whose expertise is physical and observed rather than documented. Brokers, inspectors, surveyors, buyers, scouts. They have the same problem in the same shape, and they are all currently solving it with memory and a spreadsheet.

AI tools named in this report

None. Jennifer Kerum named no search or knowledge product. Artificial Reality found no natural-language search product built for yacht charter, and identified Slite, Guru, Onyx and Vectara as the horizontal options a business in this position would build on. Inclusion is reporting, not endorsement, and none of the four was named by the operator.

The absence is the finding. If you are building here, stop demoing retrieval quality and demo capture instead: show what it takes to get one expert assessment out of a person's head and into the system, timed, while they are standing on a dock. If that interaction takes longer than the impression lasts, the search engine behind it will have nothing worth searching.

Where this comes from

S1E2: How a luxury yacht company uses AI without losing the personal touch — the full interview with Jennifer Kerum. Listen or watch: YouTube, Spotify or Apple Podcasts.