Your app is the memory. The model is not.

An assistant that “remembers you” is only as good as where it writes that down. If the fact lives in the model’s context, it dies with the session, leaks into the wrong prompt, or cannot be deleted when someone asks you to forget it.

For a shopper, that might be a shoe size. For a business it is the roster, the stocktake, the open quotes. Those are not memories. They are records. They belong in a database you own.

Store it where you already work

Every app on Croft gets a real SQLite database on your private server. The assistant can create tables, write rows, and query them. The roster is in the roster app, not in last Tuesday’s Claude chat.

That is also how you share state across apps: shared data on the same croft, with access you grant on purpose. The quotes app can read customers without a second copy of the truth living in a prompt.

The model should not be the system of record

Three practical rules, the same ones you would use for any client:

• Write durable facts into the app. A new hire, a received delivery, a signed quote. If you would be angry to lose it, it is not chat history.
• Read from the app on the next turn. Do not ask the person to re-type yesterday. Open the list.
• Let people see, fix, and delete it. A database you can export is a database you can honour a deletion request on. A transcript is not.

Connectors fit the same split. Stripe, a CRM, email: the platform holds the key, the app reads and writes through it, the model never becomes a second copy of billing.

What this gives you

You can change assistants. Build in Cursor this month, Claude next month. The app is still there, the rows are still there, the login is still yours. Your data is yours.

The model is how you change the tool. The app is how the tool remembers.

How a Croft app gets a database →  ·  Get your croft →

More from the blog