How Actionist can compose mature repositories, connectors, workflows, UI components, and industry logic into one client system without turning the database into shared mutable chaos.
This is reconstructed from the agents' full conversation JSONLs, not merely their closing callbacks.
chef, sandboxd, Astryx, and Grist supplied the strongest subsystem precedents.sequential-gallery demonstrates Bayesian sequential gallery selection.choix supplies Bradley–Terry/Luce choice modelling.There is no credible “universal SaaS repository framework.” There is, however, a well-understood combination of frameworks that solves each fundamental constraint.
Domain-driven design says each business capability owns its data, language, invariants, and state transitions.
A small stable kernel loads independently versioned plugins. NocoBase and Cal.com demonstrate this shape.
Hexagonal architecture keeps imported code behind declared command, event, query, UI, file, and secret ports.
Typed commands perform writes. Stable read models serve cross-block reads. Full event sourcing is unnecessary.
A state change and its emitted event commit in one transaction, preventing silent divergence between blocks.
Agents receive narrowly scoped abilities rather than ambient SQL, secret, or tenant authority.
Twenty, NocoBase, Directus, and Teable show how objects, fields, relations, views, and actions can become structured data.
Every block declares versions, migrations, dependencies, rollback, host compatibility, and evidence receipts.
Models propose composition; a non-model solver decides whether the graph is legal, secure, compatible, and recoverable.
The framework produced by those principles is a TypeScript/Postgres runtime where AI composes capabilities through contracts rather than improvising across source code and tables.
ACTIONIST COMPOSER
client intent → capability graph → app plan
│
deterministic validation
│
┌─────────────────────┼─────────────────────┐
│ │ │
CRM Block Finance Block Support Block
│ │ │
commands/events commands/events commands/events
│ │ │
└────────────── Actionist Kernel ──────────┘
│
tenancy · authority · jobs · receipts
events · migrations · files · secrets
│
PostgreSQL
Shared infrastructure does not mean shared mutable internals.
core.tenants core.users core.actors core.memberships core.roles core.capabilities core.block_definitions core.block_installations core.block_versions core.migrations core.commands core.events core.jobs core.receipts core.audit_log core.idempotency_keys core.files core.secret_references core.external_accounts
crm.contacts crm.companies crm.deals finance.invoices finance.payments finance.ledger_entries support.tickets support.messages support.sla_policies
Every tenant-owned row carries tenant_id. RLS comes from kernel-owned policy templates and cannot be widened by the composing agent.
| Port | Purpose | Example |
|---|---|---|
| Command | Request a controlled state change | finance.issue_invoice |
| Event | Publish a fact that already happened | crm.deal.won |
| Query | Expose a stable read model | crm.customer_summary |
| UI | Contribute pages, forms, cards, and panels | support.ticket_panel |
| Resource | Control files, secrets, and external accounts | connector.gmail.account |
Cross-block direct writes are prohibited. Cross-block reads use declared projections or views. A CRM block asks Finance to issue an invoice; it never inserts directly into finance.invoices.
Adapt a bounded capability into the shared runtime. It owns a namespaced Postgres schema and Actionist ports.
Best for contacts, invoices, approvals, extraction, SLA rules, and other clean capabilities.
The heavyweight product retains its runtime and database. An anti-corruption adapter exposes Actionist commands, events, and projections.
Best for ERPNext-, Chatwoot-, or other product-sized systems that should not be dissolved into shared tables.
Reuse only a surface, token pack, interaction pattern, schema idea, or generated specification. It owns no business data.
Best for 21st.dev UI, design packs, login forms, and study-only repositories.
The full packaging vocabulary should preserve: native_block, wrapped_service, generated_from_pattern, ui_only, and reference_only.
The agent composes manifests and capabilities—not arbitrary source code.
{
"id": "actionist.crm.contacts",
"version": "1.0.0",
"packaging_mode": "native_block",
"database": {
"schema": "crm",
"migrations": []
},
"commands": [],
"events": [],
"queries": [],
"ui_surfaces": [],
"required_capabilities": [],
"provided_capabilities": [],
"dependencies": [],
"permissions": [],
"tenant_policy": "strict_tenant_v1",
"rights": {},
"evaluation": {},
"rollback": {}
}
Before a repository becomes a block it needs pinned identity, packaging mode, typed ports, tenant policy, rights/provenance state, migrations, negative tests, receipts, rollback, and admission.
Example request: “Leads arrive, get enriched, assigned, followed up, and invoiced after closing.”
The hard problem is not generating code. It is allowing an agent to build over client data while making it structurally incapable of widening access.
Agent MAY: invoke admitted commands configure allowed fields and views request constrained migrations compose declared UI surfaces Agent MAY NOT: execute arbitrary production SQL author or weaken RLS grant itself capabilities read another tenant expose a new query without review directly access raw secrets
Schema changes use a constrained migration language. Tenant policies come from kernel-owned templates. A cross_tenant_leakage result forces NO_SHIP, regardless of every other score.
Agree the Block Contract: data ownership, commands, events, read models, authority, tenancy, migrations, rollback, packaging mode, rights, and admission evidence. Once that protocol is stable, the database host, ORM, UI framework, and imported repositories remain replaceable.