Locality: The Filesystem for AI Agents

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

Blog Image

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

That wasn't an export. It wasn't a copy. It was the same document.

While I was writing, Codex searched our launch notes in Notion, read Locality's README, found related pages, and helped shape the draft inside my editor. I reviewed the changes, rewrote parts of it, and synced everything back to Notion when I was done.

There wasn't a special "Notion integration" inside Codex.

As far as the agent was concerned, it was just working with files.

That's exactly the point.


AI agents are incredibly good at working with files

Give a coding agent a code repository and it'll surprise you.

It can trace a bug across dozens of files, understand unfamiliar code, update multiple modules, run tests, and leave behind a clean diff for review.

Part of that comes from better models.

But an equally important part comes from something much simpler.

We give agents a filesystem.

A repository isn't a sequence of API calls. It's a workspace.

Agents can search it, explore it, follow references, ignore irrelevant files, and decide for themselves where the answer lives. They aren't restricted to a predefined set of actions. They discover their own path through the work.

Humans benefit from the same interface.

We read the same files, edit them with the same tools, and review changes with ordinary diffs. Nothing disappears into an opaque conversation history.

Files are a surprisingly good interface for collaboration between people and AI.


Everything else works differently

Code lives in repositories.

The rest of our work doesn't.

Product plans live in Notion.

Engineering work lives in Linear.

Customer context lives in Salesforce.

Support knowledge lives in Zendesk.

Each application has its own interface, its own API, and its own way of exposing information.

To help agents work with them, we've largely copied that model. We build integrations. We expose APIs. More recently, we've started giving agents MCP tools like "fetch page", "update record", or "create issue".

Those tools are useful.

They're also fundamentally different from giving an agent a workspace.

Imagine asking a coding agent to maintain an entire repository using nothing but GitHub API calls.

First fetch this file.

Now search for another one.

Update this blob.

Create that commit.

Technically possible.

Nobody would choose to work that way.

So why do we expect agents to work that way everywhere else?

The distinction we keep coming back to is simple.

MCPs expose actions. Locality exposes state.


Applications should feel like repositories

That's what Locality does.

It mounts applications like Notion as ordinary folders on your computer.

Pages become directories.

Content becomes Markdown.

Relationships become folders.

Your editor doesn't need to know anything about Notion.

Neither does your AI agent.

If it already knows how to work with files, it already knows how to work with Locality.


The workflow changes completely

This launch post started as a rough outline in Notion.

Around it were positioning notes, product plans, website copy, meeting notes, and technical documentation. The implementation lived in GitHub.

I asked Codex to help write the post.

It searched the mounted workspace, found relevant documents, read our README, combined information from both places, proposed a structure, and edited the same Markdown file I was already working on.

The interesting part wasn't that it updated a Notion page.

It was that it could move through the surrounding context, decide what mattered, and synthesize information across two worlds that normally don't share a common interface.

We use the same approach before standups.

An agent reviews recent commits, reads the relevant project pages in Notion, and prepares a summary focused on decisions, blockers, and open questions.

Nobody had to build a custom workflow for that.

The agent simply worked in a filesystem.


The hard part is getting changes safely back

Turning a Notion page into Markdown is easy.

Turning edited Markdown back into Notion safely is the hard problem.

Applications contain much more than text.

They have identities, permissions, nested blocks, attachments, collaborators, and their own rules about how data changes.

A local edit shouldn't overwrite all of that.

It should become the smallest safe change possible.

That's what Locality spends most of its time doing.

It tracks local state, remote state, and the last version they agreed on. Before syncing anything, it validates the document, checks for conflicts, plans block-aware updates, and lets you inspect exactly what's about to change.

When something looks risky, it stops.

Fast when it's safe.

Careful when it isn't.

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

Or, as we describe it:

Sync without losing control.


A working copy shared by humans and agents

Most agent integrations optimize for actions.

Create a ticket.

Update a record.

Send a message.

Knowledge work usually isn't like that.

People gather information, revise ideas, compare documents, and iterate before anything is final.

Locality gives humans and agents the same working copy.

An agent can draft changes.

You can review them.

Another agent can continue tomorrow.

Everything remains visible, editable, and reviewable with the tools you already use.

The application stays the source of truth.

The filesystem becomes the workspace.


The vision: one filesystem, infinite workflows

Notion is just the beginning.

The same idea applies anywhere work is stored as information rather than code.

Imagine asking an agent to prepare a launch update using the latest product plans, recent commits, unresolved customer issues, and website copy.

Today, that usually means stitching together APIs, integrations, and custom workflows.

With Locality, it means searching a workspace.

The workflow isn't predefined.

The agent builds it from the task.

That's the bigger idea behind Locality.

Not replacing the applications teams already rely on.

Giving them a common interface.


Why we are building Locality

The last twenty years of software fragmented our work across hundreds of applications.

Each one became another place where information lives.

Humans adapted.

Agents haven't.

We think the next generation of AI software needs something more fundamental than another menu of tools.

It needs a shared workspace.

The filesystem already solved that problem for software development.

We're bringing the same interface to the rest of the applications where teams work.

We're starting with Notion.

But we're building toward something much larger: a world where agents can understand, improve, and connect work across applications without taking control away from the people responsible for it.

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.

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

