Reference

Database schema

The platform's Postgres database holds 113 tables across the public schema. Every row that belongs to a workspace carries a user_id; row-level security enforces that scope at the database edge. This page indexes the tables by purpose so a reader can locate the right one without reading raw schema files.

Updated today

Overview

At a glance

Engine: Postgres 15 (Supabase managed)
Public tables: 113
Functions: 141 (SQL plus PL/pgSQL)
Triggers: 25
RLS policies: 197 across 110 tables
Vector tables: file_embeddings, agent_memories
Storage buckets: 4 (brain-files, canvas-exports, chat-attachments, content-media)

Every workspace-scoped table follows the same shape: id uuid primary key, user_id uuid referencing auth.users, then domain columns, then created_at and updated_at timestamps. The user_id column is the RLS pivot: every read and write checks auth.uid() = user_id before the row is visible.

Extensions

Five extensions are enabled, all standard Supabase fare.

Extension	Version	Used for
`vector`	0.8.0	768-dim embeddings on brain files and agent memories; HNSW cosine index
`pgcrypto`	1.3	Encrypted columns for OAuth tokens and integration secrets
`pg_stat_statements`	1.11	Query profiling for slow-path investigation
`uuid-ossp`	1.1	uuid_generate_v4 defaults
`supabase_vault`	0.3.1	Encrypted secrets storage for a small set of sensitive values

Chat and conversations

The tables behind the chat loop. One conversation, many messages, one chat_runs row per assistant turn.

Table	Purpose	Notable columns
`conversations`	One row per chat thread	skill_type, department, model, project_id, sandbox_id, active_mission_id
`messages`	Every user, assistant, and tool message	role, content, channel, tool_events, metadata
`chat_runs`	One row per assistant turn lifecycle	status, model, started_at, completed_at, error
`chat_events`	SSE event log for replay and audit	event_type, payload, sequence
`pause_points`	Tool-approval pause records	tool_name, args, decision, resumed_at
`shared_links`	Public share tokens for conversations	share_token, expires_at, password_hash, view_count
`shared_link_views`	Per-view audit for shared links	viewer_ip_hash, viewed_at
`synced_blocks`	Live blocks rendered into shared and canvas views	block_id, content, revision

Memory and files

Three storage surfaces: agent_memories for short structured facts, brain_files plus file_embeddings for uploaded documents, and conversation summaries written back into messages.

Table	Purpose	Notable columns
`agent_memories`	Distilled facts the agent should remember across turns	agent, text, embedding (vector), tags, metadata
`brain_files`	Uploaded source files (one row per file)	file_name, file_type, storage_path, chunks_count, content_hash, status
`file_embeddings`	Chunked, embedded chunks of brain files	chunk_index, content, embedding (vector), content_tsv, token_count
`brain_artifacts`	Generated artifacts attached to brain files	artifact_type, payload
`notes`	Free-form sticky notes the agent can read and write	title, body, tags
`project_memories`	Project-scoped memory entries	project_id, text, embedding
`project_brain_files`	Link table from projects to brain files	project_id, brain_file_id

Note

file_embeddings has an HNSW cosine index (fe_embedding_hnsw_idx) with m=16 and ef_construction=64. Queries cap at k=8 and combine vector similarity with full-text rank over content_tsv.

Skills, tasks, missions

Run tracking for skill executions, agentic tasks, scheduled actions, and long-running missions.

Table	Purpose
`agents`	Static persona definitions (Cortex, Specter, Striker, Pulse, Sentinel, Amplify, Counsel)
`agent_tasks`	One row per agent-spawned background task
`tasks`	Generic task queue (user-visible)
`home_tasks`	Suggested tasks rendered on the home dashboard
`scheduled_actions`	Cron-style declarative schedules
`scheduled_tasks`	Concrete due-dated work items
`missions`	Long-running multi-step plans (mission control)
`cron_jobs`	Job definitions polled by the cron worker
`executed_rules`	Audit of automation_rules that fired
`automation_rules`	If-this-then-that style rules per workspace

CRM and outreach

Leads, deals, campaigns, sequences, and the workflow engine that drives them.

Table	Purpose
`leads`	The lead record (28 columns; name, email, company, enrichment_data, score, status)
`deals`	Pipeline opportunities with stage and value
`campaigns`	Outreach campaign definitions
`outreach_campaigns`	Multi-channel outreach orchestration
`outreach_pipeline_runs`	Per-run execution of an outreach pipeline
`outreach_pipeline_leads`	Lead-to-pipeline join with per-step status
`crm_sequences`	Reusable message sequences
`crm_sequence_enrollments`	Lead enrolment in a sequence
`crm_activities`	Activity log per lead and per deal
`crm_segments`	Saved lead segments
`crm_tasks`	User tasks tied to leads or deals
`crm_workflows`	Visual workflow definitions
`crm_workflow_runs`	Workflow execution rows

Content, pages, media

Generated content (carousels, posts, articles) and the page builder.

Table	Purpose
`content`	Generic content rows (carousels, posts, videos)
`content_sets`	Grouped content drops (theme, batch)
`content_research`	Research notes attached to a content set
`pages`	Page builder rows
`page_revisions`	Per-edit revision history for pages
`page_templates`	Saved page templates
`page_backlinks`	Internal links between pages
`media_library`	Workspace media assets
`media_items`	Individual media files (image, video, audio)
`social_posts`	Scheduled and published social posts
`post_analytics`	Engagement metrics per post

Email infrastructure

Outbound email through a transactional provider, with per-message tracking and suppression.

