Skip to content
~/canon

01 · System of record

A system of record for the agentic era.

Canonify is the backend your agents build on, the native apps your team operates through, and the standalone apps you ship when native is not enough. One record across all three, fully audited.

$ curl -fsSL https://canonify.app/install.sh | sh

macOS, Linux above. Windows: irm https://canonify.app/install.ps1 | iex

terminal
$ lore schema propose "CREATE TABLE customers (...)" --reason "Customer directory"
✓ proposal sch_01HK2N… queued · pending approval
$ lore approve sch_01HK2N… --approved-by-human
✓ schema applied · table customers ready
$ lore views create --name "All customers" --for customers
✓ view view_01HK2P… ready
Agent in the terminal
The Customers table rendered as a native Canonify app, showing rows the agent inserted with the new tier column.
The same table in the human canvas

02 · Why now

Old SaaS cannot kludge its way to agent-native.

Every team running agents in production is hitting the same wall. The agent reads context from a markdown file, writes results to a JSON blob, posts a status to Slack, and updates a row in a CRM that wasn't designed to be edited by a non-human. None of that data is governed. None of it is queryable. None of it is the same shape twice.

The honest answer is a system of record. Not a generated frontend on top of a Notion database. Not a wrapper around HubSpot's API. A real backend with schema agents can propose, queries agents can run, and an audit trail humans can read. Then native apps on top of that record so you can read, write, and approve. Standalone apps for the cases that need custom code.

"The system of record is the missing element in the agentic world."

Canonify is that record. Old-guard SaaS will spend the next two years bolting agent layers onto data models built for menus and forms. Canonify starts the other way around: data first, agents first, governance first, UI generated.

03 · Build

Agents build it.

Schema in SQL. Native apps in a JSON spec the platform validates before it touches your data. Standalone apps in code. All proposed in a CLI session, all governed by approval, all rendered the moment they land.

terminal · build
$ lore schema propose "CREATE TABLE tasks ( id TEXT PRIMARY KEY, title TEXT NOT NULL, status TEXT DEFAULT 'open', assignee_id TEXT REFERENCES _users(id), created_at TEXT NOT NULL )" --reason "Task tracking"
✓ proposal sch_01HK2T… queued · pending approval
awaiting: peter@engelbrecht.dk
$ lore approve sch_01HK2T… --approved-by-human
✓ schema applied · table tasks ready · 5 columns indexed
$ lore views create --name "All tasks" --for tasks
✓ view view_01HK2V… ready · type: list · columns auto-detected
Three commands: propose, approve, ship the view.
The All tasks native app rendered immediately after the CLI commands ran, with real rows from the new tasks table.
Native apps render from a validated spec. Standalone apps ship when the spec is not enough.

04 · Use

Use it.

Agents query and update through the CLI. Your team works the same data in whatever shape fits: list, board, dashboard. Edit the spec, not the code, to change shape.

terminal · use
$ lore list tasks --where status=open --order created_at:desc --limit 3
tsk_01HK… Review quarterly reports peter@…
tsk_01HK… Send invoices for September peter@…
tsk_01HK… Onboard Acme Corp marie@…
24 records · 3 shown
$ lore update tasks tsk_01HK… status=done
✓ updated · status: open → done · audit logged
Agent in the terminal: query, update, mutate.
The same tasks reshaped as a kanban board, grouped by status, defined by a JSON spec rather than code.
Same tasks as the build view, reshaped via spec into a kanban. No new code.

05 · Govern

Humans govern it.

Schema changes, access policies, anything that touches structure stops at a human checkpoint. Agents propose, you approve, the change lands.

terminal · propose
$ lore schema propose "ALTER TABLE tasks ADD COLUMN priority TEXT DEFAULT 'normal' " --reason "Sort tasks by urgency"
✓ proposal sch_01HK2X… queued · pending approval
diff:
tasks
+ priority TEXT DEFAULT 'normal'
awaiting: peter@engelbrecht.dk
review at: /pending/sch_01HK2X…
The agent stops at the gate. Nothing lands without approval.
The human approvals queue showing the pending schema proposal: diff, agent attribution, approve or reject.
Human in the loop, with diff and context.

06 · Today

What renders from a spec.

The same data takes whatever shape your team needs. A validated JSON spec per view, no UI code to write. Four real views below, all rendering against the same CRM data.

Tasks rendered as a sortable list view, columns auto-detected from the schema.

List

{ "type": "list", "columns": [...] }

Sortable columns, filters, inline edits.

The same tasks reshaped as a kanban board, grouped by status.

Board

{ "type": "board", "groupBy": "status" }

Kanban columns from any enum field. Drag to update.

A dashboard with KPI tiles and bar / line charts driven by widget specs.

Dashboard

{ "type": "dashboard", "widgets": [kpi, line_chart, bar_chart] }

KPI tiles, line and bar charts. No charting library to choose.

A chronological activity feed showing recent events from agents and humans on shared tables.

Activity feed

{ "type": "activity_feed" }

Streams from the system event log. Agents and humans, attributed.

When a spec cannot express what you need, ship a standalone HTML app on its own domain via lore app publish-standalone. The rest of the surface is what you'd expect: schema propose, views create, list / get / create / update / delete for structured CRUD, query / mutate for raw SQL, search, policy, audit, import, org export. Plus an MCP server for Claude Desktop, Codex, or any MCP-aware agent.

07 · Try it

Install the CLI. Get on the list.

Canonify is in private beta. The CLI is open. Drop your email and we will get you onboarded.

$ curl -fsSL https://canonify.app/install.sh | sh