Words (stream = the app's chat, the Library, the Concierge), the laws, old field names
Contents
- Words (one meaning each)
- How a stream runs
- The laws, and what each means for a config file
- Old names you will see in files
Words
| Word | Means | In files |
|---|---|---|
| Streamliner | A white-label iPhone, iPad and Mac app: business processes as chats. | — |
| Account | An organization (a company; members sign in, config is published by the owner) or a personal account (one person's own streamlines on their device). | tenant.json, mode |
| Streamline | A department's desk: one preset agent with its persona, tools, look and rules. Register, Approvals, Receiving. | an agent kind: agents/<kind>.json + private/agents/<kind>.json |
| Stream | One conversation in a streamline = one job (one sale, one PO, one offer). **The app calls it a chat** (New chat, Chats, Archive Chat); say chat to the people who use it. | a chat: chat.set, chatTitle, newChatLabel |
| Connection | One system a person signs in to, as themselves (OAuth, password, API key, none). | connections[], mcp[].connection |
| MCP server | The organization's own API, exposed as Model Context Protocol tools. The agent calls it as the signed-in person. | mcp[] |
| Model relay | Streamliner's back end that forwards an organization's model calls: holds the provider key (by credentialRef), the private instructions, the tool allowlist, membership, network and budget checks. | private/ files |
| Template | A small JSON tree of native views bound to a tool's result. Display only. | templates/<id>.json |
| Sealed form / view | A native form whose values go device → organization endpoint, never to the model; a view that shows sensitive data without the model seeing it. | forms/<id>.json |
| Owner / admin / member | Access levels on a membership (who may manage the account). Separate from job roles (who may open which streamline). | invites, directory access |
| Server key | An Ed25519 key pair the account holds for automation (publishing, directory sync). Never an employee's sign-in. | private/tenant.json serverKeys (public half) |
| Library | The app's screen where owners, admins and personal users browse and edit streamlines, briefs, templates and forms in one schema-driven editor. Personal saves apply at once; an organization's edits are staged on the device and published from the app by an owner's or admin's device an owner approved (write-api.md Publishing from the app), or through the write API. | — |
| Concierge | A built-in streamline in On this device (personal) that sets things up by conversation, every save behind a diff card. Organization setup is this skill's job. | — |
| Publisher key | The Ed25519 key that signs the manifest. Devices pin it at enrollment; the back end never holds it. | enrolment.json keys |
How a stream runs
- The person opens a stream in a streamline and types or speaks (or taps a starter or a quick phrase, scans a code, attaches a file). Speech becomes text on the device; a scan reaches the model as a tagged
<scan>value. - The agent loop runs on the device. Model calls go to the model relay (organizations) or straight to the provider with the person's own key (personal accounts).
- Tool calls go device → the organization's MCP server with the person's own credential for that connection.
- Results come back as
content(what the model reads),structuredContent(what a template draws) and optional directives in_meta["com.manolab.streamline/ui"](draw this card, refresh the overview, remember this id, end the job). - A confirm-gated tool waits for the person's tap on a confirmation card before it is sent.
- A completing tool ends the job with a banner; the next stream is a new job.
The laws, and what each means for config
- The enterprise configures, the employee converses. Config decides persona, tools and look; an employee never edits an organization's streamline. (Owners and admins may stage edits in the app's Library; they reach members only through a signed publish.)
- Every stream is one job. Design each streamline around one repeatable job with an end (a completing tool). Refuse "a general assistant for everything": that is a different product.
- The API is the security boundary and the rulebook. Price floors, approval limits, who may see what: the organization's API enforces them for every call, as the signed-in person. Instructions are guidance, never a rule anyone relies on. The app's gates are UX; the API is the lock.
- Secrets never touch the model. No SSN, date of birth, license number, card number, password or API key in a prompt, an instruction, a tool argument, a transcript, a log or a test fixture. Sensitive input goes through a sealed form; card numbers through the processor's hosted page or the store's terminal. Provider keys are named by
credentialRef, never written into config. - Confirm before the irreversible. Anything that moves money, completes a job or can't be undone is confirm-gated, with a read-only preview of the real state.
- Data, never pixels. Servers send JSON; templates draw it natively. No HTML, CSS or scripts in config.
- Nothing client-specific is compiled in. Everything an account needs is in its config folder.
- Fast feels honest. Small, determined actions (pick a search result, scan a tag) can be
direct: a button calls the tool with no model round trip. - The cheapest model that can do the job. Start desks on the smallest model; move up only on evidence.
- The agent says what it did. Success is drawn only from tool results, never from the model's prose.
- A form when it is the honest tool. Ask in the stream for ordinary data; use a form for secrets.
Old names you will see in files
The prose says streamline / stream / account; the file format keeps its first names until a coordinated rename: kinds[] and agents/<kind>.json (streamlines), chat.* (stream state), tenant.json and t/<tenant>/ (account), gateway.url (the back end's base URL), user-token (older spelling of oauth by token exchange). Write the names exactly as the schema has them.