One workspace where the enterprise does its AI work.

Most enterprises now run AI the way they once ran shadow IT. A chat tool here, a copilot there, a few agents someone wired up over a weekend, and a workflow engine nobody fully owns. Each one has its own login, its own permissions and its own idea of what the company knows.

Ask a simple question and the gaps show. Who asked for this? Which tool acted on it? What data did it touch? What did the organization learn from it? In most companies, nobody can answer all four.

Another tool will not fix that. What fixes it is a single control plane that every person, agent, app and workflow has to pass through. That is what I mean by an operating system.

Lyrn OS is the only entry point. People, models, agents, apps and workflow engines all come in the same way, and all of them are identified before anything happens.

Apps do not call each other directly. The OS mediates every call, which means every call can be checked, recorded and stopped.

Workflow engines do not run on borrowed credentials. They act under identities the OS issues for a specific task, and those identities are revoked the moment access is withdrawn.

If you remember one idea from this page, make it this one.

Access to memory and access to apps are separate decisions. Memory access follows the reporting hierarchy. App and workflow access is granted by administrators, on its own terms.

The two never leak into each other. An app grant never widens what memory a person can reach. A memory grant never unlocks a restricted app.

Effective access is the intersection of four things: who is asking, which app and capability they are using, which memory scope applies, and any mandatory restriction in force. If any one of them says no, the answer is no.

The org chart lives in Lyrn OS. The OS decides who may see what, and Lyrn Memory enforces that decision.

By default, a manager can read the work memory of the people beneath them, directly and indirectly. Peers do not gain access to each other through a shared manager.

Reading is not administering. Visibility into work memory carries no right to purge it, edit the org chart, install apps or change the schema.

There is no private employee workspace by default. The customer tells employees plainly that this is a company-controlled environment for work only.

Legal holds, preservation orders, regulated-data limits and employee-notice obligations remain enforceable. Importing an org chart cannot switch them off.

Authorization is applied before retrieval, not only after. Memory a person is not allowed to see is never pulled into the answer in the first place.

All of this is a default. Each customer configures the policy with its own legal and HR teams.

Lyrn Memory is a separate service, and Lyrn OS requires it. It owns ingestion, retrieval, consolidation, provenance and the memory Oracle.

The OS never reaches into memory on its own authority. It reaches Lyrn Memory only through signed, scoped authorization, and Lyrn Memory checks that authorization on every request.

Lyrn Memory is currently operating as MemoryStack. Lyrn OS is not live. What you are reading here is the design.

Lyrn apps include the OS integration when they are built. Registering an app in the central directory is the only manual step.

Third-party apps connect through separately configured identity, REST and MCP interfaces. The tools a company already relies on are integrated, not rebuilt inside the OS.

The specification is complete. Lyrn OS is in design and has not been released. I am happy to walk enterprise leaders through the design in an AI Readiness Briefing.