Docs

Agentic Apps · 04.02

The Anatomy of an Agentic App: From Blank Prompt to Staffed, Running Product

One end-to-end walk through what actually exists in the database and who touches it — from build_workflow to a staffed, data-backed, self-orchestrating product.

AnatomyDeep dive

Five tables, one product

An Agentic App is not a metaphor sitting on top of a workflow — it's a specific, small set of real tables that get populated in a specific order the moment a workflow becomes an App:

TablePopulated byHolds
appsThe auto-wrap, at build timeSlug, name, version, icon, owner, status, policy.
app_membersAppStaffingService, right afterThe staffed cast — exactly one operator, the rest workers, each a real agent with baked-in competence.
app_collections / app_recordsdata.define_collection, as the App's workflows declare their shapeTyped data, optionally strict-schema'd.
app_surfacesThe surface generator, from a prompt plus the collection schemasA typed ViewNode tree per named page.
app_contactsWherever a run touches a real personThe bridge from App data to the Subject/Connection primitives — and the source of the outcomes the App's own Brain learns from.

Staffing happens once, and never blocks the App from existing

The moment an App is created, staffing runs before anything else touches it: derive a cast from the App's own name and description, classified into one of five archetypes, then for each seat either reuse an existing workspace specialist or materialize a new one with real instructions and capability tags — never an empty placeholder agent. This is idempotent (call it again on an already-staffed App and nothing changes) and deliberately non-throwing: if staffing genuinely fails, the App still exists, just degraded and unstaffed, rather than the whole creation aborting because one non-critical step hiccupped.

Continue