Local First Software

Private AI workflows want local state

2 min read

Private AI workflows want local state.

That sounds like an implementation choice, but I think it is really a boundary choice. Once an AI tool starts reading notes, screenshots, drafts, files, browser state, or local project data, the app is no longer handling generic prompts. It is handling private working material that the user expected to stay nearby.

scope should start small

The useful question is not which model runs. It is what the model can see.

For a file assistant, that might mean the current file before the whole folder. For a notes assistant, the selected note before the whole vault. For a coding assistant, the current diff before the repository. The product should make that scope explicit instead of burying it in settings nobody reads.

{
  "workspace": "personal-notes",
  "allowedPaths": ["drafts/agent-control-plane.md"],
  "excludedPaths": ["journal/", "taxes/", "secrets/"],
  "syncDerivedOutputs": false,
  "expiresAt": "session-end"
}

derived artifacts can leak too

Privacy does not stop at the source file.

Summaries, embeddings, tags, memories, logs, and cached outputs can all contain the thing the user meant to keep private. A local summarizer may still write a sentence that should never sync. A local embedding index may make sensitive material searchable. A debug log may capture unredacted text. The derived state needs the same boundary as the source state.

local indexes need ownership

If the app builds an embedding index over notes or files, the user should know where that index lives, how it updates, and how to delete it. If a folder leaves scope, the vectors should leave too. If a note is deleted, the derivative should not hang around quietly.

I like private AI best when it is honest about that line. Keep the private work local, let the user choose what syncs, and show a receipt when anything moves. That is enough structure for the product to feel respectful instead of overeager.

Jeremy London

About Jeremy London

Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.