# Loom — The data plane for enterprise AI **Why the AI substrate under every organization will be built once, and why it hasn't been yet.** **Author:** Miguel Frasco. **Copyright © 2026 Miguel Frasco. All rights reserved.** **Version:** v3 · business-focused rewrite. **Last updated:** 2026-07-28. Companion prototype (hidden `/v2` landing): `docs/landing-v2-data-plane/`. Substrate itself is public to founders at [github.com/miguelfrasco/Loom](https://github.com/miguelfrasco/Loom) under proprietary license, and runs live at [itsloom.app](https://itsloom.app). --- ## Contents - [Executive summary](#executive-summary) - [Part I — The shift](#part-i--the-shift) - [Part II — What Loom is](#part-ii--what-loom-is) - [Part III — Four things Loom makes true](#part-iii--four-things-loom-makes-true) - [Part IV — Why now, and why hasn't this been built yet](#part-iv--why-now-and-why-hasnt-this-been-built-yet) - [Part V — Where Loom is today](#part-v--where-loom-is-today) - [Appendix A — What's already built](#appendix-a--whats-already-built) - [Appendix B — Glossary](#appendix-b--glossary) - [Appendix C — Change log](#appendix-c--change-log) --- ## Executive summary Every organization is quietly turning into a memory problem. AI has changed what work looks like inside a company. A year ago, "AI at work" meant an employee opening ChatGPT in a browser tab and copy-pasting the result. Today, AI runs inside the tools people already use — Cursor writes code, Copilot writes documents, Claude drafts contracts, and background agents run for minutes without human input. Each of them needs the same thing: **shared context they can ask questions to.** Every organization is building that shared context by accident. It scatters across GitHub issues, Notion pages, Slack threads, Google Drive folders, and per-employee memory in each AI tool. It is inconsistent, ungoverned, and impossible to prove compliant when a regulator asks. And it grows every week, because every new AI tool wants its own copy of it. **Loom is the substrate underneath.** A shared, tenant-isolated, governance-first memory layer that every AI tool inside an organization can query through one standardized protocol. It runs today at [itsloom.app](https://itsloom.app), with a working v1, real code, one active tenant, and a substrate that already produces cryptographically-signed audit evidence for every access. Loom makes four things true, by design: 1. **Data stays where it should stay.** Every organization gets its own isolated slice of the substrate. Personal data is redacted at ingest and stored encrypted, released only to authorized readers. 2. **Every answer is provable, not just plausible.** Every access decision runs through one policy engine; every change writes to a signed audit chain. When regulators ask *why did the AI say this?*, Loom produces a signed evidence pack — without engineering effort. 3. **No lock-in on AI economics.** Organizations bring their own AI-vendor contracts (OpenAI, Anthropic, whoever) to Loom. Loom never sits in the AI-token flow. Costs scale with the AI market's price competition, not with our margin. 4. **Cross-organization by signed agreement.** When partners, subsidiaries, or joint ventures need shared context, Loom's federation layer lets them share it bilaterally, tier-capped, and revocable. This is a primitive incumbent SaaS platforms structurally cannot ship — and it's what makes Loom a category rather than a feature. **The window.** The AI stack is unbundling in every direction. Models, tools, and agents each pick and mix vendors dynamically. But the layer they all ask questions to hasn't unbundled yet — it's still stuck inside each application. The company that ships the substrate everyone queries against, before regulation forces it or an incumbent bolts something on top of what they already have, defines the category. Loom is that bet. --- ## Part I — The shift Two shifts drive the substrate's necessity. The rest of this document is built around both. ### 1.1 From documents to substrates Organizations used to run on documents. Contracts, memos, meeting notes, policy manuals, product specs — the document was the unit of knowledge, and everyone knew where to find them. Search was the way you found the right document. AI does not work that way. When an AI system needs context, it does not want a document — it wants an answer. It does not want the Notion page about the pricing decision; it wants the pricing decision, extracted and structured, with the reasoning attached. It does not want the Slack thread; it wants the conclusion. That reversal is quiet but total. Every AI-native workflow — code assistants, meeting-note takers, compliance auditors, sales-intelligence bots — is silently building a queryable substrate under the surface. But each is building its own. GitHub Copilot builds one. Cursor builds another. Notion AI builds a third. None of them talk to each other, none of them share governance, none of them can produce audit evidence. The organization ends up with as many partial memory substrates as it has AI tools. Every substrate contains a fraction of the truth. None of them contains all of it. **The shift Loom bets on: the substrate becomes the unit of enterprise memory. Documents do not disappear — they become one of many sources that populate the substrate. AI tools stop building their own memory and start querying a shared one.** ### 1.2 From tools to substrates that tools query The same shift is happening on the tool side, backwards. Two years ago, every AI product was locked to a model. ChatGPT was OpenAI. Copilot was OpenAI-through-Microsoft. If you wanted to switch models, you switched products. Today, Cursor is one of the fastest-growing developer tools in history, and it does not run one model — it runs many. It routes between OpenAI, Anthropic, and others dynamically based on the request, the latency, and the cost. GitHub Copilot has followed. Claude Code has followed. Amazon Bedrock offers dozens. The tools layer has unbundled from the models layer. The tools became thin — orchestration, interface, workflow — and the models became interchangeable underneath. Loom bets the same unbundling is coming for the layer *above* the tools. Right now, every AI tool bundles its own memory: Cursor knows what you told Cursor; Copilot knows what you told Copilot. The memories do not cross tool boundaries. That is not sustainable for the organization — the same person asks Cursor and Copilot the same question and gets two different answers because they have two different substrates. **The next unbundling is the substrate unbundling from the tools. The tools become thin; the substrate becomes thick and shared.** ### 1.3 The layer everyone assumes will exist Both shifts have the same asymptote: an organizational memory substrate that every AI tool can query, that produces evidence for regulators, that respects tenancy boundaries, that survives when a vendor gets acquired or the model of the day changes. Every serious incumbent — Microsoft, Google, Salesforce, Databricks — assumes this layer will exist. Their strategies for the next five years bake it in. But none of them can build it themselves, for a reason that is not obvious until you look at it closely: a platform that offers cross-organization federation becomes an information-sharing intermediary between its customers, and every major platform's business model is incompatible with that classification. **The substrate the industry is quietly assuming will exist can only be built by a company that does not already run one of the big platforms.** That is the window Loom is walking through. --- ## Part II — What Loom is **Loom is a shared, tenant-isolated, governance-first memory and context substrate for AI.** Any AI tool an organization uses — code assistants, agent frameworks, compliance auditors, sales copilots, custom in-house agents — connects to Loom through a single standardized protocol (Model Context Protocol, or MCP). Through that connection, tools ask Loom questions ("what did the pricing decision look like?"), remember things ("this meeting produced the following decision"), and share context ("the M&A team needs read access to this decision, tier-capped"). Everything else the substrate does — isolation, redaction, governance, audit — is not something the user or the tool has to configure. It's what the substrate *is*. **What already exists as of Q3 2026:** - A running v1 at [itsloom.app](https://itsloom.app). Not a slide deck; not a prototype. Live code, one active tenant, real memory. - The four capabilities in Part III are implemented in the substrate today. Signed audit chains produce Merkle-rooted evidence daily. Personal data is redacted at ingest and stored in an encrypted vault. Every access decision runs through one policy engine. Bring-your-own-key credentials are already supported for OpenAI and Anthropic. Cross-organization sharing agreements are a first-class database object with bilateral signing and one-way revocation. - Retrieval works three ways: semantic search over embeddings, hybrid retrieval that fuses semantic with keyword search, and a knowledge graph you can walk. All three run today. - A public MCP endpoint that any MCP-capable AI client (Cursor, Claude Desktop, custom agents) can connect to with a personal access token. - The substrate code is under proprietary license in a private GitHub repository. Every design decision that shipped is recorded in versioned specifications inside the repository. None of Part III is speculation. What *is* still open is scale — this is v1, one tenant, modest infrastructure. What is *not* still open is whether the substrate does what this document says it does. It does. --- ## Part III — Four things Loom makes true ### 3.1 Data stays where it should stay Every tenant on Loom gets its own isolated slice of the substrate. Not a shared table with a "tenant_id" column that keeps tenancies apart with careful queries — a physically-separate database schema, with its own tables, its own indexes, its own permissions. A query in one tenancy cannot see data in another tenancy. It does not matter how the query is written; the substrate does not allow cross-tenancy reads through the normal data path. Personal data — email addresses, phone numbers, credit-card numbers, national IDs, IP addresses — is detected at ingest, *before* the content reaches any AI model. The personal values are removed from the content and replaced with anonymous tokens. The original values are stored encrypted in a separate vault, and are released only to readers who are authorized to see them. If a person later exercises their GDPR right to erasure, the encrypted vault entry is destroyed, and every downstream reference to that person becomes non-recoverable. Both mechanisms — schema-per-tenancy isolation and the redaction vault — run today. They are not features layered on top of the substrate; they are what the substrate is. ### 3.2 Every answer is provable, not just plausible When an AI system helps a bank approve a loan, a hospital prioritize a patient, or a regulator's own agent draft a policy, the question that comes next is always the same: *why did the AI say this?* Every serious buyer of AI substrates asks a version of it. Every regulator is preparing to require the answer. Loom is built around producing that answer without engineering effort. Every access decision — who can read what, at what governance tier, under what sharing agreement — runs through one policy engine, and returns a signed verdict. Every change to the substrate — every ingested piece of content, every extracted decision, every sharing agreement created — writes to an append-only audit chain, signed with a cryptographic key. Every 24 hours, the day's audit entries are hashed together into a summary root that can be independently verified against a public endpoint. The result: for any AI-supported decision, Loom can produce a signed evidence pack that shows what data the AI saw, what governance rules applied, and who authorized what — reproducibly, without asking anyone. ### 3.3 No lock-in on AI economics Every enterprise AI product today sits between the customer and the AI vendor. Microsoft charges you for a Copilot seat, then pays OpenAI on your behalf, then marks up the token cost. Google Vertex charges you for models plus the pipeline. Every layer of intermediation adds margin, and every layer makes the customer's AI economics depend on the intermediary's pricing decisions. Loom is designed to not be that intermediary. Organizations bring their own API credentials for OpenAI, Anthropic, Google Vertex, or any other AI vendor they have contracted with. Loom stores those credentials encrypted, uses them to make the AI calls the substrate needs, and never sits in the token flow — the customer pays their AI vendor directly. Two consequences follow. First, Loom's pricing is predictable — a per-seat number, unbundled from the volatile AI compute cost. Second, when the AI market's price competition drives token costs down 90% (which it will, and is already doing), the savings flow to the customer, not to Loom. Every customer's AI economics track their own vendor's price curve, not our margin. The reasonable objection is that this makes Loom less profitable per customer than a token-marked-up alternative would be. That is correct, and it is the point. Loom monetizes the substrate, not the token flow. ### 3.4 Cross-organization by signed agreement Every serious enterprise conversation about AI eventually reaches the same wall: **the AI would be much more useful if it could see the other organization's data too.** Two partners in a supply chain. A parent company and its subsidiary. A regulator and the firm it regulates. An M&A target and an acquirer during diligence. Every incumbent AI platform hits a structural block at this wall. If Salesforce lets Company A's AI query Company B's Salesforce data — even with consent — Salesforce becomes an information-sharing intermediary between the two customers, with a legal exposure the platform's business model cannot absorb. The same is true of Microsoft, Google, Oracle, Databricks. The bigger the platform, the harder the block. A substrate has different economics. Loom treats cross-organization sharing as a first-class object: two organizations enter a bilateral sharing agreement, signed by both, tier-capped (only certain kinds of content can flow), workspace-scoped (only certain projects), and revocable one-way (either side can shut it off). All shared data flows cross-tenancy tokenized, so personal information remains under the source organization's custody. Every cross-organization query writes to both organizations' audit chains. Two organizations can collaborate through AI on shared work without either party giving the other its full memory. **This is the primitive incumbents structurally cannot ship, and it is what makes Loom a category rather than a feature.** --- ## Part IV — Why now, and why hasn't this been built yet ### 4.1 Regulation is arriving fast The EU AI Act is the first major law to explicitly require organizations to produce evidence for AI-assisted decisions. Its Article 12 requires that high-risk automated decision-making systems produce audit-quality records that show what data went in, what governance applied, and how the decision was reached. Full enforcement lands during 2026 for high-risk applications. Every sector-specific regulator — banking (EBA), insurance (EIOPA), pharma (EMA), healthcare (national bodies) — is aligning its own rules to the same shape. The US SEC, HHS, and FTC are on similar tracks with different mechanisms. Every organization deploying AI in a regulated setting will need audit evidence per decision, within 18 months. Most cannot produce it today. **Loom's audit chain already produces it, natively.** ### 4.2 Every incumbent has a structural block The obvious question is: why isn't Microsoft, Google, Databricks, or Salesforce building this? They are — but around what they already have. Microsoft's substrate story is Copilot Memory; Databricks' is Unity Catalog for AI; Salesforce's is Data Cloud. All three are bounded by the same limit: they can only govern data that lives inside their platform. They cannot become the cross-platform substrate under the entire enterprise AI stack, because their business model depends on that substrate being *inside* their platform, not underneath everyone's. And none of them can offer cross-organization federation, because doing so re-qualifies them under common-carrier and platform-intermediary regulation their business model cannot absorb. **The category is open. The obvious builders are blocked. A substrate-first company is what fills it.** ### 4.3 The tools have already unbundled The final piece of "why now" is that the tools layer has already done the unbundling Loom is betting on. Cursor, GitHub Copilot, Claude Code, and Bedrock all route dynamically between models. Nobody serious in 2026 is locked to one AI vendor — the tools handle that already. The unbundling of substrate from tools is the same architectural pattern extended one layer down. The organizations that have adopted these unbundled tools are already asking the next question: how do we govern memory across all of them? Right now, the answer is "we don't." Loom is the answer that lets them say "we do." --- ## Part V — Where Loom is today **What ships today:** - V1 running at [itsloom.app](https://itsloom.app), one active tenant, ~15,000 lines of substrate TypeScript. - All four capabilities in Part III implemented. Signed audit chain producing Merkle summary roots daily. Personal-data vault operational. Policy engine returning signed verdicts on every access. Bring-your-own-key credentials for OpenAI and Anthropic in production. - Public MCP endpoint compatible with any MCP-capable AI client (Cursor, Claude Desktop, GitHub Copilot through adapters, custom agents). - Three retrieval methods running: semantic search, hybrid retrieval, knowledge-graph traversal. **What comes in the next 12 months:** - **Design partners in regulated verticals** — 3–5 lighthouse engagements at design-partner terms, chosen for regulatory profile (banking, insurance, pharma, automotive, healthcare). Each engagement co-defines the substrate for a vertical and produces a case study. - **SOC 2 Type II readiness kickoff.** The substrate produces the required evidence natively (signed audit chain, encryption, retention, append-only usage log), but certification requires the observation clock started with an audit firm and a compliance stack (policies, incident response, vendor risk) sitting alongside the substrate. Every design partner's procurement team will ask about SOC 2 status in week one — the clock has to start now. - **Open-source reference implementation of the protocol.** So third-party AI tools can integrate with Loom-shaped substrates without our permission. This is how the substrate turns from a product into a category. - **Signed evidence per answer.** Before EU AI Act Article 12 enforcement lands, every answer Loom returns carries a self-verifying evidence bundle. Extends what the audit chain already does. - **Category framing.** *"The data plane for enterprise AI"* is an unowned label with the right shape, but it is not yet a procurement budget line. A year of consistent language use in industry press and procurement documents decides whether the category name enters the vocabulary or fades. **The honest risks:** - **Distribution.** A great substrate with three users is invisible. The regulated-vertical design-partner motion is how the substrate turns into a purchase order; the open-source reference is how it turns into a category the industry talks about. If neither lands, the technical lead evaporates on a 12–24-month clock. - **Incumbent gravity.** Microsoft, Google, or Databricks could ship a "substrate" story that is less clean but is bundled into everything an enterprise already buys. The mitigation is the federation primitive — the piece incumbents structurally cannot ship. - **Key-person concentration.** The current substrate was built by one person. Bus factor is one. The next material hire is a technical co-founder. Every category-defining infrastructure company of the last twenty years — AWS, Stripe, Databricks, Snowflake, MongoDB, HashiCorp — succeeded by owning the durable substrate under a rapidly-changing application layer above it. AI applications will keep changing. AI models will keep changing. Enterprise memory and governance will not. **Loom is the substrate for the second.** --- ## Appendix A — What's already built A quick reference for anyone who wants to confirm this document is not aspirational fiction: - **Substrate v1:** 78 database tables across a shared public schema and per-tenant content schemas; approximately 45 scheduled background jobs; 24 database migrations; approximately 15,000 lines of TypeScript in the substrate core. - **Retrieval:** semantic search over vector embeddings, hybrid retrieval fusing semantic with keyword search, and a knowledge graph you can walk. All three run today. - **Audit chain:** append-only, signed with Ed25519 cryptographic keys, daily summary roots (Merkle-shaped) computed by a scheduled background job. Public endpoint lets external parties verify the chain's integrity. - **Personal-data vault:** AES-256 encryption with authenticated additional data binding the encrypted value to its tenancy. Deterministic tokenization for repeated values within a tenancy — so GDPR erasure is a single vault deletion. - **Federation:** cross-organization sharing agreements as first-class database objects. Bilaterally signed, tier-capped, workspace-scoped, immutable once signed, revocable one-way. - **Client protocol:** MCP endpoint compatible with Cursor, Claude Desktop, GitHub Copilot (through adapters), and any other MCP-capable AI client. --- ## Appendix B — Glossary - **AI substrate.** The data + governance layer under an organization's AI tools. Where memory, permissions, and audit evidence live. - **MCP (Model Context Protocol).** A recent open protocol for how AI tools talk to context / memory servers. Loom is MCP-native. - **Tenancy.** An organization on Loom. Each tenancy is physically isolated from every other tenancy. - **Audit chain.** A cryptographically-signed, append-only record of every state change on Loom. - **Merkle root.** A cryptographic summary of a batch of audit entries that lets someone verify the batch's integrity without reading every entry. - **BYO-key (bring your own key).** An arrangement where the customer, not Loom, holds the AI-vendor contract. Loom uses the customer's own credential to call the AI models the substrate needs. - **Sharing agreement.** A bilateral, signed record allowing two tenancies to exchange context under stated conditions (tier caps, workspace scope, revocation rights). - **Design partner.** An early customer who co-defines the product with the vendor in exchange for reduced pricing and hands-on shaping influence. - **Data plane.** The layer of an infrastructure stack that moves and stores the actual data (as opposed to the control plane, which configures the system). Loom is a data plane for AI. --- ## Appendix C — Change log - **v3 · 2026-07-28** — Business-focused rewrite. Compressed from ~9,000 words (v2.1) to ~4,000 words. Reframed around two shifts (documents → substrates; tools → substrates that tools query) rather than three — the previous "portable individual identity" shift was a decade-out consumer arc that did not belong in an enterprise substrate pitch. Six substrate guarantees compressed into four business capabilities (data isolation + PII merged into one; policy engine + audit chain merged into "provable governance"; BYO-key preserved; cross-organization federation preserved). Technical jargon reduced to the minimum required to demonstrate the substrate is real and running. Regulatory detail compressed. Pricing, sales, and roadmap-chunk reference material removed from the main body; the "what's already built" concrete anchor moved to Appendix A. The whitepaper is now readable in one sitting by a business audience, while still naming enough of the substrate's actual mechanisms that a technical reader can verify the argument against the code at [github.com/miguelfrasco/Loom](https://github.com/miguelfrasco/Loom). - **v2.1 · 2026-07-28** — Editorial polish on v2. Corrected Part III count (five → six guarantees), reverted the three-shifts conditional to the honest version, renamed §2.1 heading, added SOC 2 Type II readiness kickoff to the 12-month plan, softened design-partner engagement wording. Filename renamed from `loom-data-plane-whitepaper-v1.md` to `loom-whitepaper.md`. See git history for details. - **v2 · 2026-07-28** — Narrative-first restructure of v1. Executive summary rewritten as one page of pure narrative. Reference material moved to appendices. See git history for details. - **v1 · 2026-07-27** — Original mixed-audience business + technical whitepaper. See git history.