Locality: The Filesystem for AI Agents

Why we’re turning systems of record into local, reviewable workspaces—starting with Notion.

Details Image

This post was written in Notion—and in a local file

This post lives in Notion. But I wrote it with Codex in my editor, as a local Markdown file.

Codex searched through the rest of our launch material in Notion, read Locality’s source code README, reviewed the structure I had drafted, and helped turn it into the post you are reading now. I edited alongside it, reviewed the changes, and the result stayed connected to the original Notion page.

There was no special Notion workflow inside Codex. It did what coding agents already do well: search folders, read files, connect relevant context, and edit text.

Locality made that possible by turning our Notion workspace into a local filesystem.

Files are the native workspace of agents

Coding agents are remarkably capable. You can point one at an unfamiliar repository and ask it to trace a bug, understand an architecture, update several related modules, run tests, and leave behind a reviewable diff.

Part of that power comes from the models. But an equally important part comes from the environment we give them.

Code is available as files and folders. An agent can traverse the repository, search for a concept, open only the files it needs, follow references, and combine information across the codebase. It is not restricted to a predefined sequence of actions. It can discover its own path through the work.

At their core, agents consume context and produce text. Even when an agent calls a tool, the model ultimately reasons over a textual representation of state and emits textual instructions. Text files are therefore a remarkably direct interface: they give agents durable information they can natively read, search, transform, and create.

Files also give humans and agents a shared surface. We can inspect the same content, edit it in the same tools, and understand what changed through a diff. The agent’s work does not disappear into a tool-call transcript. It remains visible and editable.

The rest of our work is hidden behind application interfaces

Most of the work surrounding our code does not have this interface.

Product plans and company knowledge live in Notion and Google Docs. Engineering work lives in Linear and Jira. Customer context lives in Salesforce and HubSpot. Support knowledge lives in Zendesk and Intercom.

These applications were designed around visual interfaces for humans. When agents need to work with them, we usually add another interface: an API, browser automation, or a menu of MCP tools such as “fetch page,” “create issue,” or “update record.”

Those tools are valuable, especially for discrete actions. But they make the agent operate through a collection of paved paths rather than exposing the underlying state as a coherent workspace.

Imagine asking a coding agent to maintain a repository entirely through GitHub API calls: fetch this file, search that endpoint, update this blob, create that commit. We do not work that way. We give the agent the repository.

Why should company knowledge work be different?

The distinction we keep coming back to is simple:

MCPs expose actions. Locality exposes state.

Sending a message or triggering a workflow is naturally an action. Understanding a launch plan, reconciling it with customer feedback, and updating several connected documents is stateful work. For that, agents need room to search, understand, compose, and edit.

Locality mounts applications as workspaces

Locality turns systems of record into local, agent-readable workspaces.

Connect your workspace and Notion appears on your computer as ordinary files and folders:

Notion pages become directories. The page body lives in page.md. Child pages become child directories. Databases and their rows become folders with Markdown bodies and structured frontmatter.

Your editor, scripts, and existing agents can work with this tree using the tools they already understand. There is no new agent framework to adopt and no Locality-specific reasoning model. If an agent can work with files, it can work with Locality.

Locality also installs guidance for supported agents, so tools like Codex and Claude already understand how to work with the mounted workspace. Agents edit content through normal file operations and use the loc CLI to find pages, inspect sync state, review diffs, and safely synchronize changes with Notion.

This is not a one-time Markdown export. Files hydrate when they are opened, Locality keeps track of remote changes, and edits can synchronize back to the original application. Notion remains the collaborative source of truth; Locality provides a local working copy.

Locality handles both sides of the translation. It converts application state into text an agent can understand, then converts textual diffs back into the application-specific operations needed to update the source.

A real workflow: writing this launch post

The workflow behind this post is a good example of what changes when an application becomes a workspace.

I began with a rough launch outline in Notion. That page lived alongside our positioning notes, launch plan, demo script, website copy, and technical architecture notes. The implementation details lived in the Locality GitHub repository.

I asked Codex to help structure the post. Locality had already installed guidance that taught Codex how to work with the mount. It used the loc CLI to locate pages and understand their sync state, while the actual searching, reading, and editing happened through ordinary files. Codex searched the launch directory, read the relevant Notion pages as Markdown, and combined them with the repository README. It proposed a narrative, wrote it into the same mounted document, and left the result for me to review and edit.

