Zeroth's Business Operating System.

One system that sits across the tools you already run and does the admin work: drafting, invoicing, reporting, follow-up. In your voice, under your permissions, with a record of everything it does.

The difference

Your business with it, and your business without.

The rest of this page is how it works. This is what changes.

Without the system

  • Someone uses ChatGPT for email drafts. Nobody else knows what it's good at.
  • Every AI idea dies in a meeting, or in a tool nobody logs into twice.
  • What the firm knows lives in four people's heads, and two of them are flat out.
  • The same eight things get retyped into three systems every week.
  • Admin grows with revenue, so growth costs headcount.
  • Nobody can tell you what the AI did last Tuesday, or who asked it to.

With the system

  • Everyone works from the same context: your clients, your voice, your SOPs, your live numbers.
  • Five role groups, each scoped to what that role should see and do.
  • Nothing irreversible happens without a person approving the exact thing being sent.
  • Every action sits on a log nobody can edit, including us.
  • New automations land on a platform that's already standing, so each one is cheap.
  • The work only people can do is the work people are doing.
The argument

Why a chat window isn't an operating system.

A chatbot with no architecture behind it gives impressive answers. It still can't tell who is asking, keep your numbers straight, stop itself before something irreversible, or prove what it did. Four failures, and none of them can be fixed with a prompt.

It doesn't know who is asking

A shared folder of notes cannot tell your bookkeeper from your HR lead. If everyone's AI sees everything, you have published every salary and every client matter to the whole firm. Identity has to be built in. It has to reach the database itself, not sit in a prompt politely asking the model to look away.

It has nowhere to keep your numbers

Markdown files are a fine place for "how we write proposals". They are a terrible place for eleven thousand timesheet lines. Ask a folder of files which projects have unbilled hours and you get a plausible guess, not a total. Anything you need to count, filter, invoice or reconcile needs a real database behind it.

Nothing stops it before it acts

The moment an AI can send an email or issue an invoice, "usually right" stops being good enough. Something has to pause an irreversible action and show a person what is about to happen. The gate has to be a separate service, not a rule in an instruction file. A rule is a request.

It can't prove what it did

Six months from now someone will ask why a client got that email. "The AI sent it" is not an answer your insurer or your auditor will accept. The record has to be written automatically, and nobody can be able to quietly edit it. Including us.

Four failures, each one fixed by building something rather than asking for it. That's what the Zeroth Business OS is: identity that reaches the database, a real database behind it, a gate that runs as its own service, and a record nobody can edit. These four failures are what stop most firms putting AI anywhere near real client work.

The stack

What does the system look like?

Read it from the ground up. Each layer talks only to the ones directly above and below it, which is what makes any single piece replaceable without rebuilding the rest.

The framework Each person signed in as themselves, from Claude Cowork or Microsoft Copilot
Interface L5 Intelligence The orchestrator · loads every layer below into context · conversation, role-scoped dashboards, scheduled work Operational L4 Workspace SharePoint / Google Drive · proposals · deliverables · drafts · templates L3 Integrations M365 / Google · Slack / Teams · Xero · Stripe · CRM · + moreZeroth Gateway · role-gated · confirm-before-write · audited Memory L2 Database Yours, in your firm's name · timesheets · rates · CRM · audit log · encrypted secrets L1 Foundation Business context · SOPs · voice & brand · contracts · proposal templates · client briefs

Click any layer to jump to its detail below, or read the whole system in detail.

Where your data is

Where your business data goes.

There are two answers to this, not one: where your records are stored, and where the model that reads them runs. Most vendors quote you the first and stay quiet on the second. Here is both.

Your database, your region

  • CRM, timesheets, projects, the invoice mirror, the audit log and the encrypted credential vault sit in one region, in a cloud project provisioned for your firm.
  • Not multi-tenant. Your data does not share a database with another client of ours.
  • Your documents stay in your own Microsoft or Google tenancy. We take no copy.
  • If you leave, extraction is a database export plus the document store you already own. No proprietary format, and the business context is plain text readable without any of our software.

The model, United States

  • Anything that enters a conversation goes to a model hosted in the US: the text of an email you ask about, a client name, a figure from a report. That is a real cross-border flow and we do not soften it.
  • There is no selective disclosure boundary. Whatever the assistant reads is in the context window, and the context window goes to the model.
  • Whether that counts as a use or a disclosure under Australian privacy law is a genuine open question. We show you the flows; your lawyer lands it. Anyone telling you it is settled is guessing.
  • We train nothing. There is no training pipeline in the system.
  • If this is a concern for your firm, there are things we can do about it. Get in touch and we'll talk through the options.
