The Zeroth Business OS, in detail.

What it is

A Business OS is not an app your team logs into. It is a set of five layers assembled on infrastructure your firm owns, so that the AI your people already have access to can work on your business rather than in general.

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

The same framework goes in every time and is configured to your firm: 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 the diagnostic decides is how the framework is shaped around your business and what runs on it first.

It is built for Australian professional services firms of roughly five to thirty people. Above thirty we scope and quote rather than pretend the same shape fits.

Why we built it

The pattern kept repeating inside firms 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. Not because the software was bad, but because nobody built it into how the firm actually works.

Meanwhile the AI everyone already had was genuinely good and almost useless for real 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 firm 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 a gate.

Those three gaps are context, records and reach. A firm that closes them once, properly, does not have to close them again every time the model changes.

What it does

Eight things, in the order most firms end up using them. Each is a plain question or instruction from a person, answered or carried out against your real 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 firm's voice

Proposals, reports, client emails and replies, written against your samples and your process rather than a generic house style.

Raise invoices from approved hours

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

Send email, book meetings, take payments

From a conversation, through the gateway, with a preview and an explicit yes before anything leaves the firm.

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 drift out of step.

Answer "how do we do this here"

Your written process, available on day one to a new starter instead of eighteen months of asking around.

What it connects to

Every connection runs through the gateway, and the list is explicit: a system that is not on it is unreachable rather than merely disallowed.

• 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 firm 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 would rather add one that earns its place than advertise fifty.

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 firm's 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 real database. A Postgres database provisioned for your firm, not a shared multi-tenant one. Anything you need to count, filter, invoice or reconcile lives here.
• Permissions, in the database itself. Row-level rules mean the database will not return rows a person is not entitled to. It is not a filter applied after the model has already seen everything.
• One door 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.
• A gate on anything irreversible. Two calls, never one: a preview and a single-use token, then execution of the payload that was previewed. Sending an invoice goes further and is released by a person after a fresh sign-in.
• 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 firm arrives fenced and labelled, so a planted instruction cannot pass itself off as a request from your team.

Model and provider choice

The Intelligence layer is the one we would happily replace tomorrow, and that is the point of building the other four properly.

• Today it is Claude or Microsoft Copilot, met through the chat window your team already has open. There is no separate Zeroth app to learn.
• The model is not where anything durable lives. 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 something better ships, that layer changes and the four below it stay exactly where they are. A firm whose AI is one vendor's chatbot starts again at that point. You do not.

Access, identity and approvals

This is the part worth reading twice, because it is what makes the difference between an assistant that suggests and a system you can let act.

• There is no Zeroth password. Everyone signs in with the Microsoft or Google account they already have. Your multi-factor policy applies, we inherit it, and we hold no bypass. Remove someone from your tenant and their access ends everywhere.
• Roles come from your firm, not from us. Admin, finance, HR, IT, marketing and general staff each see a different slice, enforced by the database rather than by instructions to the model.
• Each tool carries its own permission level. Run it, preview it and wait for a yes, or hand it to a person who signs in afresh to release it. Set per tool for your firm, and the AI cannot change it.
• Documents keep your existing permissions. If someone cannot open a folder today, the AI acting for them cannot either.
• 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

It is not SaaS. There is no Zeroth tenant your firm becomes a row in.

• Your database, your cloud project. Provisioned for your firm in an Australian region, holding your CRM, timesheets, projects, invoice mirror, audit log and encrypted credential vault. Not shared with another client of ours.
• Your documents stay put. 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 firm's 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 we vanished tomorrow it keeps 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

Two to four weeks from signature to a system your team is using. The shape is the same every time.

Compared with the alternatives

Not against other consultancies, which is covered on the services page, but against the other ways a firm can try to solve this.

The honest version of the fourth row: building it yourself is entirely possible and some firms should. What takes the time is not the chat interface, it is the permission model, the approval gate and the audit trail, which is most of what we charge for.

Who uses it, and for what

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

• Director. Pipeline, cash and delivery status in one place, so the Monday brief writes itself.
• Finance and admin. The billing round: invoices drafted in Xero from approved hours, nothing sent without a yes.
• Operations. A new starter sorted in one pass: access requested, kit ticket raised, intro booked, each approval routed to its owner.
• Sales. Proposals written in the firm's voice from the firm's own context, ready for review.
• HR. Leave checked against balances, booked, cover flagged, and HR sees only the rows HR should.
• IT. The open ticket queue by severity, what has waited longest, what is escalated.
• New starters. The firm's actual process, on day one.

Where your data sits

There are two answers here, not one, and most vendors quote the first and stay quiet on the second.

Your records

• Your database sits in an Australian region, in a cloud project provisioned for your firm, 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 real cross-border flow and we do not soften it.
• 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.
• 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 will talk through the options.

How engagements are structured

Two products, in sequence. The diagnostic's price is published; everything after it is priced in writing in your Diagnostics Report before you buy. See the services page.

• Systems Diagnostic. A$3,900 under ten people, A$4,900 for ten to thirty, price on quote above thirty. Invoiced in full at booking, and a complete piece of work on its own.
• Deliver — the Business OS install. Fixed for your size, stated with every per-item price in your Diagnostics Report. Invoiced only on acceptance of a build order, at or after the Diagnostics Review.
• Maintain. A flat monthly plan, priced for your size before you commit to it. Month to month, thirty days' notice, no minimum term. It covers monitoring, a modification allowance, a monthly session with your team and your database hosting.
• One decision point. The Diagnostics Review — you order the build there or take the Diagnostics Report and stop; nothing beyond the diagnostic is ever invoiced unless you order it.

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

Common questions