Every AI vendor now offers some version of a local mode. If you run technology or operations, the useful question is not whether the model runs on the laptop. It is where the authoritative copy of your organization's data lives, and who holds the switches on it.
In July 2025, TechCrunch reported that search engines were indexing links to ChatGPT conversations. Its follow-up reported that OpenAI removed the feature from ChatGPT that allowed users to make their public conversations discoverable by search engines. I am not calling that a breach. I am pointing at the control surface: the vendor owned the setting, the storage, and the decision to take it away.
The test: what is left when the network is gone
The Ink and Switch essay on local-first software gives the cleanest definition I know. It describes how cloud apps work:
In cloud apps, the data on the server is treated as the primary, authoritative copy of the data; if a client has a copy of the data, it is merely a cache that is subordinate to the server.
Local-first inverts that. My shorthand for buyers is to cut the network and see which copy is still standing. If the answer is a cache, you bought a cloud product with a local skin.
I build Team-X, an open-source, local-first desktop app for running AI-agent organizations. I checked it against this test at tag v3.2.1, and I am reporting what the code shows, including where my own slogan had to be narrowed.
What Team-X puts on your machine
- The database. One SQLite file in the user-data directory. The connection factory applies three pragmas, including write-ahead logging, which SQLite documents as giving more concurrency because readers do not block writers and a writer does not block readers. SQLite itself lists desktop application file formats as a standard use.
- The vault. File contents sit on disk. Name, size, SHA256, and tags sit in the database. A verify call re-hashes a file and reports whether it matches.
- Search. An FTS5 full-text index lives in the same database file and is kept current by triggers. No search service is involved.
- Secrets. Provider API keys go to the operating system credential store through keytar. The keytar project documents the backing store for each platform: Keychain on macOS, libsecret on Linux, and Credential Vault on Windows. Non-secret provider settings stay in the database.
What the process is allowed to do by default
This is the half most evaluations skip. Four findings at v3.2.1:
- No analytics SDK. The repo has seven package manifests. A search of them for the names of common analytics and crash-reporting products returns nothing, and neither does a search of the source. The word telemetry in the app means local cost accounting.
- No automatic update check. The update call has exactly one call site, reached from a button in Settings. Auto-download is switched off, so installing is a second click.
- A fenced UI. The renderer's content security policy allows connections only to itself and localhost.
- Exceptions. Model calls go to the providers you configure. And the agent execution tools include a browse tool that fetches whatever URL it is given. So the slogan that nothing touches the network unless you configured it is not one I can defend. The narrower claim is.
What it costs, because it costs something
Local-first is a trade, and a CIO should price it before signing.
- One machine. I found no sync service in the main process. The Ink and Switch essay lists working across devices as an ideal, and Team-X does not deliver it at this tag.
- Backups are yours. Backup is a one-click archive to a destination you choose. Nothing in the main process schedules it.
- No encryption at rest that I can show. A search of the database, backup, and vault code for sqlcipher, a key pragma, or the word encrypt finds nothing. Your protection is your OS account and disk encryption.
- Linux needs libsecret. The 3.2.0 changelog records that minimal installs crashed on first API-key access without it. The .deb now declares the dependency. The AppImage does not.
A vendor that holds your state can sync, back up, and encrypt it for you. It can also change the terms of a sharing feature whenever it chooses.
What to do with this
- Put one question in every AI vendor review: where does the primary copy of our data live, and what survives if the vendor is unreachable?
- Ask for the dependency manifest and the update path. A button is an answer. A timer is a different answer.
- Decide who owns backups before rollout, and write the owner down.
- Treat a local model on a cloud architecture as a cloud product in your risk register.
The full walk-through, with line-level links to the v3.2.1 source, is in the original post on the Team-X blog. Every claim in it is pinned to a tag you can read yourself.
-Rocky
#TeamX #LocalFirst #AIGovernance #EngineeringDreams #StrategiaX
Originally published on Team-X Blog.