Bedstone OS is your business portal, deployed privately at your own subdomain. Each business function is a module on one shared registry of entities, jobs, suppliers, people and permissions. Accounts runs in production today, with entities and jobs, suppliers, approvals, document intake and reporting alongside it. An ask layer over the top answers plain-language questions from the same data, with sources attached.

Bedstone OS | Internal AI Workspace AU

What Bedstone OS is

Bedstone OS is a portal, deployed privately at a subdomain you control. It is where your team does the work, which is the part most internal AI projects skip. A dashboard reports on work that happened somewhere else. An assistant answers questions about work that happened somewhere else. Bedstone OS is where it happens.

Every function is a module, and every module sits on one shared spine: a single registry of your entities, jobs, suppliers, people and permissions. That is the architectural point. Because the registry is shared, a job created once is the same job in the invoice, the approval, the on-charge and the report. There is no reconciliation step because there was never a second copy.

It is a product, not a project. Built on tested patterns, deployed in two to four weeks for the first module, configured to your operations and operated alongside your team. Your subdomain. Your data. Your model choice. Hosted on infrastructure you control.

Why we built it

Every business we work with has the same problem. The operational data lives in 10 to 30 different systems. The CRM knows the deals. The ticketing system knows the issues. The shared drive knows the contracts. The ERP knows the invoices. Nobody knows all of it at once because no one person can hold that many tabs open.

ChatGPT and Copilot are general assistants. They do not know your customers, your contracts, your operational history, or who has access to what. They are useful for general drafting. They are useless for "what is the status of the McKinnon contract" or "who in the team has touched the Carraway account this quarter".

Internal dashboards and analytics tools sort of help, but the team has to know which dashboard to open, what filter to apply, and what the column names mean. Most staff give up and ping an analyst on chat. The analyst becomes the bottleneck.

Bedstone OS removes that bottleneck by moving the work into one place rather than adding a fifteenth system that reports on the other fourteen. Because each module writes to the same registry, the operating picture assembles itself as the work is done, and the ask layer over the top can answer a question from it directly, grounded in the access the person asking already has, with the source records linked. Non-technical staff get straight at operational data without learning a dashboard.

The modules

You do not buy Bedstone OS whole and wait. You turn on the function that hurts most, prove it, and extend along the same spine.

Accounts. Live in production today. Supplier invoices read and coded to the right entity, job and account with a confidence score per field. Invoices raised and recoverable costs on-charged. Receivables aged and chased on a cadence. A defence-in-depth check on every party you pay before money moves, so nothing is paid on the strength of a document looking right. See AI accounts for the detail.
Entities and jobs. The registry everything else derives from. Your group entities and their real jobs in one place, so nothing can be coded to a job that does not exist in the entity being billed.
Suppliers and creditors. Keyed by ABN rather than by a name someone typed, with licence, insurance and expiry tracking, duplicate detection, and enough history that a changed bank account is visible instead of invisible.
Approvals. Routing by amount, department and entity, with who approved what and when recorded against every decision. The system tracks the chain; it does not decide it.
Intake and documents. A shared mailbox and a document store that feed the modules directly, so work starts from what arrived rather than from someone filing it first.
Reporting. Live position by entity, job and account, built from the coded data as it is created rather than reconstructed at month end.
The rest, on the same pattern. Sales, support, people, assets. Each one a module on the same registry, scoped and built the way accounts was. We build the one that hurts most first.

Asking across all of it

One component of the portal is the ask layer. Because every module writes to the same registry, there is finally something worth asking a question of: not one system at a time, but the whole operating picture at once.

Plain-language questions across everything. “Which jobs have gone over on labour this month, and which of those are recoverable.” Answered from the coded data, not from an export someone made last week.
Cross-module synthesis. “Give me the full position on this supplier.” Spend, open invoices, approval history, ABN and bank-detail status, and which jobs they have touched, returned as one brief.
Grounded, with sources attached. Every answer links the underlying records, and anything that cannot be sourced is flagged rather than filled in. That is the difference between an answer you can act on and one you have to go and check.
Identity-aware. The answer respects what the person asking is already allowed to see. Asking a question is not a route around a permission.
Logged. Every question and every answer recorded, so a compliance review can see who asked what and what came back.

