The Zeroth Business OS in detail

What it is

A Business OS is a set of five layers assembled on infrastructure your business owns, so that the AI your people already have access to can work with your business's own context, records and systems.

The five layers are your Foundation (your context, written down), your Database (the operational records a business has to be able to count), the Gateway (the single permissioned connection to your other systems), your Workspace (the document store you already use), and the Intelligence layer (the model, and the chat window people use it through). Each is explained at length on the overview page.

Where the build includes the Business OS, the same framework goes in and is configured to your business: your roles, your processes, your voice, your clients, your systems. There are no packages to choose between and no per-capability modules to buy. What Diagnose decides is how the framework is shaped around your business and what runs on it first.

It is built for Australian businesses of roughly five to thirty people, and fits best where the core work follows the same steps every time. Above thirty we scope and quote, because the same shape may not fit.

Why we built it

The pattern kept repeating inside businesses we worked with. Software was bought, webinars were sat through, sometimes a consultant was paid. Six months later the tools sat unused while the team did the work by hand. The software was often good. Nobody had built it into how the business works.

Meanwhile the AI everyone already had was capable, and of little use for the business's own work. Ask a general assistant which projects have unbilled hours and it cannot answer, because it has never seen your timesheets. Ask it to draft a proposal and you get something competent and anonymous, because it has never read anything your business wrote. Ask it to raise an invoice and it cannot, because it has no way to reach your accounting package, and you would not want it to have one without an approval step.

The three gaps are context, records and access to your systems. A business that builds these three once does not have to rebuild them each time the model changes.

What it does

Eight things, in the order most businesses end up using them. Each is a plain question or instruction from a person, answered or carried out against your own systems.

Answer questions about your own numbers

Operational questions that a folder of documents cannot answer, because they need counting and filtering rather than reading.

Find and summarise what was said

Across your mail, your calendar, your team chat and your meeting transcripts, within the caller's own access.

Draft in your own voice

Proposals, reports, client emails and replies, written against your samples and your process.

Raise invoices from approved hours

Drafted into your accounting package from approved timesheets, with the hours stamped as billed in the same step so nothing is billed twice or missed.

Send email, book meetings, take payments

From a conversation, through the gateway, with a preview and an explicit yes on each action your business sets to wait for one.

Run the recurring work on a schedule

A Monday brief, a monthly invoice batch, a Friday digest. Same permissions and same audit trail as a person asking, without anyone having to remember.

Give each role a live view

Small dashboards rendered from the same gateway calls the chat makes, as the same signed-in person, so there is no second copy of your data to fall out of date.

Answer "how do we do this here"

Your written process, available to a new starter from the first day.

What it connects to

Every connection runs through the gateway, and the list is explicit: only the systems on it are connected.

• Accounting. Xero: invoices, payments, bank transactions, aged receivables, profit and loss, balance sheet.
• Email and calendar. Microsoft 365 or Google, the caller's own mailbox and calendar.
• Documents. SharePoint, OneDrive or Google Drive, in your existing tenancy.
• Team chat and meetings. Microsoft Teams chats and meeting transcripts.
• Notes. OneNote notebooks.
• Payments. Stripe: balance, customers, subscriptions, checkout links.
• Publishing. LinkedIn, as your profile or your company page.
• Site analytics. PostHog, for traffic, sources and campaign performance.
• Your own database. Time, projects, clients, pipeline, tasks, tickets, leave, expenses.

Beyond that list, if a system has an API and your business has a real use for it, it becomes a gateway route with the same role gating, the same approval behaviour and the same audit trail as everything else. We add a connection when a business needs it, and we do not advertise integrations nobody uses.

How it works underneath

Eight pieces, and the reason each is separate from the others.

• Context, in plain files. Your Foundation is a set folder structure of written documents in your document store. Readable by your team, editable by a couple of people, every version kept, and the whole library committed to a private git repository as a backup at each refresh. No proprietary format.
• Skills and code, in git. The code that runs your system (the gateway, its database migrations, its configuration) lives in a private repository, and the skills your team uses live in a second one in your own GitHub organisation, delivered to everyone as a versioned plugin. Every change to either is a diff with an author and a date.
• Records, in a database. A Postgres database provisioned for your business alone, with no other client's data in it. Anything you need to count, filter, invoice or reconcile lives here.
• Permissions, in the database itself. Row-level rules mean the database returns only the rows a person is entitled to, so only those rows reach the model.
• One route out. The gateway is a small service of your own. Every action against an outside system goes through it, and it checks the caller's role before doing anything.
• An approval level on every action. Each action is set to run, to preview and wait for a yes, or to be held for a person to release after signing in again. A preview takes two calls: a preview and a single-use token, then execution of the payload that was previewed.
• An append-only log. Who, what, when, and whether it succeeded, including refusals and including the previews that were issued but never released. Nobody can edit or delete a row.
• A boundary around outside text. Anything written by someone outside your business arrives marked and labelled, so a hidden instruction cannot pass as a request from your team.

Model and provider choice

The Intelligence layer is the one designed to be replaced, which is why the other four are built separately.