The useful part was not a single “update Notion page” action. It was the agent’s ability to move through the surrounding context, decide what mattered, and synthesize information from two normally separate worlds: our shared company workspace and our local codebase.

We use the same pattern internally before standups. An agent can review the team’s recent Git commits, combine them with project context in Notion, and prepare an update focused on decisions and blockers. The meeting starts from a useful synthesis instead of a recitation of yesterday’s work.

This is the kind of workflow that becomes natural when agents can operate on application state as files.

The hard part is getting changes safely back

Turning a Notion page into Markdown is not the hard part.

The hard part is letting an agent edit that Markdown without corrupting the system of record.

Applications contain more than visible text. They have durable identities, nested blocks, properties, permissions, attachments, concurrent collaborators, and API-specific rules. A local edit has to preserve that structure and become the smallest safe set of operations upstream.

Locality turns text diffs into safe, source-aware application operations.

Under the hood, it tracks three versions of state: what exists remotely, what exists locally, and the last version both sides agreed on. Before writing, it validates the edited document and checks whether the remote source changed. It plans block-aware operations instead of blindly replacing an entire page.

You can inspect planned changes with loc diff before anything touches Notion. Pushes are journaled for inspection and recovery. When Live Mode is enabled, straightforward changes can synchronize automatically. If Locality encounters remote drift, a conflict, an unsupported edit, or a risky plan, it pauses instead of guessing.

The goal is simple: fast when it is safe, careful when it matters.

Or, as we describe it on the website:

Sync without losing control.

A working copy shared by humans and agents

Most agent integrations are optimized around a successful action: the agent created a ticket, updated a record, or sent a message.

Locality is optimized around a shared working copy.

An agent can draft a broad change locally. A human can inspect it, rewrite part of it, or reject it. Another agent can continue the work later. Existing editors, search tools, scripts, and review workflows can all operate on the same representation.

This matters because valuable knowledge work is rarely a single API call. It is iterative. People gather context, form a point of view, revise it, and coordinate changes across several pieces of information. The work benefits from agents, but it also benefits from human judgment.

Locality gives agents room to work without giving them unchecked authority. They can explore and propose changes through files while the source application preserves identity, permissions, collaboration, and organizational truth.

The result feels less like delegating a button click and more like sharing a workspace with a capable collaborator.

The vision: one filesystem, infinite workflows

Notion is our starting point, not the boundary of the idea.

Today, Locality gives Claude, Codex, Cursor, and other file-capable agents a local workspace for Notion. Next, we want to bring the same model to other text-heavy systems of record: documents, project trackers, customer systems, support tools, and the applications where teams maintain shared context.

Imagine asking an agent to prepare a launch update using the latest product plan, recent code changes, unresolved customer issues, and current website copy. It can find the relevant state across mounted applications, synthesize it, and leave each proposed change ready for review in the system where it belongs.

That should not require someone to predefine every step as a rigid automation. Once state is available through a common interface, the agent can compose the workflow required by the task.

This is what we mean by:

One filesystem. Infinite workflows.

The long-term opportunity is a common state layer between agents and software. Applications continue to own collaboration, permissions, and the source of truth. Agents get a coherent local environment in which they can understand and improve the work spread across those applications.

Why we are building Locality

We believe the next generation of agent software will need more than access to actions.

Agents need a coherent place to understand and manipulate state. They need to see how information relates, discover context that was not explicitly handed to them, and make changes that remain inspectable by the people responsible for the outcome.

The filesystem is the most universal, composable, and transparent interface we have for that work. Every serious coding agent already understands it. Every operating system supports it. Humans already have decades of editors, search tools, scripting languages, and review workflows built around it.

Locality brings that interface to the applications where the rest of our work lives.

We are beginning with a practical promise: make Notion available as a safe local workspace for the agents people already use. But we are building toward something broader—a universal workspace layer that lets agents work across software without taking control away from the humans and systems responsible for the truth.

Try Locality

Locality is available now, starting with Notion.

Install the desktop app, connect your workspace, and use it with the agents and editors you already have. You can browse Notion as files, bring real workspace context into agent tasks, review local changes, and synchronize them back safely.