Layer by layer

The fundamentals of each of the layers.

If you want the whole thing in one document — what it connects to, how we deploy it, where your data sits, what the first weeks look like and what it costs — read the Business OS in detail.

Layer 1

Foundation

plain files · every version kept · backed up in git

The things about your firm that are true on Monday and still true in March. Without this, every conversation starts by explaining who you are. That is why most firms' AI never gets past generic.

What this looks like in reality

A set folder structure of plain written documents, sitting in your document store like any other set of folders: one file for what the business does, one for how your firm writes, one per SOP, one per client. Everyone can read them, a couple of people can change them, and every change is a tracked edit somebody approved. The whole library is also committed to a private git repository at each refresh, so the history of your context sits beside the history of the system that reads it. The AI reads them at the start of a conversation the way a new hire would read the handbook.

What it holds

  • What the business does, who it serves, and how it makes money
  • Voice and tone, with real samples of your own writing, not adjectives about it
  • Your SOPs: how a proposal gets made, how an invoice gets raised, what "done" means
  • Role definitions: what each job does day to day
  • Per-client briefs, loaded only when someone is working on that client

What it lets you do

Ask for a proposal and get one that reads like your firm wrote it, because it was drafted against your samples and your process. New staff inherit this on day one instead of absorbing it over eighteen months.

How security works here

  • Changes are a human action, and every version is kept. The AI reads the Foundation; it does not rewrite it on its own. Every edit is saved as a new version showing exactly which words changed, who changed them and when, and the old version is still there. The whole library is also committed to a private git repository as a backup at each refresh, so your context can be recovered even if the live folder is deleted. Nothing is overwritten and nothing changes without somebody deciding it should.
  • No credentials live here. Not API keys, not passwords, not tokens. Context is context; secrets live in a vault the model cannot read from.
  • Client briefs load on demand. Working on one client doesn't pull every other client's brief into the conversation.
In detail: what your team can ask, once the context is written down
Layer 2

Database

Postgres · your own instance

A real database, in your name, holding the things a firm has to be able to count. This is the layer that separates an operating system from a very good chatbot.

What this looks like in reality

A private database in your firm's name, the same kind of thing your accounting package runs on, holding the operational numbers that currently live in spreadsheets and people's heads: hours, projects, clients, tickets, leave, expenses. Nobody has to log into it or learn it. You ask a question in plain English and get a real total back, and what you are allowed to see is decided by your role.

What it holds

  • Time tracking, projects and project membership
  • Clients, contacts, interactions and pipeline
  • Tasks, IT tickets and escalations
  • Leave requests and expense claims
  • An invoice mirror: a local copy of what your accounting system holds, so the AI can answer billing questions without ever being the source of truth for them

What it lets you do

"Which projects have unbilled hours over twenty?" "Show me every interaction with this client since March." "What did we spend on subcontractors last quarter?" Those are database questions. No amount of clever prompting gets them right from a folder of documents.

How security works here

  • Row-level security, enforced by the database itself. Permissions aren't a filter applied after the fact. The database physically will not return rows a person isn't entitled to. A staff member asking about leave sees their own; HR sees the team's. Same question, different answers, by design.
  • Own-row rules are keyed to the signed-in identity. Who filed a ticket or claimed an expense is set by who is logged in, not by whatever the request claims. You cannot file something in someone else's name.
  • Every change is trigger-audited at the table level, underneath the application, so the record doesn't depend on the application behaving.
  • Only named tables are reachable at all. The gateway carries an explicit list of what can be read and what can be written. Anything not on that list is unreachable rather than protected, which is a stronger thing: there is no permission to get wrong.
  • Some tables are read-only by design. The invoice mirror is one: it can be read and re-synced from your accounting system, never hand-edited, so a local number can't silently disagree with the ledger.
In detail: how the database and its permissions are put together
Layer 3

Integrations

Zeroth Gateway

The single door between the AI and anything that can affect the outside world. If one section here is worth reading twice, it is this one. The gateway is the difference between an assistant that suggests and a system you can let act.

What this looks like in reality

A small piece of software of your own sitting between the AI and everything that can affect the outside world: your accounting package, your mailbox, your calendar, payments. Every action has to go through it. It checks who is asking and whether their role allows it, shows a person a preview before anything irreversible, and writes a line in a log nobody can edit. Nothing reaches your accounting package or your mailbox by any other route.

