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 and without the system

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 stops at a meeting, or ends in a tool nobody logs into a second time.
  • What the business knows is held by four people, and two of them are at capacity.
  • 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.
  • You choose which actions wait for a person's yes, action by action, and the person sees the exact thing being sent.
  • Every action is recorded on a log that nobody can edit, including us.
  • New automations are built on a platform that is already in place, so each one costs less to build.
  • The work only people can do is the work people are doing.
The argument

Four limits of a chatbot on its own

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

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 record to the whole business. Identity has to be built in. It has to be enforced by the database itself. An instruction in a prompt asking the model to ignore some records does not protect them.

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. A database returns the total. Anything you need to count, filter, invoice or reconcile needs a real database behind it.

Nothing stops it before it acts

Once an AI can send an email or issue an invoice, "usually right" is not good enough. The business has to be able to choose which actions stop and show a person what is about to happen. The approval step has to run as a separate service. A rule in an instruction file is only 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 edit it, including us.

Four failures, each one fixed by building a component. The Zeroth Business OS is those four components: identity enforced by the database, a database for your records, an approval step that runs as its own service, and a record nobody can edit. These four failures are what stop most businesses using AI on client work.

The stack

The five layers of the system

Read it from the bottom up. Each layer connects only to the layers 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 · approvals set per action · audited Memory L2 Database Yours, in your business'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: where your records are stored, and where the model that reads them runs. Most vendors give the first and leave out the second. Both are below.

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 business.
  • Single-tenant: your data does not share a database with any other 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 cross-border flow of data, and we state it plainly.
  • 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 an open question. We show you the flows, and your lawyer decides. 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 business, there are things we can do about it. Get in touch and we'll talk through the options.
Layer by layer

Each layer in detail

If you want the whole thing in one document, covering 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 facts about your business that stay the same from week to week. Without this, every conversation starts by explaining who you are. That is why AI in most businesses gives generic answers.

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 business 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 every conversation.

What it holds

  • What the business does, who it serves, and how it makes money
  • Voice and tone, with samples of your own writing
  • 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 you wrote it, because it was drafted against your samples and your process. New staff can read it from their first day.

How security works here

  • Changes are a human action, and every version is kept. The AI reads the Foundation, and people make the edits. 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. Every change is one somebody decided to make.
  • No credentials are stored here. API keys, passwords and tokens are kept in a vault the model cannot read.
  • 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 database in your name, holding the things a business has to be able to count. A chatbot on its own has no equivalent of this layer.

What this looks like in reality

A private database in your business's name, the same kind of thing your accounting package runs on, holding the operational numbers that are currently kept in spreadsheets or known only to individual staff: hours, projects, clients, tickets, leave, expenses. Nobody has to log into it or learn it. You ask a question in plain English and get an exact 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. A folder of documents cannot answer them accurately, however the question is phrased.

How security works here

  • Row-level security, enforced by the database itself. The database returns only the rows a person is entitled to, so permissions apply before any data leaves it. 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. Whatever the request claims is ignored. 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. The gateway carries an explicit list of what can be read and what can be written, and reaches only the tables on it, so there is no permission elsewhere 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 and cannot be edited by hand, so a local number always matches the ledger as at the last sync.
In detail: how the database and its permissions are put together
Layer 3

Integrations

Zeroth Gateway

