Operations
Work and intake
Every piece of work has exactly one owner, a status and a history, so nothing is lost between runs, people and channels.
An employee does not remember work in its head. It keeps a work queue: each item has an owner, a status (open, waiting, blocked, done), a priority, what it waits on, the next action, and a history of who did what. Every run starts by reading the employee's queue, and ends by updating it.
People can give an employee a task, add a note, mark an item done or reopen it, and hand it to another employee. Employees hand work to each other the same way, with the reason recorded. Reopening something an employee marked done counts against it (see Outcomes in Analytics).
Email, Slack messages, Stripe events and GitHub events enter through intake, once each (duplicates are ignored). In order:
1. A follow-up on an open thread (same person, same subject) joins that item and wakes its owner. 2. A channel someone owns goes to its owner: an inbox address, a Slack channel, a repository, a Stripe event type, or an employee's own email address. 3. Otherwise a router reads the event and picks the best employee, or drops it as noise.
Work, Arrivals shows every event and where it went and why; admins assign channel owners in Company, Channels or on each employee's page.
Inbound text is screened for prompt injection. A suspicious event still becomes work, but as a high-priority security item, and people are alerted.
With this switched on (Company > Rules, Independence, or per employee), a run that ends without touching the item it was woken for gets up to two more attempts that carry what it already found. After that the item is marked stuck and a person is told. Urgent, high-priority or overdue items nobody touched for a day get a nudge. It suits repetitive work (support, billing follow-ups) best.
How employees send is a policy: send (within trust levels and approval rules), ask before sending, or draft only. Set it for the workspace and override it per employee.