Vol. 01 / The Organizational Memory Protocol
Every conversation your team has with an AI generates knowledge that today evaporates the moment the tab closes. Osmer is the system of record for the work your colleagues do with machines. Captured, refined, and passed forward.
A note on the work
Before Salesforce, customer knowledge lived in individual notebooks and heads. When someone left, it walked out the door. Osmer proposes the same inflection for the knowledge that flows through every AI conversation your company has. The knowledge should belong to the organization, not to the inbox of one employee.
§ 01 / The shadow AI problem
The average knowledge worker now uses three to five different AI models in a working week. Each chat thread contains a small private archive of decisions, hypotheses, debugging traces, and resolved problems.
None of it is searchable by colleagues. None of it survives a tab close. When the employee leaves, it leaves with them.
We call this shadow AI: the twenty-first-century cousin of shadow IT, with one important difference. The artefacts are not files but conversations, and they are produced faster than any documentation practice can capture.
No model provider solves this. They optimise for their own walled garden. The problem is, by definition, between them.
§ 02 / Three tiers of memory
Memory in Osmer is structured as a three-tier protocol. A fact you discover in a private conversation belongs to you. A decision your team makes belongs to the team. A truth about the company belongs to the organisation. Each atom carries provenance, confidence, and a decay function. Knowledge, but with metabolism.
Private to the user. Preferences, working context, drafts.
Shared with the team. Conventions, decisions, on-call playbooks.
Visible across the company. Stack, compliance, strategy.
§ 03 / The protocol
We extract atoms, not transcripts. Each atom has a type, a confidence, a scope, a provenance, and a half-life. They are stored in pgvector for similarity, indexed for the graph, and reconciled nightly to detect drift, staleness, and contradiction.
§ 04 / Every model, one room
A unique capability
A second opinion is one keystroke away. Open a thread with Claude, ask GPT the next question, then send the result to Gemini. Osmer keeps the entire context coherent across providers.
How would we shard the events table?
Hash by tenant_id, range by week. Keeps tenants co-located while bounding hot partitions.
Send that answer to GPT-4o for a sanity check.
Concur on tenant_id hash. Suggest pg_partman for the weekly ranges; review your retention policy.
§ 05 / In practice
Three panels: the conversation, the model in use, and the knowledge atoms quietly attached to the answer, with citations, confidence, and the option to promote any atom to your team’s shared memory.
How would we shard the events table for the new region?
Given the team’s prior decision (March ’26) to standardise on hash-by-tenant_id, range-by-week, extending the same pattern to the new region keeps pg_partman config portable.
Two atoms attached this answer to past context.
A closing remark
The companies that win the next decade are the ones that remember what their people learned with machines.