If the applications where your team works became a local workspace for your agents, what would you hand them first?

This post was written in Notion—and in a local file

This post lives in Notion. But I wrote it with Codex in my editor, as a local Markdown file.

Codex searched through the rest of our launch material in Notion, read Locality’s source code README, reviewed the structure I had drafted, and helped turn it into the post you are reading now. I edited alongside it, reviewed the changes, and the result stayed connected to the original Notion page.

There was no special Notion workflow inside Codex. It did what coding agents already do well: search folders, read files, connect relevant context, and edit text.

Locality made that possible by turning our Notion workspace into a local filesystem.

Files are the native workspace of agents

Coding agents are remarkably capable. You can point one at an unfamiliar repository and ask it to trace a bug, understand an architecture, update several related modules, run tests, and leave behind a reviewable diff.

Part of that power comes from the models. But an equally important part comes from the environment we give them.

Code is available as files and folders. An agent can traverse the repository, search for a concept, open only the files it needs, follow references, and combine information across the codebase. It is not restricted to a predefined sequence of actions. It can discover its own path through the work.

At their core, agents consume context and produce text. Even when an agent calls a tool, the model ultimately reasons over a textual representation of state and emits textual instructions. Text files are therefore a remarkably direct interface: they give agents durable information they can natively read, search, transform, and create.

Files also give humans and agents a shared surface. We can inspect the same content, edit it in the same tools, and understand what changed through a diff. The agent’s work does not disappear into a tool-call transcript. It remains visible and editable.

The rest of our work is hidden behind application interfaces

Most of the work surrounding our code does not have this interface.

Product plans and company knowledge live in Notion and Google Docs. Engineering work lives in Linear and Jira. Customer context lives in Salesforce and HubSpot. Support knowledge lives in Zendesk and Intercom.

These applications were designed around visual interfaces for humans. When agents need to work with them, we usually add another interface: an API, browser automation, or a menu of MCP tools such as “fetch page,” “create issue,” or “update record.”

Those tools are valuable, especially for discrete actions. But they make the agent operate through a collection of paved paths rather than exposing the underlying state as a coherent workspace.

Imagine asking a coding agent to maintain a repository entirely through GitHub API calls: fetch this file, search that endpoint, update this blob, create that commit. We do not work that way. We give the agent the repository.

Why should company knowledge work be different?

The distinction we keep coming back to is simple:

MCPs expose actions. Locality exposes state.

Sending a message or triggering a workflow is naturally an action. Understanding a launch plan, reconciling it with customer feedback, and updating several connected documents is stateful work. For that, agents need room to search, understand, compose, and edit.

Locality mounts applications as workspaces

Locality turns systems of record into local, agent-readable workspaces.

Connect your workspace and Notion appears on your computer as ordinary files and folders:

Notion pages become directories. The page body lives in page.md. Child pages become child directories. Databases and their rows become folders with Markdown bodies and structured frontmatter.

Your editor, scripts, and existing agents can work with this tree using the tools they already understand. There is no new agent framework to adopt and no Locality-specific reasoning model. If an agent can work with files, it can work with Locality.

Locality also installs guidance for supported agents, so tools like Codex and Claude already understand how to work with the mounted workspace. Agents edit content through normal file operations and use the loc CLI to find pages, inspect sync state, review diffs, and safely synchronize changes with Notion.

This is not a one-time Markdown export. Files hydrate when they are opened, Locality keeps track of remote changes, and edits can synchronize back to the original application. Notion remains the collaborative source of truth; Locality provides a local working copy.

Locality handles both sides of the translation. It converts application state into text an agent can understand, then converts textual diffs back into the application-specific operations needed to update the source.

A real workflow: writing this launch post

The workflow behind this post is a good example of what changes when an application becomes a workspace.

I began with a rough launch outline in Notion. That page lived alongside our positioning notes, launch plan, demo script, website copy, and technical architecture notes. The implementation details lived in the Locality GitHub repository.

I asked Codex to help structure the post. Locality had already installed guidance that taught Codex how to work with the mount. It used the loc CLI to locate pages and understand their sync state, while the actual searching, reading, and editing happened through ordinary files. Codex searched the launch directory, read the relevant Notion pages as Markdown, and combined them with the repository README. It proposed a narrative, wrote it into the same mounted document, and left the result for me to review and edit.

