Most work ends up in a grid, a doc, a real database you have to operate, or a spreadsheet that became the company. Thogits is a different shape: thogits (the things) and tags (the types you put on them), plus a local replica so pages the assistant builds feel like software, not a form over a slow API.
This is the data layer. Not a wiki. Not a SQL product you run yourself.
A thogit is a thing. A tag is a type.
A thogit is an entity in a space. It has a name, an optional description, an identity that does not change, and the tags you applied.
A tag is a schema you can put on a thogit. It names fields and their types: text, number, true/false, date, a link to another thogit, or a select. Apply Person and you get phone and role. Apply Client and you get billing terms. Apply both to the same thogit.
That last sentence is the product.
Priya is one record. She is a person, a client, and a crew lead. You do not copy her into three tables so three tools can see her. You tag her. Query “clients with open jobs” and she is there. Query “crew on site today” and she is there. Same identity.
Tags can extend other tags. Job can extend Work. Asking for Work still finds the jobs. Each tag keeps its own fields — there is no flattened pile of identically named columns fighting each other.
You add a tag when the work grows a new shape. You do not run a migration. You do not stand up a new spreadsheet. You do not duplicate the row.
What that is useful for
A job can carry a status, a crew, a site, and an amount — and also be the thing the invoice points at. The invoice is another thogit, tagged Invoice, with a reference field back to the job. Filter invoices where the job’s client is Oak Clinic. That is a real query, not a VLOOKUP you hope nobody broke.
A note can sit on the same job. A person can be on the job. The assistant files a follow-up and the page already showing “open work” updates, because it is looking at the same records.
This is why generated screens work. The page is not inventing a data model. It is drawing the thogits you already have.
Spreadsheets
A spreadsheet is a rectangle of cells. There is no identity. “Priya” in row 4 and “Priya Chen” in the invoices tab are two strings. Types are a rumour. Two people edit at once and you get the copy on someone’s laptop.
Spreadsheets are good at a one-off grid. They are a bad system of record. The moment you need “this job, this client, this invoice, this person — and they are the same facts everywhere,” you have left the product.
Thogits gives you identity, types, links, and queries. The grid, if you want one, is a page on top.
Notion
Notion can hold a database. It is a good one, for a wiki. Properties are typed. Views exist. You can relate rows.
The database still lives inside a document. The product is the editor. Views are a closed set: table, board, calendar, gallery. You assemble them. You are the layout engine. The AI writes prose. It does not run a local replica of your records so a generated screen can update a field without waiting on the wiki.
Thogits inverts that. The record is the product. Pages are software on the records. A thogit can wear more than one tag without becoming two Notion databases you have to keep in sync. Feature-by-feature: Thogits vs Notion.
Airtable
Airtable is a real table product. Linked records, interfaces, automations, an API. If you think in bases and you enjoy building the grid, it is good at being that.
A row still belongs to one table. “Priya the client” and “Priya the crew” are two rows or a messy link. Interfaces are a second product you configure. The assistant, such as it is, does not sit on a local copy of the base and paint a page that writes through the same kernel as the server.
Thogits is not trying to out-grid Airtable. It is trying to be the system you query and the system the generated page talks to, without you living in the grid. Fairer feature-by-feature on Thogits vs Airtable.
Postgres
Postgres is a serious database. Thogits stores the space on one. That is not the same as you operating Postgres.
Against Postgres you still owe: tables, migrations, an API, auth, a sync story, and a UI. An agent that “builds an app” on Postgres usually builds a prototype that hits a remote server on every click, or invents its own cache, or silently diverges from the schema.
Thogits is the data plane that cut that work down:
- Tags instead of
ALTER TABLE - Thogits instead of picking a primary key strategy
- Queries with boolean logic, field comparisons, and walking references — without writing SQL for each screen
- A local replica of the slice the page cares about, with the same validation rules as the server
You do not get a general-purpose SQL console. You get a typed space an agent can build on in an afternoon.
The local replica — why generated pages feel like apps
This is the other half of the model, and the reason agents can ship a board that does not feel like a demo.
A page does not have to load every record in the space. It subscribes to what it needs: this week’s jobs, one invoice, the tag catalog. Those thogits live in a local replica next to the page.
Writes go to that replica first. The click is visible before the network round-trip finishes. Subscribers on the same page update in the same turn — a job leaving “Quoted” appears in “On site” without a spinner on the whole board.
The replica uses the same domain rules as the server. A bad value that would fail in the API fails locally too. If the server later rejects a write (someone else deleted the record, the schema moved), the replica does not keep the lie. It rolls back and the page hears about it.
Two people editing different fields on the same thogit both keep their changes. Two people editing the same field: later write wins. That is the contract. It is why a generated CRM does not need you to invent conflict UI on day one.
Other connected clients see accepted changes without reloading the space. If a client lags and reconnects, its subscriptions catch up. Temporary divergence is allowed. A permanent split of the data you subscribed to is not.
Call this local-first in the engineering sense: the page talks to a local API, then syncs. Do not read it as “the product is an offline app.” Web and iPhone stay in sync when they can reach the space. We do not sell a plane-mode workspace. We sell screens that do not wait on the wire for every keystroke.
That is what “agents build snappy, reliable, consistent apps quickly” actually means. The assistant is not generating a pretty layout that then needs an ORM. It is generating a page against an engine that already knows how to read, write, filter, and merge.
What you do with it
Ask for a board of open jobs. The page subscribes to jobs that are not done. Move a card. The thogit’s tag field changes locally, the column updates, the server confirms.
Ask for invoices overdue more than 14 days, linked to the client. That is a filter plus a reference walk. Not a new microservice.
Tag a person as a vendor later, without cloning them. The directory page and the payables page both see the same record.
Let the assistant call you about what is still open. It is reading the same thogits the board is subscribed to.
MCP can see and edit those records from an agent you already run. It does not build the pages. The local replica is for the screens inside Thogits.
Start there
Name the things you track. Put tags on them. Ask for a page. The database is already the product — data, pages, agents. How it sits next to other tools: Compare. The short product picture: What Thogits is.