The single connection between the AI and anything that can affect the outside world. This is the most important section on this page. The gateway is what lets the system take actions safely, where an assistant on its own can only make suggestions.

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, applies the approval level your business set for that action, and writes a line in a log nobody can edit. It is the only route to your accounting package and your mailbox.

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
  • Only the systems on this list are connected

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 issues 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 and we hold no way around it. Remove someone from your tenant and their access ends everywhere, with no separate account left to forget about.
  • Preview and yes, enforced by the server. Any action your business sets to wait for a yes takes two calls. The first returns a preview and a single-use token; the second executes. The second call runs the payload stored with the preview, so a preview approved for one recipient cannot be used for another.
  • Release after a fresh sign-in, for the actions you choose. An action set to this level, such as sending an invoice to a customer, is staged and returns a link. A person opens it, signs in to Microsoft afresh (an existing signed-in session is not enough), reads a summary the server wrote from what your accounting system returned, and releases it. The release is made on that page, by that signed-in person.
  • 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. That includes your admin and us.
  • Rate limits that refuse when they cannot count. Ordinary calls keep working if the rate limiter is unavailable, which suits a caller who is already authenticated. Anything that sends, publishes or moves money refuses instead, because an agent stuck in a loop with a broken counter could email 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 requested and the matching write scope is left out. So there is no permission in the granted token that could record or reverse a payment. Mail access is your own mailbox only, with nothing shared. Widening any of it needs a fresh administrator consent, and it cannot happen without one.
  • 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, and 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 are stored. We use your existing setup on purpose, so your files stay where they are and under your control.

What this looks like in reality

The SharePoint or Google Drive your business already uses, unchanged. Same folders, same sharing, same permissions. A finished proposal is saved in the folder it belongs in, in your template, ready to use without pasting or reformatting. 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 file in your template, saved in the right folder.

How security works here

  • Your existing permissions carry over. The AI acting for someone opens what that person can already open. The system uses your setup as it is.
  • No copy is taken. Documents stay in your tenancy. There is no Zeroth-side mirror of your files.
  • Writes stay inside the workspace. Automated file operations work only in 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 applications people use it through. You choose the model: standard Claude, Claude hosted in Australia, or Microsoft Copilot. This is the only layer designed to be replaced, which is why the other four are built separately. Models change every few months. When a better one is released, this layer is replaced and the four below it keep your knowledge, data, permissions and history where they are. A business whose AI is one vendor's chatbot has to start again at that point. You carry on.

What this looks like in reality

The chat window your team already has open, Claude or Microsoft Copilot, with your business 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 supply the context.

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 that needs to be kept is stored in one of the other layers.

Your team gets the full capability of a frontier model, Claude or whichever platform leads when you read this, connected to the business. It is the same model everyone else uses. It knows your clients, your numbers and how your business writes, and it can act in your accounting package and your mailbox with your permissions applied.

Four ways people use it

  • Conversation, used directly 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 own repeatable jobs, packaged as a plugin your Claude organisation subscribes to. Everyone runs the same version, and a change arrives as a new version of the plugin. Detailed below.

In detail · the dashboards

Dashboards on the same data and permissions

Analytics in most businesses sits in a second product: a separate login, a nightly export, and numbers a day behind that rarely reconcile with the source. Each dashboard here 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 fall out of date.

Each role gets a view built around the decisions that role makes:

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. A new one is built by asking for it in a conversation, so a view that stops being useful is replaced. Dashboards that cannot be changed tend to stop being read.

Security applies the same way. A dashboard goes through the same gateway, as the same person, under the same row-level rules. It shows only what that person could have asked for in a sentence, no data is exported into it, and every call it makes is written to 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 business 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 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 applies the same way here. 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 by your business in your Claude organisation.

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 is no other route to the database.
  • Each action is set to the level your business wants. There are three levels: run it, show a preview and wait for a yes, or hold it for a person to release after signing in again. Your business chooses the level action by action: for example, run reports straight away, preview emails and invoice drafts, and hold invoices to customers for release. Actions can also be limited by role, so a capability is available only to the people who should have it. The levels are configuration set for your business, and the AI cannot change them.
  • Text from outside is marked. Email bodies, invoice line items, calendar invites, meeting transcripts: anything written by someone outside your business arrives inside a labelled marker carrying a one-time code. The marker stops an instruction hidden in ordinary-looking content ("pay this to a new account") from passing as a request from you. The most likely attack on an AI assistant is an email containing instructions. The marker makes the boundary visible and impossible to fake. It does not make the text harmless, which is what the next point covers.
  • 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

The next step: a short call

If you want your business running more efficiently and you're not sure where to start, book a call. On the call we learn about your business and answer your questions, and if it's a fit, we agree where to start.

Book a call See what it costs