Table	Purpose
`email_sends`	One row per outbound message with delivery status
`email_suppressions`	Bounce, complaint, and manual suppression list
`brevo_domains`	Verified sending domains
`brevo_senders`	Verified sender identities (from-address rows)
`sender_groups`	Groups of senders rotated for warmup
`sender_group_items`	Group-to-sender link rows

Billing and usage

Subscription, credit ledger, usage counters, and Stripe event audit.

Table	Purpose
`profiles`	User profile and subscription state (plan, stripe_customer_id, credit_balance, business profile)
`credit_grants`	Credit-package purchases and grants
`credit_transactions`	Append-only ledger of credit debits and credits
`billing_events`	Audit of Stripe webhook events
`invoices`	Cached Stripe invoices for the dashboard
`plan_limits`	Quota definitions per plan tier
`usage_tracking`	Daily counters (messages, leads, content, api_calls)

Integrations and accounts

OAuth and API-key connections to third-party services, plus the cookie pools that some scrapers borrow against.

Table	Purpose
`integrations`	Per-user provider connections with encrypted credentials
`user_integrations`	OAuth flow state and tokens
`google_tokens`	Google OAuth tokens (Gmail, Calendar, Drive)
`google_burner_pool`	Pool of burner Google identities for read-only public scraping
`google_cookie_pool`	Cookie pool with health and last-used timestamps
`social_accounts`	Connected social network identities
`channel_connections`	Slack, Discord, Telegram channel-level installs
`telegram_connections`	Telegram bot installations per workspace

Warning

Tokens in integrations.api_key_encrypted are encrypted with the platform's ENCRYPTION_SECRET before insertion. They never leave the database in plain form.

Scraping signals

The intermediate tables scraper workers write into before downstream skills aggregate them.

Table	Purpose
`job_signals`	One row per scraped job posting (jd_url is the dedup key)
`account_signals`	Buying signals attached to a company
`account_analytics`	Aggregated account-level metrics
`profile_changes`	Detected profile diff events from tracked LinkedIn handles
`job_events`	Background-job event log shared by skills and scrapers
`jobs`	Generic background job rows
`jobs_notification_settings`	Per-user notification preferences for job runs

Fundraising and agreements

Tables behind the fundraising flow: investor pipelines, commitments, and signed agreements with audit.

Table	Purpose
`fundraising_jobs`	Long-running fundraising worker tasks
`investor_commitments`	Soft and hard commits from investor outreach
`rfp_requests`	Inbound RFP requests captured for routing
`agreements`	Generated agreement documents
`agreement_recipients`	Signer identities per agreement
`agreement_fields`	Fillable fields and their bound values
`agreement_signatures`	Captured signatures with timestamp and IP hash
`agreement_audit_logs`	Tamper-evident audit trail per agreement

Ops and automation

The internal ops console writes a small set of tables for proposals, missions, and policy.

Table	Purpose
`ops_missions`	Internal ops missions
`ops_steps`	Step rows within an ops mission
`ops_proposals`	Action proposals that need approval
`ops_policy`	Guardrail policy rules
`ops_events`	Append-only event log for ops
`activity_feed`	Unified user-facing activity feed across all sources
`events`	Internal product-event stream (used for analytics dispatch)

Sandbox and workspace

The per-user sandbox metadata and the workspace project model.

Table	Purpose
`projects`	User-defined workspace projects (groups conversations)
`project_counts`	Materialised counts per project
`sandbox_artifacts`	Artefacts produced inside the E2B sandbox
`sandbox_questions`	Questions the sandbox surfaced to the user mid-run
`recall_bots`	Meeting-recording bot rows (one per active recording)
`blueprints`	Saved multi-step workflow blueprints
`deployments`	User-deployed apps from the deployment flow
`deployment_runs`	Per-run execution rows
`deployment_outputs`	Outputs captured from a deployment run
`deployment_activity`	Activity rows for the deployment surface
`deployment_usage_events`	Usage events emitted by deployed apps

Storage buckets

Four Supabase Storage buckets handle binary content.

Bucket	Public	Holds
`brain-files`	Yes	Uploaded brain-file binaries; URL stored on brain_files.storage_path
`canvas-exports`	No	Canvas PNG and PDF exports served via signed URL
`chat-attachments`	Yes (25 MB limit)	Images and small files attached to chat messages
`content-media`	Yes	Carousel slide PNGs and other generated content media

Row-level security

RLS is on for almost every public table. The pattern is uniform.

rls-policy-template.sqlsql

1-- The template used on every user-scoped table

2alter table public.<table> enable row level security;

4create policy "<table>_select_own"

5 on public.<table> for select

6 using (auth.uid() = user_id);

8create policy "<table>_modify_own"

9 on public.<table> for all

10 using (auth.uid() = user_id)

11 with check (auth.uid() = user_id);

13-- The service role bypasses RLS for backend writes (webhooks, workers)

Tip

110 of 113 public tables have RLS enabled. The three without RLS are admin-only tables (plan_limits, cron_jobs, agents) that are read-only at the application boundary and never read by anonymous or user-scoped clients.

Vector indices

Two tables hold embeddings; only one needs a vector index.

file_embeddings indexsql

1create index fe_embedding_hnsw_idx

2 on public.file_embeddings

3 using hnsw (embedding vector_cosine_ops)

4 with (m = 16, ef_construction = 64);

agent_memories stores embeddings but does not have an HNSW index. Memory rows are few per user (typically under 200) so a sequential scan with a cosine distance computation runs in well under 10 ms. Brain files, by contrast, are unbounded and need the index to keep retrieval latency below the chat-loop budget.