That wasn't an export. It wasn't a copy. It was the same document.

While I was writing, Codex searched our launch notes in Notion, read Locality's README, found related pages, and helped shape the draft inside my editor. I reviewed the changes, rewrote parts of it, and synced everything back to Notion when I was done.

There wasn't a special "Notion integration" inside Codex.

As far as the agent was concerned, it was just working with files.

That's exactly the point.


AI agents are incredibly good at working with files

Give a coding agent a code repository and it'll surprise you.

It can trace a bug across dozens of files, understand unfamiliar code, update multiple modules, run tests, and leave behind a clean diff for review.

Part of that comes from better models.

But an equally important part comes from something much simpler.

We give agents a filesystem.

A repository isn't a sequence of API calls. It's a workspace.

Agents can search it, explore it, follow references, ignore irrelevant files, and decide for themselves where the answer lives. They aren't restricted to a predefined set of actions. They discover their own path through the work.

Humans benefit from the same interface.

We read the same files, edit them with the same tools, and review changes with ordinary diffs. Nothing disappears into an opaque conversation history.

Files are a surprisingly good interface for collaboration between people and AI.


Everything else works differently

Code lives in repositories.

The rest of our work doesn't.

Product plans live in Notion.

Engineering work lives in Linear.

Customer context lives in Salesforce.

Support knowledge lives in Zendesk.

Each application has its own interface, its own API, and its own way of exposing information.

To help agents work with them, we've largely copied that model. We build integrations. We expose APIs. More recently, we've started giving agents MCP tools like "fetch page", "update record", or "create issue".

Those tools are useful.

They're also fundamentally different from giving an agent a workspace.

Imagine asking a coding agent to maintain an entire repository using nothing but GitHub API calls.

First fetch this file.

Now search for another one.

Update this blob.

Create that commit.

Technically possible.

Nobody would choose to work that way.

So why do we expect agents to work that way everywhere else?

The distinction we keep coming back to is simple.

MCPs expose actions. Locality exposes state.


Applications should feel like repositories

That's what Locality does.

It mounts applications like Notion as ordinary folders on your computer.

Pages become directories.

Content becomes Markdown.

Relationships become folders.

Your editor doesn't need to know anything about Notion.

Neither does your AI agent.

If it already knows how to work with files, it already knows how to work with Locality.


The workflow changes completely

This launch post started as a rough outline in Notion.

Around it were positioning notes, product plans, website copy, meeting notes, and technical documentation. The implementation lived in GitHub.

I asked Codex to help write the post.

It searched the mounted workspace, found relevant documents, read our README, combined information from both places, proposed a structure, and edited the same Markdown file I was already working on.

The interesting part wasn't that it updated a Notion page.

It was that it could move through the surrounding context, decide what mattered, and synthesize information across two worlds that normally don't share a common interface.

We use the same approach before standups.

An agent reviews recent commits, reads the relevant project pages in Notion, and prepares a summary focused on decisions, blockers, and open questions.

Nobody had to build a custom workflow for that.

The agent simply worked in a filesystem.


The hard part is getting changes safely back

Turning a Notion page into Markdown is easy.

Turning edited Markdown back into Notion safely is the hard problem.

Applications contain much more than text.

They have identities, permissions, nested blocks, attachments, collaborators, and their own rules about how data changes.

A local edit shouldn't overwrite all of that.

It should become the smallest safe change possible.

That's what Locality spends most of its time doing.

It tracks local state, remote state, and the last version they agreed on. Before syncing anything, it validates the document, checks for conflicts, plans block-aware updates, and lets you inspect exactly what's about to change.

When something looks risky, it stops.

Fast when it's safe.

Careful when it isn't.

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

Or, as we describe it:

Sync without losing control.


A working copy shared by humans and agents

Most agent integrations optimize for actions.

Create a ticket.

Update a record.

Send a message.

Knowledge work usually isn't like that.

People gather information, revise ideas, compare documents, and iterate before anything is final.

Locality gives humans and agents the same working copy.

An agent can draft changes.

You can review them.

Another agent can continue tomorrow.

Everything remains visible, editable, and reviewable with the tools you already use.

The application stays the source of truth.

The filesystem becomes the workspace.


The vision: one filesystem, infinite workflows

Notion is just the beginning.

The same idea applies anywhere work is stored as information rather than code.

Imagine asking an agent to prepare a launch update using the latest product plans, recent commits, unresolved customer issues, and website copy.

Today, that usually means stitching together APIs, integrations, and custom workflows.

With Locality, it means searching a workspace.

The workflow isn't predefined.

The agent builds it from the task.

That's the bigger idea behind Locality.

Not replacing the applications teams already rely on.

Giving them a common interface.


Why we are building Locality

The last twenty years of software fragmented our work across hundreds of applications.

Each one became another place where information lives.

Humans adapted.

Agents haven't.

We think the next generation of AI software needs something more fundamental than another menu of tools.

It needs a shared workspace.

The filesystem already solved that problem for software development.

We're bringing the same interface to the rest of the applications where teams work.

We're starting with Notion.

But we're building toward something much larger: a world where agents can understand, improve, and connect work across applications without taking control away from the people responsible for it.

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.

/