What must stay local for an AI agent to be genuinely local-first?

by

Disclosure: I’m building ChaseOS Studio, a local-first workspace where agents operate under explicit approval and evidence boundaries.

I do not think “local model” and “local-first product” are the same thing. An app can call a cloud model and still keep the operator in control. It can also run a model locally while trapping durable state in an opaque store that is difficult to inspect, export or recover.

The boundary I’m testing keeps five control surfaces on the operator’s machine:

1. Durable project truth in inspectable, exportable representations

2. Memory plus provenance, with indexes treated as rebuildable

3. Permission and approval state independent of any model provider

4. Execution receipts for task packets, tools, failures and writeback

5. Recovery through local version history, backups and reversible writes

Providers can still be explicit adapters. The question is whether network loss removes access to primary project state or transfers authority over that state to the provider.

The current ChaseOS boundary is intentionally specific: the signed Windows Studio release and Core local-first foundations are implemented; encrypted sync, hosted runtimes, agent fleets and GPU compute remain planned or separately gated.

I wrote the longer architecture note here:

For products you use today, what has to remain local before you would call the system local-first: files, memory, permissions, logs, recovery—or all five?

1 view

Add a comment

Replies

Be the first to comment