What it can connect to

  • Your accounting package, for invoices, payments, bank transactions and reports
  • Your mailbox and calendar, in your existing Microsoft 365 or Google tenancy
  • Your document store, and your team chat and meeting notes
  • Payments, for checkout links and subscriptions
  • Publishing and site analytics
  • Anything not on this list is unreachable, rather than merely disallowed

What it lets you do

Draft an invoice from approved timesheets. Send an email from a shared mailbox. Book a meeting with a Teams link. Take a payment. All from a conversation, and all of it recorded, permissioned and stoppable.

How security works here

  • There is no Zeroth password. The system mints no credential of its own. Everyone signs in with the Microsoft or Google account they already have, through your identity provider, so your multi-factor policy applies, we inherit it, and we hold no bypass. Remove someone from your tenant and their access ends everywhere, with no separate account left to forget about.
  • Confirm-before-write, enforced by the server. Anything irreversible takes two calls, never one. The first returns a preview and a single-use token; the second executes. Crucially, the second call runs the payload stored with the preview. A preview approved for one recipient cannot be spent on another.
  • Step-up approval on the sharpest actions. Sending an invoice to a customer doesn't end with the AI at all: it stages the send and returns a link. A person opens it, signs in to Microsoft afresh (a warm session isn't enough), reads a summary the server wrote from what your accounting system returned, and releases it. The AI is never handed anything it could redeem on its own.
  • An append-only audit log. Who, which action, when, and whether it succeeded, including the ones that were refused. Nobody can edit or delete a row. Not your admin, not us.
  • Rate limits, and they fail closed where it counts. Ordinary calls keep working if the limiter is unhealthy. That is the right trade for an already-authenticated caller. Anything that sends, publishes or moves money does the opposite and refuses, because a looping agent plus a broken counter is exactly what emails a client two hundred invoices.
  • Read routes never ask for write access. Where a capability only needs to read your accounting system, the read-only scope is what's requested and the write twin is not. So there is no permission in the granted token that could record or reverse a payment. Mail access is your own mailbox only: nothing shared, nothing that deletes or moves. Widening any of it needs a fresh administrator consent; it can't happen quietly.
  • Credentials never reach the model. Your accounting and mail tokens live in an encrypted vault readable only by a server-side function. Claude holds a URL and a short-lived access token. Nothing that would let it act as you anywhere else.
In detail: every system the gateway connects to
Layer 4

Workspace

SharePoint / Google Drive

Where documents live. This is your existing setup on purpose. We do not move your files somewhere new so that we can be the ones holding them.

What this looks like in reality

The SharePoint or Google Drive your firm already uses, unchanged. Same folders, same sharing, same permissions. The difference is that a finished proposal lands in the folder it belongs in, in your template, rather than arriving as text in a chat window for somebody to paste and reformat. If a person can't open a folder today, nothing about that changes.

What it holds

  • Proposals, reports and client deliverables in progress
  • Templates and the design system that keep output on-brand
  • The Foundation files themselves, so your team can read and edit them like any other document

What it lets you do

Ask for a document and get a real file, in the right folder, in your template. Not a wall of text in a chat window that you then have to reformat.

How security works here

  • Your existing permissions apply, unchanged. If someone can't open a folder today, the AI acting for them can't either. We inherit your setup rather than replacing it with our own.
  • No copy is taken. Documents stay in your tenancy. There is no Zeroth-side mirror of your files.
  • Writes are fenced to the workspace. Automated file operations can't reach outside the folders they're scoped to.
In detail: how it is deployed on the tenancy you already own
Layer 5

Intelligence

Claude / Copilot

The model, and the surfaces people meet it through. This is the only layer we would happily replace tomorrow, and that is the point of building the other four. Models change every few months. Your operating system should not have to. When something better ships, this layer gets swapped and the four below it keep your knowledge, your data, your permissions and your history exactly where they are. A firm whose AI is one vendor's chatbot starts again at that point, and you carry on.

What this looks like in reality

The chat window your team already has open, Claude or Microsoft Copilot, with your firm behind it. No new application to learn and no separate login. Somebody asks a question the way they'd ask a colleague, and the answer comes back specific to your business because the four layers underneath are feeding it.

What it holds

Nothing permanently, and that's deliberate. It loads context from Foundation, queries the database, calls the gateway, reads and writes the workspace. Then the conversation ends. Everything durable lives in a layer that outlives the chat.

