Views
A view is a named query plus a rendering configuration over the same records; the view types a pod implements.
Not yet re-verified
The Idea in One Line
Same data. Any lens. No code changes.
A view is not a copy of your data — it is a named query + rendering configuration. Change the view type and the same entities become a kanban board, a timeline, a graph, a masonry feed. The data never moves. Only the lens changes.
This is Config-over-Code in action: every view is a JSON configuration. AI can generate a complete dashboard from a plain-language description. No developer required.
View types
The view types a pod implements are defined in packages/types/src/renderables/views.ts of the backend repository.
19 are implemented:
| Category | View types |
|---|---|
| Structured | sheet, table, list, grid, gallery, kanban, matrix, masonry, calendar, gantt, timeline, graph, flow, map, zoom_map |
| Canvas | whiteboard |
| Special | pipeline, branch_tree, bento |
Not every implemented type can be created as a new view: table (superseded by sheet), branch_tree (only
meaningful inside a conversation), zoom_map (retired as a new view) and pipeline (created by its own flows) remain
renderable for existing views but are not offered when you create one. mindmap is defined but not implemented.
New view types are adapters in the view renderer; the data layer does not change.
AI-Generated Views
Because every view is a configuration, AI can generate views from natural language:
- "Create a pipeline view of my deals grouped by stage" → kanban config,
groupBy: dealStage - "Build a team dashboard with open tasks, recent activity, and deal velocity" → bento config with 3 widget blocks
- "Show me a graph of how my contacts relate to each other" → graph view config
The AI writes the config. The view renderer runs it. No code touched.