YC’s company-brain thesis: turn know-how into usable instructions
Contents
YC’s company-brain thesis
From scattered know-how to usable instructions
Y Combinator’s Summer 2026 Requests for Startups includes “Company Brain,” by Tom Blomfield. His proposal focuses on fragmented business know-how becoming maintained instructions AI can use to do work. That is a more specific thesis than “private data is a moat,” and it leaves founders with a demanding product problem.
What the original says
The original Company Brain request describes knowledge scattered across people and work systems. Blomfield proposes gathering it, organizing it, keeping it current and making it usable as executable skills for AI. He distinguishes this from company-wide search or a document chatbot. If the page opens another batch, select Summer 2026.
The request is an invitation to build, not evidence that any particular implementation is reliable or commercially successful. It does not endorse HeyBrain. The category’s appearance on the list also does not establish that incumbents cannot compete or that proprietary information automatically creates a durable advantage.
Our reading: a source is not yet a procedure
The following is our interpretation, rather than an additional claim attributed to YC: retrieving the paragraph that mentions an exception is only part of the job. A usable procedure must establish when that exception applies, which information is required, who can approve it and what happens when the evidence is incomplete.
Imagine a fictional software team whose delivery-date exception process is scattered across a policy page, examples in chat and one operations manager’s memory. A search result may locate the policy. A working instruction needs to resolve the gaps before an agent can apply it.
A narrow example of the missing work
This is an original fictional procedure sketch, not YC’s example and not a tested automation. It does not authorize an agent to make promises to customers.
| Part of the job | Instruction the team would need to establish |
|---|---|
| Trigger | A requested delivery date falls outside the published standard schedule. |
| Required evidence | Current schedule, requested date, work scope and responsible team’s capacity assessment. |
| Rule | Use only the approved exception policy; prior chat approvals are examples, not blanket authority. |
| Missing information | Return the missing field and responsible owner rather than inventing a delivery commitment. |
| Output and authority | Prepare a recommendation for the operations owner; do not send or approve a customer promise. |
Run the sketch through one case
In the fictional case, the requester supplies the date and work scope, but no capacity assessment. The procedure’s completed outcome is a request for that assessment, addressed internally to the responsible team. It does not produce a plausible-looking date or copy an exception from another customer.
That may look less impressive than a fully autonomous demonstration. It is more informative: the product has identified what it does not yet know and stopped before exercising authority it does not have. A later assessment could support a recommendation; sending a commitment would remain a separate authorized step.
The hard product work is now visible. Someone must establish the policy, maintain the capacity source, resolve conflicts, update the procedure and control its actions. Indexing more chat messages does not automatically perform those jobs.
A useful founder question is smaller than the category
Our suggestion is to start with one recurring procedure whose current owner can explain success, exceptions and failure. Compare the existing work with the proposed assisted route, including human correction and upkeep. A useful answer interface may be sufficient; execution is not mandatory just because the category sounds ambitious.
Do not treat the number of connected systems as the result. Ask whether the selected work becomes more dependable at an acceptable total cost, and whether the system stops appropriately when instructions or authority are missing. The pilot evaluation example makes those downstream costs explicit.
Keep the ambition and the attribution separate
YC supplies the historical thesis. The example and product judgment here are ours. Neither establishes a winner, a market size or a moat for HeyBrain or anyone else.
For the human work of keeping decisions current, see the company second-brain workflow. For a first source-to-answer system boundary, see the scoped architecture guide. The opportunity is easier to examine once it becomes a specific job with an observable result.
Prepared by HeyBrain Editorial Team with AI assistance. Examples are fictional illustrations, not observed customer incidents or product tests. This correction retains the original publication date and corrects the earlier account. Primary sources were checked on 13 October 2026.