• Today it is Claude or Microsoft Copilot, used through the chat window your team already has open. There is no separate Zeroth app to learn.
• Nothing that needs to be kept is stored in the model. Context, records, permissions and history all sit in layers underneath it, so swapping the model does not cost you any of them.
• Model choice is configuration. When a better model is released, that layer changes and the four below it stay as they are. A business whose AI is one vendor's chatbot starts again at that point. You carry on.

Access, identity and approvals

This section explains what lets the system take actions safely, where an assistant on its own can only make suggestions.

• There is no Zeroth password. Everyone signs in with the Microsoft or Google account they already have. Your multi-factor policy applies, and we hold no way around it. Remove someone from your tenant and their access ends everywhere.
• Roles are set by your business. Admin, finance, HR, IT, marketing and general staff each see a different set of records, enforced by the database itself.
• Each action is set to the level your business wants. Run it, show a preview and wait for a yes, or hold it for a person to release after signing in again. Your business sets the level action by action, and the AI cannot change it.
• Your existing document permissions carry over. The AI acting for someone opens what that person can already open.
• Read access does not come with write access. Where a capability only needs to read, the read-only scope is what is requested. Widening it needs a fresh administrator consent.
• Credentials never reach the model. Your accounting and mail tokens sit in an encrypted vault readable only by a server-side function.
• Everything is logged, including refusals. Six months from now, "why did a client get that email" has an answer with a name and a timestamp on it.

How we deploy it

Each business gets its own deployment. There is no shared Zeroth tenant holding several businesses' data.

• Your database, your cloud project. Provisioned for your business in an Australian region, holding your CRM, timesheets, projects, invoice mirror, audit log and encrypted credential vault. It is not shared with any other client of ours.
• Your documents stay where they are. They remain in your Microsoft 365 or Google tenancy. We take no copy.
• Your accounts, your credentials. You hold them. The gateway acts with permissions your administrator granted and can withdraw.
• Nothing to install. The OS reaches your team through the tools already open on their machines.
• Your skills, from your own repository. The procedures your team runs through the OS are packaged as a plugin your Claude organisation subscribes to from a private git repository in your own GitHub organisation. Nobody on staff needs a GitHub account, and a change arrives as a new version the way any other update does.
• Yours to keep. If Zeroth closed tomorrow it would keep running, and the database hosting transfers to your billing. Extraction is a database export, the document store you already own, and the git repositories holding the code and your skills. The business context is plain text readable without any of our software.

What the first weeks look like

Diagnose, then a build that goes live on the date set in your delivery engagement. The sequence is the same every time.

Compared with the alternatives

This table compares the software routes a business can take. The other kinds of AI offer, such as training courses and free audits, are compared on the services page.

On the fourth row: building it yourself is possible, and some businesses should. Most of the time goes into the permission model, the approval step and the audit trail, and that is most of what we charge for.

Who uses it, and for what

Everyone works through the same system, and each person sees what their role allows.

• Director. Pipeline, cash and delivery status in one place, compiled into a Monday brief.
• Finance and admin. The billing round: invoices drafted in Xero from approved hours, and you choose whether sending waits for your yes.
• Operations. A new starter set up in one pass: access requested, kit ticket raised, intro booked, each approval routed to its owner.
• Sales. Proposals written in the business's voice from its own context, ready for review.
• HR. Leave checked against balances, booked, cover flagged, and HR sees only the records HR is permitted to see.
• IT. The open ticket queue by severity, what has waited longest, what is escalated.
• New starters. The business's documented process, from the first day.

Where your data sits

There are two answers: where your records are stored, and where the model runs. Most vendors give the first and leave out the second.

Your records

• Your database sits in an Australian region, in a cloud project provisioned for your business, and is not shared with another client of ours.
• Your documents stay in your own Microsoft or Google tenancy. We take no copy.
• Extraction, if you leave, is a database export, a document store you already own, and the git repositories holding the code and your skills.

The model

• Anything that enters a conversation goes to a model hosted in the United States: 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.
• 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.
• 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 will talk through the options.

How engagements are structured

The first step is a short call. Everything after it is priced in writing before you buy. See the services page.

• The call. 15–20 minutes with Peter McEvey to learn about your business and check the fit. If it's a fit, we agree where to start.
• The full Systems Diagnostic, for complex cases. For a business with many teams, many systems or compliance obligations. The full Systems Diagnostic is quoted to the size and complexity of your business, from A$3,900, ex GST. Invoiced in full at booking, and a complete piece of work on its own.
• Deliver: the build. Delivery usually starts from A$5,000, paid up front or monthly. Every item, including the Business OS install where the build includes it, carries an estimated price in writing before you decide, and the delivery engagement fixes the scope and the price. Invoiced only when you sign it.
• Evolve. An optional monthly plan, quoted with your delivery engagement, before you decide whether to take it. Each month it builds the next items on your ranked list, and it covers monitoring and a monthly session with your team. It covers our services only: your database and other subscriptions stay on your own accounts, paid by you. Month to month, thirty days' notice, except a build paid monthly, where Evolve runs for that payment term.
• One decision at a time. Once every build is priced, you sign a delivery engagement for the builds you choose, or stop there. Nothing is ever invoiced unless you order it.

Nothing about the OS is priced per seat, per agent or per integration, because a system your business runs on should not get more expensive every time someone new uses it.

Common questions