The Company Operating System

Context coverage is the metric

The most useful idea I have seen come out of teams running this seriously is treating context coverage as a tracked number: what share of the company's product, business and customer knowledge the system actually holds.

It converts a vague ambition into something with a state, and the thresholds people report are specific. At roughly 54% coverage the agent performs at the level of a junior to mid product manager: it handles backlog decisions and routine triage and nothing above that. The band where it starts contributing to strategy work, long-range roadmap and trade-off analysis, is put at 70% to 90%.

Those are one team's self-reported figures and should be read that way. The practice is what transfers. A number you track is a number that improves, and a gap you can name is a roadmap instead of a complaint.

Knowledge leakage is the real problem it solves

The pitch for this is usually speed. The durable value is that when the person who knew why the pricing model works that way leaves, the reason does not leave with them.

Every company runs on knowledge stored in exactly one head, and every company discovers which head only when it walks out. A system that holds the reasoning, not just the documents, is the first version of institutional memory that survives turnover. I went into what belongs in that layer in Skills Are Institutional Memory.

Do not summarize the transcript

The counterintuitive finding, and the one I would test first in your own setup: summarizing meeting transcripts before storing them measurably degrades recall. The reported drop is 20% to 25%, which is not a rounding error. Summaries keep what was typical about a conversation and discard the specific, the caveat, the aside where somebody explained why an obvious approach was rejected 2 years ago.

Those asides are the thing you built the system to remember. Storage is cheap and the raw file is the asset. This is the same failure I described under Compress in Context Engineering for PMs, appearing at company scale rather than in a single session.

Memory needs more than a vector database

The setups that hold up use 3 layers rather than one store. A knowledge graph for structured relationships between entities that actually relate. A vector database for the fuzzy questions, which carries most of the load, because keyword matching fails on roughly 75% of how people really ask. And raw daily markdown underneath both, unsummarized, so nothing is unrecoverable.

Skills the system writes for itself

The layer that surprised me is automatic skill generation. The agent watches for tasks that recur, and when it sees the same shape often enough it writes that sequence into a reusable skill rather than re-deriving it every time. Reported effect on recall accuracy: 31%.

That closes a loop worth noticing. Skills are how you encode what the company knows, and the expensive part has always been that somebody has to sit down and write them. A system that drafts its own from observed behavior turns the bottleneck from authorship into review, which is a much smaller job.

Rules are imperatives, and they live in 2 files

The configurations that work are split. A short execution file, kept under 100 lines, holding the guidelines that need to be read fast on every call. And a much longer file, around 800 lines, defining behavior, tone and decision principles, which is where the real constraints live.

The long file reads as commands rather than preferences. No fabrication. Back every claim. Skip the filler and the explanation of the obvious. The teams running these test the directives against real queries continuously, the way you would test anything else that ships, because a rule nobody checked is a rule nobody follows.

The separation matters more than the line counts. One file is instructions for the task. The other is the standard the output is held to, and conflating them is how you get a 900-line prompt that the model skims.

The 2 open runtimes differ exactly here, and the difference is instructive. One compacts older turns into compressed files you can open and edit, which is predictable and inspectable. The other keeps a tiered retrieval path, core memory first and deeper search after, which is more disciplined but harder to eyeball. Neither is wrong. Pick based on whether your failure mode is bloat or opacity.

The agent as gatekeeper

This is the part that changes the org rather than the tooling. Stakeholders pitch the agent before they reach a PM. It asks the clarifying questions somebody was going to have to ask, checks the request against what is already prioritized, declines the ones that do not fit without anybody having to be the bad guy, and routes the rest to whoever owns that area.

What that removes is not work. It is the 40 unstructured requests a quarter that each cost a meeting to turn into something evaluable. The agent does not decide. It makes sure that what reaches a person is a decision rather than a conversation.

Which only functions if the rules are imperatives. The published configurations are long, hundreds of lines, and blunt: no fabrication, cite the source, do not pad. Vague guidance produces a polite agent that says yes to everything, and soft rules do not hold on systems optimizing for something else, which is the same lesson in The Cheapest Token Never Arrives.

What it does to the PM job

Roughly half of a PM's week goes to reporting, stakeholder updates, demo prep and the surrounding administration. That number is not controversial and it has been true for a long time.

Automate that layer and the job does not get easier, it gets wider. Teams running this report a single PM covering 3 to 4 customer-facing domains rather than 1, with the released time going to discovery and user research. That is the actual argument for building one of these, and it is better than the efficiency pitch: not fewer PMs, but PMs doing the half of the job everyone agrees matters and nobody has time for.

The failure mode is the same one that kills every internal automation. If a person still reviews every output before it can be used, nothing moved, and I went through why in Automate the Handoff, Not the Task.