Apps & Interfaces · 07.03
App Staffing: Born With a Cast
An App is created with an auto-assembled cast of specialist agents — reused from the workspace talent pool where a fit exists, materialized where it doesn't.
Four steps, run once, idempotent forever after
Staffing an App follows one deterministic sequence: derive a cast from the App's own name and description (classified into one of five archetypes — sales, support, analytics, research, automation), then for each role in that cast either reuse a fitting specialist that already exists in the workspace's talent pool or materialize a brand-new one born with real competence — baked-in operating instructions and capability tags, not an empty shell — then pin any default abilities for the role, and finally seat every agent in app_members with exactly one operator (who becomes the App's owner) and the rest as workers.
The whole sequence is idempotent — an App that already has members is left completely untouched on a repeat call — and deliberately non-throwing: a staffing failure never blocks the App's own creation, it just leaves that App running degraded (unstaffed) rather than broken.
Continue
Filter/sort/limit/cursor queries with optional strict schemas, live DATA_CHANGED updates, and terminal run outcomes feeding back into records.
Live co-presence over the realtime bus, ephemeral by design, so two operators can tell they're looking at the same App at once.