How it works
A being does its job inside the firm’s operating system. This page is about that system: what it holds, how work moves through it, how it knows who is acting, and where everything sits.
One instance per firm
Every firm gets its own operating system: its own database, its own kernel, its own connections. Nothing is shared with another firm. The beings who work in it keep their own stores, so a firm’s operating system can be switched off and the being still exists, and a being can be taken out without touching the firm’s record.
The firm’s record
Small firms run on many systems, and nobody has a data warehouse. The operating system does not replace those systems. It holds the operational slice: the things the firm has to act on, track and answer for. It is built one function at a time, and each function is a proper schema with its own permissions, not a folder of exports.
Finance is live: suppliers, invoices, categories, bank accounts and cards, in the firm’s currency, with a worker that sweeps the invoices inbox and forwards what the accountant needs. The team, the workers and the mail that arrives for them are live. Client onboarding, compliance administration and company secretarial are in build.
The point of the record is that the firm becomes queryable. A being can ask “which invoices are unpaid” or “which client reviews fall due next month” and get an answer from the firm’s own data, instead of chasing three inboxes.
Procedures
The firm’s processes are written down as procedures the system can run and a person can read: what triggers them, which steps follow, what counts as done, when to stop and ask. Procedures are versioned, and every run is pinned to the version it followed, so a piece of work can always be traced to the exact procedure that produced it. Whether a being may change a procedure on its own or must ask a person first is a matter of the authority it has been granted, exactly as for a human colleague: a being may be trusted to improve some processes, all of them, or none without approval, and the charter says which.
Workers
Routine, well-defined steps are done by workers: narrow automations, usually on smaller and faster models, each built for one job and registered in the operating system as its own actor. Every worker is assigned to a being. It is woken either by the operating system’s own schedule or by the being, given its instructions, and hands back its result and files. A worker can delegate to another worker, but only a few levels deep, and it never holds authority of its own: the being it reports to does. Beings orchestrate; workers execute.
The kernel
Underneath sits the kernel, which is the part that makes delegation safe. It keeps the register of who is on the team, the schedules that wake workers and run procedures, the supervision that notices a run that has stalled or died and marks it so, the credentials in a vault so that no secret ever sits in a being’s memory or a worker’s prompt, and the record: every schedule, run, instruction and change, with who did it and when.
Who is acting
The operating system does not take anyone’s word for who they are. Every human, being, worker and external agent on the team is a registered member with its own identity. Machine members connect through one gateway, carrying a token signed with the operating system’s own key; the gateway checks the token and runs the request as that member’s own database role, and every row it can see or change is governed by row-level permissions for that role. Nothing runs as “the system”. A member can be revoked in one step, and all of a member’s tokens can be invalidated at once.
This is also how other assistants and agents join. Through the team connection protocol they become members like any other, with their own identity, their own permissions and the same record behind them. The firm can use whichever assistants it likes and still have one trail across all of them.
Handing off to people
The system is built to hand off, not to press on. A being’s charter says which decisions and which signatures belong to a person, and the record shows every hand-off: a conversation marked as waiting on the owner, a run that escalated, a recommendation logged with its rationale and a suggested next step. People are reached where they already are, in the team chat, by email or by text, and the being waits. In regulated work the qualified person decides and signs; the being has prepared, tracked and filed, and the record shows that it did.
What it connects to
Connections are the tools every member of the team uses, human or being; they are not where the firm’s truth lives. Live today: email and calendar, the team chat, the task tracker, the wiki, the documents drive, the code host, the feedback board, the test manager, the investor-update and check-in tools, and a dedicated mailbox for invoices. A first practice-management connection for financial advice firms is in build.
Where data lives
The firm’s operating system and each being’s store are held in the country the firm operates in, under its legislation; for a UK firm, in the United Kingdom. The systems the firm already uses keep their own data; the operating system holds only the operational slice, and a being reads the rest through its seat, as a person would. Secrets live in a vault. The firm can read its record directly and export it at any time; self-service export from the owner’s console is in build.
How it changes
Every change to a firm’s operating system is a reviewed, recorded change: a proposal, a review, a merge, an automatic apply, a verification that it landed. That is true of a new function, a changed procedure and a permission grant alike. The firm’s operating system has a history, and the history can be read.