The useful part was not a single “update Notion page” action. It was the agent’s ability to move through the surrounding context, decide what mattered, and synthesize information from two normally separate worlds: our shared company workspace and our local codebase.

We use the same pattern internally before standups. An agent can review the team’s recent Git commits, combine them with project context in Notion, and prepare an update focused on decisions and blockers. The meeting starts from a useful synthesis instead of a recitation of yesterday’s work.

This is the kind of workflow that becomes natural when agents can operate on application state as files.

The hard part is getting changes safely back

Turning a Notion page into Markdown is not the hard part.

The hard part is letting an agent edit that Markdown without corrupting the system of record.

Applications contain more than visible text. They have durable identities, nested blocks, properties, permissions, attachments, concurrent collaborators, and API-specific rules. A local edit has to preserve that structure and become the smallest safe set of operations upstream.

Locality turns text diffs into safe, source-aware application operations.

Under the hood, it tracks three versions of state: what exists remotely, what exists locally, and the last version both sides agreed on. Before writing, it validates the edited document and checks whether the remote source changed. It plans block-aware operations instead of blindly replacing an entire page.

You can inspect planned changes with loc diff before anything touches Notion. Pushes are journaled for inspection and recovery. When Live Mode is enabled, straightforward changes can synchronize automatically. If Locality encounters remote drift, a conflict, an unsupported edit, or a risky plan, it pauses instead of guessing.

The goal is simple: fast when it is safe, careful when it matters.

Or, as we describe it on the website:

Sync without losing control.

A working copy shared by humans and agents

Most agent integrations are optimized around a successful action: the agent created a ticket, updated a record, or sent a message.

Locality is optimized around a shared working copy.

An agent can draft a broad change locally. A human can inspect it, rewrite part of it, or reject it. Another agent can continue the work later. Existing editors, search tools, scripts, and review workflows can all operate on the same representation.

This matters because valuable knowledge work is rarely a single API call. It is iterative. People gather context, form a point of view, revise it, and coordinate changes across several pieces of information. The work benefits from agents, but it also benefits from human judgment.

Locality gives agents room to work without giving them unchecked authority. They can explore and propose changes through files while the source application preserves identity, permissions, collaboration, and organizational truth.

The result feels less like delegating a button click and more like sharing a workspace with a capable collaborator.

The vision: one filesystem, infinite workflows

Notion is our starting point, not the boundary of the idea.

Today, Locality gives Claude, Codex, Cursor, and other file-capable agents a local workspace for Notion. Next, we want to bring the same model to other text-heavy systems of record: documents, project trackers, customer systems, support tools, and the applications where teams maintain shared context.

Imagine asking an agent to prepare a launch update using the latest product plan, recent code changes, unresolved customer issues, and current website copy. It can find the relevant state across mounted applications, synthesize it, and leave each proposed change ready for review in the system where it belongs.

That should not require someone to predefine every step as a rigid automation. Once state is available through a common interface, the agent can compose the workflow required by the task.

This is what we mean by:

One filesystem. Infinite workflows.

The long-term opportunity is a common state layer between agents and software. Applications continue to own collaboration, permissions, and the source of truth. Agents get a coherent local environment in which they can understand and improve the work spread across those applications.

Why we are building Locality

We believe the next generation of agent software will need more than access to actions.

Agents need a coherent place to understand and manipulate state. They need to see how information relates, discover context that was not explicitly handed to them, and make changes that remain inspectable by the people responsible for the outcome.

The filesystem is the most universal, composable, and transparent interface we have for that work. Every serious coding agent already understands it. Every operating system supports it. Humans already have decades of editors, search tools, scripting languages, and review workflows built around it.

Locality brings that interface to the applications where the rest of our work lives.

We are beginning with a practical promise: make Notion available as a safe local workspace for the agents people already use. But we are building toward something broader—a universal workspace layer that lets agents work across software without taking control away from the humans and systems responsible for the truth.

Try Locality

Locality is available now, starting with Notion.

Install the desktop app, connect your workspace, and use it with the agents and editors you already have. You can browse Notion as files, bring real workspace context into agent tasks, review local changes, and synchronize them back safely.

If the applications where your team works became a local workspace for your agents, what would you hand them first?

/