# Who owns the company brain? CM-011 · written 2026-08-28 · published 2026-08-29 · guide tags: context-management, agent-memory, evidence > Nobody has settled it. The contracts allocate inputs and outputs, not the derived memory record; portability is disputed; deletion has a measured residue. Nobody has settled it, and the documents you would expect to settle it do not mention the thing in question. That is the honest answer, and it is worth more than a confident one. A company brain — the term of art, as of 2026, for a store that reads your Slack, docs, calendar and agent transcripts and keeps what it extracts — accumulates an artifact that did not exist before: a structured record of what an organisation decided, when, and on whose say-so. The contracts governing these products were drafted around inputs and outputs. The record is neither, exactly. Nobody has publicly resolved what it is. Three questions follow from that, and each has public evidence pointing in a different direction: who owns the artifact, what you can take with you when you leave, and what an employee's stored memory entry is. What follows is what I could read on 28 August 2026 and nothing else. Every source is linked. Where the evidence stops, the piece stops. ## The claim, and who is making it "Company brain" stopped being a metaphor sometime in the spring of 2026. A Hacker News search for the exact phrase, restricted to submissions, returns 25 results. **Thirteen of them carry the phrase in the title and are dated between 29 April and 3 August 2026**; before that, going back to 2014, only two titles use it in anything like the current sense — a 2021 vendor blog post and a 2024 Show HN. The most-engaged of them is **Launch HN: Hyper (YC P26) – Company brain to power agentic development**, posted 3 June 2026, showing 79 points and 78 comments. Its own description of the mechanism is unusually specific for a launch post, and worth reading before anything is argued about it: Hyper ingests "Docs, Slack, Email, Calendar, Granola" and splits what it keeps into two things. *Episodes* are "the raw source items kept as the source of truth." *Facts* are "the meaning pulled out of each episode, stored as subject-predicate-object records with a plain summary and timestamps for when the fact was introduced and when it was invalidated (subject=person, predicate=works_at, object=company)." When a later fact contradicts an earlier one, "the new fact supersedes the old one instead of both looking equally true, and we never auto-discard the superseded version, so you can still ask how you landed on Monday." Every fact carries provenance and per-fact access-control tags, "which means two people on the same team can ask the same question and get different answers." Hold onto the shape of that: an entity resolved to a person, a predicate, an object, a provenance chain, a timestamp for when it stopped being true, and a rule that the superseded version is never auto-discarded. That is not a document store. It is a dossier, and most of the questions below are questions about dossiers. The same phrase is also being claimed by projects that answer the ownership question by construction. `agno-agi/scout` describes itself simply as "Open Source Company Brain", Apache-2.0, 717 stars. `getnao/sylph` — "The open-source company brain" — has 187 stars and a repository whose top-level directories are the departments of a company: `finance`, `hr`, `legal`, `sales`, `product`. It also has **no licence file**: GitHub's licence endpoint returns 404 for it, and there is no `LICENSE` at the root. An open-source company brain that has not said what open-source means for it is a small illustration of the general problem. ## Ownership, as the contracts actually have it Read the terms and you find a well-settled answer to a question adjacent to the one you asked. Anthropic's commercial terms are representative of the model-layer norm: "Anthropic agrees that Customer (a) retains all rights to its Inputs, and (b) owns its Outputs," where **"Inputs" means submissions to the Services** and **"Outputs" means responses generated by the Services to Inputs**. Clean, and the two defined terms are the whole universe of customer content. mem0's platform agreement is the one quoted at length below, and the reason is worth stating before the quotes rather than after: it is published, specific, and it resolved. Two other vendors' terms pages did not — so the asymmetry of scrutiny here reflects what could be read on one day, not a finding that mem0's terms are worse than the ones I could not reach. A vendor that publishes a detailed agreement is easier to hold to it. The agreement, dated 3 August 2026, follows the same skeleton and then adds the parts that matter here. "Customer retains all right, title and interest in and to the Customer Content," where Customer Content is "Inputs, Outputs, and any other content or information uploaded or transmitted to the Mem0 Service." Aggregate Data is then carved out: mem0 "may create aggregated and de-identified data derived from Customer Content and Performance Data," and "Mem0 shall own all right, title, and interest in and to the Aggregate Data." Both of those are ordinary SaaS drafting. The licence you grant also differs by tier, which is likewise ordinary — what makes it worth reading is the size of the difference. Paid customers grant a licence "during the Term" to provide the service, with training excluded. Free-plan customers grant "a non-exclusive, worldwide, perpetual, irrevocable, royalty-free and fully paid-up license to access, use, reproduce, modify, and create derivative works from Customer Content for any lawful purpose, including … to train and improve machine learning and artificial intelligence models." Free tiers are not the same product as paid ones, and that is the general lesson rather than a fact about one company. Now the gap. **No clause in either agreement names the extracted memory record as a category.** Is the fact `subject=person, predicate=works_at, object=company` — derived by the vendor's pipeline from your Slack, stored in the vendor's schema, in the vendor's graph — an Output? It is plausibly one: mem0 defines Outputs as what the AI Tools generate in response to Inputs, and extraction is generated in response to input. That reading gets you to customer-owned, and I think it is the better reading. It is still a reading. The clause was not written with a derived, persistent, mutating store in mind, and a reading is what you have until someone writes the clause. Two more things the reading does not cover. First, whether the *schema* — the entity resolution, the edge types, the confidence ranking — travels with the facts, or stays with the vendor as its technology. mem0's §5.1 keeps "all right, title and interest in and to the Mem0 Technology, including any enhancements, improvements, or derivatives thereto" with mem0, which is entirely standard and also exactly the boundary the question sits on. Second, exit. mem0's §10.3 says that on termination the licences terminate, use ceases, and "each party will return to the other or destroy all property (including any Confidential Information) of the other party" — a standard mutual termination clause, of the kind most agreements in this category carry. **What I could not find, there or in the other agreement I could read, was any clause obliging the vendor to provide an export of Customer Content, or naming a retrieval window.** Most of these products ship an export API; that is a product feature, which can be deprecated, and it is not the same object as a contractual right, which cannot. That distinction — *the thing the product does today* versus *the thing the agreement obliges* — is the single most useful lens in this whole area, and it applies to every vendor including the ones whose terms I could not reach. ## Exit and portability, where there is a real fight Here the disagreement is on the record, named, and current, so it can be laid out rather than resolved. **Zep's Daniel Chalef argues portable memory is a fallacy.** *The Portable Memory Wallet Fallacy: 4 Fundamental Problems*, published 19 June 2025 and updated 3 June 2026, makes four arguments. Economic: "Asking AI companies to participate in portable memory systems means asking them to voluntarily surrender their primary competitive advantage." Behavioural: users say they want control and consistently choose convenience. Technical: "AI context is domain-specific and often non-transferable … Your therapy bot doesn't need your driving destinations," and any universal standard trades simplicity against usefulness until "detailed preferences get reduced to generic tags." Security: in multi-agent memory ecosystems, "a single poisoned memory entry could propagate to dozens of agents." **Two projects are building the thing anyway.** *memorywire* is a JSON-Schema 2020-12 wire format for five memory operations — remember, recall, forget, merge, expire — with a reference implementation and "five backend adapters (sqlite-vec, mem0, Letta, Cognee, pgvector)". Its own framing of the problem is the mirror image of Chalef's third argument: the frameworks "each ship their own SDK, storage layout, and operational vocabulary. There is no shared wire format: every integration is bespoke, every migration rebuilds memory from scratch." The **Universal Memory Protocol** aims at the same target from the interoperability side — "What MCP did for tools, UMP does for memory … a portable, signed, bi-temporal record that any harness can speak and any store can serve" — with six operations including `forget`, and an ownership field baked into the record: every memory carries a `scope` with an `owner` identified by a cryptographic key. Now the part that keeps this from being a tidy story with a winner. UMP's own launch thread is where Chalef's incentive argument gets restated by a stranger with no stake in it. One commenter: "these efforts are only as good as the industry adoption that they gain: who is using this? MCP came from Anthropic, A2A from Google so they had big tech backing from day 1. As a developer, I wouldn't touch this without confidence I can get gains down the line from interoperability." Another asked for benchmarks and found none. The reception was, on the whole, sceptical. So: a vendor executive says portability will not happen for incentive, behavioural, technical and security reasons; two open projects have built the technical part he says is hardest; and the adoption question — his first argument, the economic one — is the one neither project has answered and the one the public commentary keeps returning to. **I do not think the evidence adjudicates this.** What it does establish is that the technical impossibility case is weaker than it was in June 2025, and the incentive case is untouched. There is also an academic framing worth knowing exists, though it argues at a different altitude than an engineering decision: Mario Brcic's *The Memory Wars* proposes "Network Effect 2.0," a model in which "value scales with the depth of personalized memory, creating powerful cognitive moats and unprecedented user lock-in," and names the resulting problem "cognitive sovereignty." It is a policy paper, not a portability spec, and I include it because it is the only source I found that treats memory lock-in as a structural condition rather than a procurement risk. If you are choosing a store on these grounds, [what the agent-memory vendors actually differ on](/blog/what-the-memory-vendors-differ-on) — CM-008 — compares the documented substrates, and the last of its four questions is this one: what comes out on export, and in what shape. A store of extracted facts is not the conversation it came from. ## What an employee's memory entry is This section is questions, not answers, and none of it is legal advice. I am not qualified to give any and the piece would be worse if I pretended otherwise. What follows is the text of one regulation and one measurement, put next to each other. The GDPR defines personal data as "any information relating to an identified or identifiable natural person". It separately defines **profiling** as "any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person's **performance at work**, economic situation, health, personal preferences, interests, **reliability**, behaviour, location or movements." Set that next to `subject=person, predicate=works_at, object=company`, plus a confidence ranking, plus provenance, plus a record of which of a person's stated positions were later superseded. Whether that constitutes profiling is not mine to declare. That it is a question an engineering leader should have asked *before* the pipeline went live seems hard to dispute. Article 17(1) gives a data subject the right "to obtain from the controller the erasure of personal data concerning him or her without undue delay". Article 17(2) is the sentence built for exactly this architecture, decades early: where erasure is required, the controller "shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or **copy or replication** of, those personal data." Copies and replications are what a memory pipeline manufactures. And there is now a measurement of how well erasure actually works against them. *Deployment-Time Memorization in Foundation-Model Agents* sweeps three memory-design knobs and introduces a **Forgetting Residue Score** to quantify "whether deleted information remains recoverable from derived memory tiers." Its finding, in the authors' words: "raw-only deletion leaves derived summary copies recoverable in approximately 20% of instances, and only full-pipeline purge or tombstone redaction drives worst-tier residue to zero." One in five is a number about one benchmark and one pipeline. What it demonstrates generally is cheaper than that: deletion in a system that summarises, embeds and derives is a **pipeline** property, not a row operation, and the derived tiers are where it fails. A related architectural study puts the point more bluntly still — "production failures are predominantly forgetting failures rather than recall failures, yet existing benchmarks measure only recall" — which is the authors' claim about their own 385-case adversarial surface, not an industry statistic. Which brings the section back to where it started. In the Hyper thread, a commenter asked how the product would handle California's CCPA. The founder answered, the same day: "User data is the right of the user. We don't have automations for everything yet (we're super early!) but any user has total right to request deletion, updates, or deliverance of their data, which we seek to comply with fully." About an hour earlier, in a different subthread about contradictory sources, the same founder had written: "Unlike many other memory systems, Hyper never actually deletes memories. It constantly reranks them based on confidence." Those two statements are not necessarily in conflict — a user-initiated erasure request and the automatic handling of a superseded fact are different operations, and the second sentence is plainly about the second case. I am reporting them together because **which of the two governs is precisely the unsettled thing**, it was answered candidly and in public by a founder who did not have to answer at all, and the honest state of the art is that the question arrived faster than the automation for it. Every vendor in this category is somewhere on that same gap. ## Where this actually stands Plainly, so it can be quoted: **Ownership of the derived record is unresolved in the documents.** The published contracts allocate inputs and outputs. The extracted, persistent, mutating record is most plausibly an output, and no clause I read says so. **Portability is contested by name.** A vendor executive has published a four-part case that it will not happen; two open projects have shipped formats that do the technical part; neither has demonstrated cross-vendor adoption, which is the argument's strongest leg. **Deletion is a measured problem, not a hypothetical one.** Derived tiers retain what the raw tier dropped, at a rate somebody has now put a number on for one benchmark. **The employee question has not been argued in public at all.** I looked for a treatment of it while writing this and did not find one — which is a statement about what I could find on one day, not proof that none exists. Where the honest answer is "nobody has settled this," saying so is the whole contribution. Context governance — deciding who controls what an organisation's agents remember, and on what terms — is, at this date, less a settled practice than a set of questions that get expensive when a deployment outruns them. ## Seven questions worth asking before you sign Each is answerable from documents the vendor already has, and none requires their cooperation to check. 1. **Which defined term in your agreement covers the extracted memory record?** If the answer is "it's an Output," get that in writing, because the definition was not drafted for it. 2. **What is carved out?** Aggregate, de-identified, or performance data owned by the vendor is normal; know its boundary before rather than after. 3. **Does the free or trial tier grant a different licence?** Tiered licensing is normal; the size of the gap is not always. At least one published agreement moves from a term-limited licence with training excluded to a perpetual, irrevocable one that permits it. Check which tier you are on. 4. **Is export a contractual obligation or a product feature?** Find the clause. If there is only an endpoint, you have a roadmap, not a right. 5. **What comes out, and in what shape?** Raw sources, extracted facts, the graph edges, the provenance chain, the access-control tags — these are five separate exports and a vendor may ship one of them. 6. **What does deletion mean, concretely, across every tier?** Raw store, extracted facts, summaries, embeddings, caches, backups. The published measurement says the derived tiers are where erasure fails. 7. **Does a record about a named employee's judgment get treated differently from a record about a deployment target?** If the pipeline cannot tell them apart, the answer is no, and that is a decision you have made by not making it. If you are earlier than that — still deciding what you are building — [what agent memory actually is](/blog/what-agent-memory-actually-is) is the prior question, and it is a cheaper one to get wrong. Every source above was read on 28 August 2026 from primary pages, three of them arXiv abstracts rather than full papers, and two vendor pages did not resolve at all. Contracts are amended without notice and none of the terms quoted here carries a version number. Re-read anything load-bearing rather than citing this piece for it.