Google is right about the boring part.
The missing primitive for AI knowledge is not another dashboard, another SaaS catalog, or another proprietary graph. It is a format simple enough to survive tool churn.
That is why I like the Open Knowledge Format. The spec is almost aggressively plain: Markdown files, YAML frontmatter, normal links, optional index.md files, optional log.md files, and permissive consumers.
That restraint is the point.
If a human can read it, an agent can read it. If Git can diff it, a company can audit it. If the format is just files, the knowledge does not die when a vendor changes its API.
But OKF is not an operating system for a company. It is the exchange layer.
That distinction matters.
What OKF Gets Right
OKF formalizes a pattern many agent builders already use: a directory of Markdown documents with a small amount of structured metadata at the top.
Each file represents a concept. The type field tells the consumer what kind of concept it is. Links express relationships. The body carries the messy context: schemas, examples, runbooks, citations, assumptions, and history.
This is good design because it does not pretend every company shares the same ontology.
A BigQuery table, pricing policy, incident runbook, sales playbook, and API endpoint can all live in the same shape without forcing a universal schema. The format gives agents enough structure to traverse the knowledge, without turning every producer into a standards committee.
That is why OKF should exist.
It makes knowledge portable.
Where OKF Stops
The problem is that companies do not only store knowledge. Companies act.
A lead is not just a concept. It has a lifecycle.
A customer interaction is not just a note. It has provenance, status, ownership, and follow-up obligations.
A meeting transcript is not just searchable text. It should create tasks, update account context, change priorities, and teach the next agent what happened.
This is where a pure knowledge format runs out of road. OKF can describe a playbook. It cannot enforce the playbook. It can link to a table. It cannot decide whether an agent is allowed to update the table’s source of truth. It can represent a runbook. It cannot run the incident response loop.
That is not a flaw in OKF. It is scope discipline.
The mistake would be treating the format as the system.
My Mental Model
My current view is that OKF gets the file shape right, but the file shape is only the first layer.
A useful AI-native company system needs at least four layers:
- Memory: local, readable company state.
- Verbs: deterministic tools that create, update, validate, import, repair, and query that state.
- Judgment: persistent instructions for how agents should use those tools.
- Feedback: a loop that compares what happened against what should have happened.
The memory layer is the closest piece to OKF. It should be local, offline-first, and boring: Markdown files, frontmatter, links, records, transcripts, messages, notes, opportunities, tasks, and operating context.
But memory alone is not enough.
A folder full of Markdown can become a junk drawer. Agents will freestyle edits. Imports will create ugly filenames. Counters will drift. Fields will split into singular and plural variants. Links will break. The system will still be readable, but it will stop being reliable.
That is why a company needs verbs.
An agent should not manually invent the structure of a lead file every time. It should call the command that creates a lead, checks the counter, writes the frontmatter, validates the result, and fails loudly when something is wrong.
The file remains the source of truth. The tool makes the truth valid.
SKILL files sit one level above the tools. They encode operational judgment:
- which command to use
- which flags matter
- what to validate before writing
- when to stop and ask
- what external data is allowed to leave the repo
- how to avoid repeating known mistakes
This is the part most ‘company brain’ discussions understate. Context is not enough. Agents need practice. Practice has to be written down.
The harness is the part that connects those pieces into a loop:
- Observe what happened.
- Write it into durable company memory.
- Use deterministic tools to change state safely.
- Use SKILL files to keep the agent inside the operating practice.
- Validate the result.
- Feed the new state back into the next decision.
That is closer to an operating system than a knowledge base.
The YC Prompt
Y Combinator recently described this opportunity as an AI operating system for companies.
Their framing is right: the best AI-native companies make the entire company queryable. Meetings, tickets, customer interactions, and decisions become legible to an intelligence layer. The company stops acting like an open loop and starts acting like a closed loop.
That phrase matters: closed loop.
Most companies make a decision, ship the work, and maybe inspect the outcome weeks later. A closed-loop company watches what happened, compares it to what should have happened, and adjusts.
But the hard part is not the chatbot. The hard part is the connective tissue.
You have to ingest the artifacts. You have to preserve provenance. You have to normalize messy state. You have to expose safe actions. You have to validate every mutation. You have to teach agents the operating rules. You have to make the system recoverable when the agent is wrong.
This is why I do not think ‘AI operating system’ should mean ‘one more app with a search box.’
It should mean a harness.
The Critique Of My Own Approach
The honest critique is that my preferred approach is more flexible than OKF, but also more fragile.
OKF wins by refusing to own too much. It does not care whether your business calls something a lead, account, opportunity, deal, project, or customer. It just gives you a document shape that can travel.
An operational company system, by contrast, has to care. A real company has domain rules. Leads are not contacts. Contacts belong to accounts. Opportunities may become projects. Meetings create follow-ups. Messages belong to conversations. A validator has to know the difference.
That is the power and the danger.
The more domain-aware the system becomes, the more useful it becomes. It can stop bad state before it enters the company memory. It can help an agent do the right thing instead of merely finding the right file.
But it also becomes easier to overfit the system to one company’s habits. Naming drift becomes a problem. Tool wrappers become a problem. Counter files become a problem. Import edge cases become a problem. Skill routing becomes a problem.
This is where OKF is a useful corrective. It reminds me to keep the storage layer boring and portable. If the system cannot degrade gracefully into a readable bundle of Markdown files, it is too clever. If the tools become the only way to understand the state, they have failed.
The lesson is not ‘Markdown solves companies.’
The lesson is: Markdown gives agents something durable to read. Tools give agents safe verbs. Skills give agents operating judgment. The harness turns that into a loop.
The Stack I Want
The final shape is simple:
OKF is the format.
Markdown-backed company memory is the substrate.
Deterministic tools are the verbs.
SKILL files are the judgment layer.
The company loop is the product.
That is the direction I am exploring privately. I am working on stealth alpha/beta products around this, but there is no public implementation available beyond what I am describing here. I will share public links later when the work moves from alpha/beta to public release.