The ask layer is a component, not the product. A business that only wanted a chat box over its files would be better served buying one off the shelf. What makes the question worth asking here is that the portal did the work in the first place, so there is something true underneath to read.

Systems it connects to

Whatever your business actually runs. We do not publish a supported-vendor list, because the honest answer is that the category matters and the brand does not:

Your customer and sales systems. Whatever holds the pipeline, the accounts and the history.
Your finance and accounting platform. The ledger, the payables, the receivables, whatever you post to.
Your operational systems. Jobs, projects, work orders, rosters, scheduling, inventory. The line of business applications your team lives in all day.
Your documents. Cloud document stores, on-premise file shares, contract libraries, internal wikis.
Your service and support desk. Tickets, queues, escalations, customer correspondence.
Your communication channels. Chat, shared inboxes, notification channels, with permission.
Your reporting layer. Data warehouses, business intelligence tools, and the databases underneath them, with read-only scoped access.
Your bespoke systems. The internal application somebody built years ago that runs a critical part of the business and has no vendor behind it. These are usually the ones that matter most and the ones every off-the-shelf product ignores.
On-premise sources. Connected over a private link where the data must stay inside your network.

If it has an API, we connect to it. If it does not, we work out the right read pattern instead, whether that is a scheduled sync, a file drop or supervised database access. On premise or in the cloud, current or ancient, vendor-supported or long abandoned. Tell us what you run and we will tell you plainly how it connects.

What makes it defensible

Built on patterns proven in client engagements over the last three years. What matters is not the parts list, it is what you can rely on:

Answers are grounded, with sources attached. Every answer links the records it came from, and anything that cannot be sourced is flagged rather than filled in. That is the difference between something you can act on and something you have to go and check.
Identity-aware end to end. Every request carries the identity of the person making it, and nothing is ever returned that the person could not already reach in the source system. Asking a question is not a route around a permission.
Actions are scoped, logged and reversible where the source system allows it. When the portal does something on your behalf it does it as you, within your permissions, and it is recorded.
Everything is logged. Every query, every action, every record touched. Surfaced to your security and compliance people rather than buried.
Data stays current without anyone maintaining it. Each connected system refreshes on a cadence appropriate to how fast it actually changes, so the answer reflects today rather than last week.
Measured, not asserted. Accuracy, latency, how often answers are properly sourced and what it costs are all tracked and visible to your team. If it degrades you will see it before your staff do.
Hosted in your environment, in your region. Your account, your data, your control.

The internals are ours and we do not publish them. Under NDA we will take your infosec, procurement or engineering team through the architecture and the data flow in full.

Model and provider choice

The right reasoning layer depends on your data sensitivity, your compliance posture and your budget. Bedstone OS treats that as configuration, not architecture:

Commercial models, AU-region routed. The sensible default for general workloads. We build on the leading foundation models and layer our own system over them, routed through Australian regions so data does not leave the country without an explicit decision.
Open-weight models on your own infrastructure. For workloads that cannot send data to a third party at all, the reasoning layer runs inside your own environment. Nothing leaves your network.
Mixed deployment. Sensitive work on models in your own environment, everything else on commercial endpoints, with routing tied to data classification rather than to a blanket policy.
No lock-in, by design. Model choice is a setting. Switching takes hours, not weeks, which means you are never exposed to one provider’s pricing, availability or terms.

We stay deliberately model-agnostic and keep the exact mix under the hood. The model is the commodity part of this. The registry, the coding engine, the verification checks and the controls above them are ours, and they are what actually produces the result. Under NDA we will walk your infosec or procurement team through the full architecture and data flow.

Access control and identity

Access control is the most important thing the Hub gets right. A salesperson should see their pipeline. The CFO should see ledger data. HR should see employee records. None of them should see things their existing role does not permit.

SSO integration. The Hub authenticates against your existing identity provider (whatever directory you already run). No separate password.
Role inheritance. Each user's role and permissions come from the source systems. The Hub respects them.
Per-system scope. Where a user has limited access in a source system, the Hub queries with their scope, not a service account that sees everything.
Document-level access. For document stores with per-file permissions, the Hub only returns documents the requesting user has read access to.
Field-level redaction. Sensitive fields (salary, PII, financial details) can be redacted based on the requesting user's role.
Audit logging. Every query, every retrieval, every action logged with user identity. Tied to your existing SIEM if you have one.
Conditional access. MFA enforcement, device compliance, IP restrictions, all inherited from your identity provider's conditional access policies.