What that leaves your team with is the full capability of a frontier model, Claude or whichever platform leads when you read this, wired into the business rather than sitting beside it. The same model everyone else is using, except it knows your clients, your numbers and how your firm writes, and it can act in your accounting package and your mailbox with your permissions applied. That is the whole difference: not a better chatbot, the same one with your business behind it.

Four ways people use it

  • Conversation, operated straight from Claude Cowork or Microsoft Copilot. No separate place your team has to remember to go.
  • Dashboards: role-scoped views of live data. Detailed below.
  • Scheduled work: a Monday brief, a monthly invoice batch, a Friday digest. Same permissions, same audit trail, nobody has to remember to trigger it.
  • Skills: your firm's repeatable jobs, packaged as a plugin your Claude organisation subscribes to. Everyone runs the same version, and a change arrives as a release rather than an email saying "do it differently now". Detailed below.

In detail · the dashboards

Not a reporting tool bolted on the side

Most firms end up with analytics in a second product: a separate login, a nightly export, and numbers that are always a day behind and never quite reconcile with the source. The dashboards here aren't that. Each one is a small view rendered from the same gateway calls the chat makes, as the same signed-in person. The numbers are live, and there is no second copy of your data to drift.

Each role gets a view built around the decisions that role makes, rather than one dashboard with everything on it and permissions bolted over the top:

Admin

Unbilled hours by project, what's ready to invoice, what's overdue, this month against last.

HR

Leave balances and pending requests, who's away next fortnight, onboarding in progress.

IT

The open ticket queue by severity, what's been waiting longest, what's escalated.

Marketing

Site traffic and campaign performance, what's scheduled, what's published.

They are small and quick to change on purpose. Building one is a conversation, not a project, so a view that stops being useful gets replaced rather than endured. Which is the actual difference: a dashboard nobody can change is a dashboard nobody reads by March.

Security is not separate. A dashboard is not a back door around the permission model. It goes through the same gateway, as the same person, under the same row-level rules. It cannot display anything that person couldn't have asked for in a sentence, no data is exported into it, and every call it makes lands on the same audit log as everything else.

In detail · the skills

Your procedures, versioned and shared

A skill is a written procedure the AI follows on request: onboarding a new person, refreshing the Foundation, building a dashboard, or something written for your firm alone, like the month-end timesheet run. The ones that come with the system are maintained by us. The ones written for you are yours.

They reach your team as a plugin. The skills live in a private git repository in your firm's own GitHub organisation, your Claude organisation subscribes to it, and the skills appear for everyone the subscription covers. Nobody on staff needs a GitHub account and nobody installs anything. A change is a commit and a version number, so everyone is running the same version and you can see exactly what changed and when.

Security is not separate here either. A skill can only do what the person running it could have asked for in a sentence: same gateway, same role, same approvals, same audit log. Which skills a person gets is set in your Claude organisation, not by us.

How security works here

  • The model has no privileges of its own. Everything it can do, it does through the gateway as the signed-in person. It can't widen its own access, and there's no back door to the database.
  • Each tool carries its own permission level. Every action the system can take is set to one of three, tool by tool: run it (reading a report), preview it and wait for an explicit yes (sending an email, drafting an invoice), or hand it to a person who signs in afresh to release it (sending an invoice to a customer). Tools can also be limited by role, so a capability simply isn't present for people who shouldn't have it. Which level applies to which tool is configuration set for your firm, and the AI cannot change it.
  • Text from outside is fenced. Email bodies, invoice line items, calendar invites, meeting transcripts: anything written by someone outside your firm arrives wrapped in a labelled marker carrying a one-time code. That's there to stop a trojan instruction planted in ordinary-looking content ("pay this to a new account") passing itself off as a request from you, because the attack on an AI assistant isn't hacking it, it's emailing it. The fence makes the boundary visible and unforgeable; it doesn't make the text harmless, which is what the next point is for.
  • Instructions come from your people only. If something in a document or an email tries to direct the system ("pay this to a new account", "ignore your rules"), the system surfaces it and asks, quoting the line and naming where it came from.
  • Secrets never appear in output. Keys and tokens aren't readable by the model and can't be printed into a chat, a document or a dashboard.
In detail: model choice, and why this layer is the swappable one

Want to see it running on your operation?

If you want your business running more efficiently and you're not sure where to start, get in touch below. We'll tell you what we would build, what it would change and what it would cost.

Get in touch See what it costs