Platform
Onnie is built from a set of modules that each handle a distinct kind of work. This page maps out what each module does and how they fit together so you know where to look when you want to get something done.
The modules at a glance
| Module | What it does | Overview |
|---|---|---|
| Workspace | The top-level container. Holds your data, your team, your billing, and your AI context. | Workspace |
| Teams and users | Members, roles, and teams. Controls who can read and write what inside a workspace. | Teams and users |
| AI Agents | The three agent surfaces — Onnie AI (your personal assistant), Onniebots (scoped workers), and Superagent (the orchestrator). | AI Agents |
| Routines | Automated jobs: Agent Routines (AI-driven), Functions (sandboxed code), and Chains (branching sequences). Triggered by schedule or event. | Routines |
| Tasks | Persistent work items tracked through a state machine. Assigned to people or bots. | Tasks |
| Projects | Groups related Tasks, Pages, tables, and Routines under one initiative. Supports private access control. | Projects |
| Pages | Long-form documents with rich content, inline entity references, and optional public sharing. | Pages |
| Tables | Structured datasets with typed columns, views, forms, and AI-derived fields. | Tables |
| Skills | Reusable instruction documents you give to agents. Encode SOPs, domain rules, and sub-workflows once, reference everywhere. | Skills |
| Custom fields | Typed column definitions that extend Tables — including formula and AI-generated columns. | Custom fields |
| API | REST API for reading and writing workspace data from external systems. | API |
| MCP | Model Context Protocol server — call Onnie tools from Claude Desktop, Cursor, and other MCP clients. | MCP |
How modules compose
Onnie modules are designed to be used together. Here are three worked scenarios that show how they connect.
Scenario 1 — Weekly project digest. A workspace editor creates an Agent Routine (Routines module) that runs every Monday via pg_cron. The Routine's prompt tells Onnie AI to read all open Tasks in a given Project, summarize them into a Page inside that project, and post a link back as a chat message. Modules involved: Routines, Tasks, Projects, Pages, AI Agents.
Scenario 2 — AI-enriched CRM.
The team maintains a contacts Table with columns for company name, last-contact date, and a custom AI column whose instructions say "Summarize the latest news about {{Company Name}} in two sentences." Whenever a record's company name changes, the engine regenerates the AI field automatically. An Onniebot configured with a Skill that describes the team's follow-up SOP can then read the table and create Tasks for the sales rep. Modules involved: Tables, Custom fields, AI Agents, Skills, Tasks.
Scenario 3 — Private project with gated access.
A team marks a Project as private and adds only the relevant engineers to its project_members list. They create Pages for specs, Tables for bug tracking, and Tasks for individual work items — all scoped to the project. An Onniebot scoped to that project's onnie_md context handles triage questions. Other workspace members see none of this. Modules involved: Projects, Teams and users, Pages, Tables, Tasks, AI Agents.
Where to start
- Workspace — understand the container everything lives in.
- Teams and users — invite your team and set roles.
- AI Agents — learn the three agent surfaces and what each one is for.
- Tasks — start tracking work.
- Routines — automate repetitive jobs.
- Projects — group work by initiative.
- Tables — add structured data.
- Skills — encode knowledge for your agents.
- API — connect external systems.
How data flows
Understanding where data lives helps you build the right thing in the right place.
CRUD and queries go straight to Supabase. When your code reads or writes projects, tables, tasks, pages, or records, it calls Supabase directly. The public API also routes through Supabase via service-role adapters. There is no middle layer for ordinary data access.
The onnie-engine handles AI side effects only. When you send a chat message, trigger an Agent Routine, or generate an AI field, the request goes to the engine. The engine runs the model, calls tools, and writes results back to Supabase (tasks, pages, records, memory) using the service role. The engine is not a general-purpose data API — it is the AI runtime.
Scheduled jobs run in pg_cron. Every timed trigger — Routine schedules, AI field re-runs, billing credit refills — starts as a pg_cron job in the Supabase database. There is no separate scheduler service.