How we deploy it

Bedstone OS is not SaaS. We deploy it into your environment, on your terms.

Your cloud account. AWS, Azure, or GCP, in the AU region of your choice. We deploy the infrastructure as code, document it, and hand back keys.
Your subdomain. ai.yourcompany.com.au, or whatever fits your brand. DNS, TLS, and routing configured.
Your data, your account. All data stored in your cloud account. No vendor lock-in on the data layer. Backups in your account.
Your model accounts. Where commercial model endpoints are used, the accounts are held in your name. The Hub is configured to use them.
On-premise variant. For organisations that cannot run in public cloud, the Hub deploys on-premise on your own infrastructure. Same architecture, your hardware.
IRAP / sovereign variant. For workloads requiring IRAP-assessed infrastructure or sovereign cloud, we deploy to the appropriate sovereign environment.

What week one looks like

Most Hub deployments run for two to four weeks for the first usable version. The first week sets up the rest.

Day 1. Discovery and scope. Which systems first. Which team uses it first. What questions they need to answer. Access requirements mapped.
Day 2. Identity integration. SSO configured against your identity provider. Test users provisioned. MFA enforcement validated.
Day 3. First system connection. Pick the most valuable system (usually CRM or document store) and wire up the connector. Read-only, scoped, identity-aware.
Day 4. First end-to-end query. Internal test users issue real queries against real data. Citations validated. Access scoping tested.
Day 5. Pilot user onboarding. Small group of pilot users access the Hub at the agreed subdomain. Feedback captured. Refinements scheduled.

Bedstone OS vs alternatives

Option	Best for	Trade-off
ChatGPT Enterprise / Microsoft Copilot	General drafting, productivity assistance, internal document Q&A inside one productivity suite.	Cannot see your CRM, ERP, ticketing, or custom systems. Hosted in vendor regions, not yours.
Glean, Notion AI Q&A, enterprise search	Better than ChatGPT for internal search across documents.	Often limited on operational workflows (CRM, ERP, ticketing). Hosted SaaS with the vendor's data residency model.
Build it yourself	You have a senior AI engineering team and want full ownership end-to-end.	Six to twelve month build plus an operational tail of model upgrades, retrieval tuning, access control. Wasteful without an in-house team.
Per-system AI (Salesforce Einstein, Copilot for Dynamics, etc.)	Vendor-specific augmentation inside a single tool.	Each only sees its own data. The salesperson still context-switches across five tools. No cross-system synthesis.
Bedstone OS	Unified internal AI workspace without the build cost. Your cloud, your region, your subdomain. Connects every system.	Not pure off-the-shelf SaaS. Requires deployment into your account (which is also the point).

Common use cases

Sales. "Show me at-risk accounts. Draft a renewal email for each. Summarise the last six months of activity on this account before my call." Pulled from CRM, communication, and document data.
Customer success. "What is the open ticket queue for this customer. What is their contract renewal date. Have they been escalated in the last quarter." Pulled from ticketing, contracts, and account data.
Operations. "What invoices are overdue more than 30 days. Which customers have the largest exposure. Generate the dunning email batch." Pulled from accounting and CRM.
Finance. "Reconcile this bank statement against the ledger. Show me the unallocated payments. Draft the monthly board pack with the variance commentary." Pulled from accounting, banking, and historical board packs.
Legal. "Find every contract with a termination clause shorter than 60 days. Pull the renewal dates. Flag the ones expiring this quarter." Pulled from document store with contract metadata.
Engineering. "What is the on-call queue. What was the last incident. Find every place the legacy auth library is still used in the codebase." Pulled from PagerDuty, incident tooling, and code repositories.
HR. "Find every employee due for a performance review this month. Pull the templates. Summarise the last review for each." Pulled from HRIS and document store, with HR-only access.
Executive. "Brief me on the top three customer issues this week. Pull the revenue impact. Summarise the actions team has taken." Pulled across CRM, ticketing, and finance.

Data residency and compliance

Data residency matters for AU businesses, and Bedstone OS is designed for it.

AU-region by default. Vector store, retrieval cache, application logs, audit trail all live in AU. No data crosses borders without explicit configuration.
Model provider routing. Where commercial model endpoints are used, we route to Australian regions wherever the provider offers them. For workloads that cannot send data offshore, we deploy open-weight models in your VPC.
Privacy Act and OAIC. Data handling aligned to APP obligations. Breach notification process documented.
Sector frameworks. APRA CPS 234 for regulated financial entities, ACSC Essential Eight, sector-specific obligations. Configured per engagement.
IRAP. Where the deployment supports government workloads, deployed to IRAP-assessed environments.
SOC 2 and ISO 27001. Hub deployments produce the evidence trail your auditor expects.
Data deletion. When a record is deleted in the source system, it is removed from the Hub retrieval index within minutes.
No training on your data. Commercial LLM providers configured with the appropriate enterprise terms so your data is not used for model training.

How we structure engagements

Bedstone OS is sold as a deployment plus operate engagement, not as SaaS subscription. Common shapes:

Foundation deployment. First three to five systems connected, single department use case, two to four week deployment. Fixed scope, fixed timeline.
Broad rollout. Connect remaining systems and roll out across the business. Sequenced engagement over four to twelve weeks.
Operate retainer. Monthly engagement to add new integrations, tune retrieval, update model configuration, respond to user feedback. Recommended for the first six months of usage.
Infrastructure-only. For organisations with internal AI engineering capability, we deploy the infrastructure and hand over. Less common.

Bedstone OS deployments commonly qualify for the R&D Tax Incentive given the novel integration work and AI engineering involved. Reach out and we will reply within 24 hours with the shape and pricing that fits your situation.

Common questions

What is Bedstone OS?

Bedstone OS is your business portal, deployed privately at your own subdomain (for example ai.yourcompany.com.au). Each business function runs as a module on one shared registry of your entities, jobs, suppliers, people and permissions. Accounts is in production today; entities and jobs, suppliers, approvals, document intake and reporting sit alongside it. It is where the work is done rather than a layer reporting on work done elsewhere, and an ask layer over the top answers plain-language questions from the same data with the source records attached.

How is it different from ChatGPT or Copilot?

They are general assistants that answer questions. Bedstone OS is where the work happens. Your team codes an invoice, routes an approval, verifies a supplier and raises an on-charge inside it, and because all of that lands in one shared registry there is a complete operating picture to ask questions of afterwards. A general assistant has no access to your systems, no permissions model, and nothing of yours to be grounded in. It is not really assistant against assistant; it is an assistant against a system of work.

Where does the data live?

By default, AU-region cloud (AWS ap-southeast-2, Azure Australia East, or GCP australia-southeast1). Your data does not leave Australia without explicit configuration. For IRAP or sovereign workloads we deploy to appropriate sovereign environments.

Which LLM does it use?

It is model-agnostic by design, and that is a deliberate commercial decision rather than a technical hedge: you are never tied to one provider and we can route to whatever performs best on your work without you changing anything. We build on the leading foundation models and layer our own system over them. For workloads where data cannot leave your environment at all, the reasoning layer runs on open-weight models on your own infrastructure. The model is the commodity part; the registry, the coding engine and the controls above it are ours, and they are what you are actually buying.

Which business systems can it connect to?

The categories rather than a brand list: customer and sales systems, finance and accounting, operational systems like jobs, projects, work orders, rostering and inventory, document stores and wikis, service desks, communication channels, data warehouses and the databases underneath them, and the bespoke internal applications that have no vendor behind them. On premise or in the cloud. If it has an API we connect to it; if it does not, we work out the right read pattern. We do not publish a supported-vendor list because the category is what matters, not the brand.

Who can see what data?

Access controls inherit from your existing identity model. A salesperson sees the deals they own, not someone else's pipeline. Finance sees ledger data, not HR records. The Hub never surfaces data the requesting user could not access in the source system.

Does it work for non-technical staff?

Yes, and it is a design constraint rather than a hope. The modules are built around the task a person is doing, not around the data model underneath, and the ask layer takes plain-language questions with no query syntax and returns answers with the source records linked. The point is to give non-technical staff direct access to data that previously needed an analyst.

How long does deployment take?

First version live in two to four weeks for a focused scope (three to five systems connected, single department use case). Broader rollout across the business follows in four to twelve weeks depending on system count and access integration.