A governed knowledge layer
One maintained source of the documents, policies and data that AI is allowed to draw on, with ownership, review dates and access rules that match your existing information governance.
AI Services
One operating layer, not fourteen disconnected tools
An AI operating system is the shared infrastructure a team works through: the knowledge it draws on, the agents it can run, the standards it holds to, the permissions that constrain it and the record of what happened. It is what turns scattered AI use into an organisational capability.
The symptom
Every team has invented its own AI
Individually rational, collectively expensive. This is what it looks like from the top.
- The same knowledge re-uploaded into six different tools, each version ageing differently
- No shared library of what works, so every team pays the learning cost again
- No way to answer "what did the AI do last month, and on whose authority?"
- Access granted per tool, so leavers keep access and joiners wait a fortnight
- Leadership cannot see usage, cost or benefit in one place
What it consists of
Six components, assembled to fit you
Not a product we resell - an architecture we assemble from your existing platform plus the parts that are missing.
An agent and assistant catalogue
The approved set of assistants and agents, each with a stated purpose, owner, data scope and review date - so teams adopt from a catalogue instead of building shadow tools.
Standards and guardrails
The house rules made operational: what must be checked by a human, what may never be sent to an external model, how outputs are cited and stored.
Identity and permissions
Access driven by your existing directory and role model, so joining, moving and leaving work the way they already do for everything else.
Audit and evidence
A durable record of runs, inputs, outputs, approvals and overrides - the artefact that makes assurance, incident review and regulatory questions answerable.
The leadership view
Usage, cost, time recovered and exception rates in one place, broken down by team, so investment decisions rest on data.
In practice
What working with us looks like
The engagement runs with the people who do the work, not around them. Sessions are short, scheduled around delivery, and every stage ends with something you can act on.
You get a named consultant for the whole engagement - the person in the room is the person doing the work.
How it is built
Assembled in stages, useful from the first one
1
Map what exists
Current tools, licences, identity model, information governance and the teams' actual habits. Most organisations own more of this than they realise.
- Existing platform capability assessed first
- Duplicate spend identified and recovered where possible
2
Design the layer
Architecture, permission model, knowledge ownership and the standards that will be enforced rather than merely published.
- Designed against your existing IG and security policy
- Sign-off from IT, security and the business together
3
Build the first slice
One department, real work, the full stack - knowledge, agents, standards, audit and reporting - so the model is proven before it is scaled.
- A working department-level system in weeks
- Adoption measured, not assumed
4
Extend and hand over
Additional teams onboarded to the same layer, with your own people trained to own it.
- Runbooks and an internal owner in place
- A catalogue your teams extend themselves
Deliverables
What you leave with
What you end up with
- A single governed knowledge layer with named owners
- A catalogue of approved assistants and agents
- Enforced standards and guardrails, not just a policy PDF
- Role-based access wired to your existing directory
- Complete audit trail of AI activity
- Leadership dashboard: usage, cost, time recovered, exceptions
- Internal ownership, documentation and training
Who this is for
Organisations past the pilot stage, where several teams are using AI daily and the lack of shared infrastructure has become the constraint.
It is usually the wrong first purchase. If you have not yet proven value in one workflow, start with augmentation or an audit - an operating system built around unproven habits will simply industrialise them.
Size is less relevant than spread. A 60-person firm with AI in five teams needs this more than a 500-person one where it lives in a single department.
Work we can name
CedarGuard: an operating system, not a chatbot
CedarGuard is a risk and compliance operating system for UK social housing delivery, built to the point where it is a live product at cedarguard.co.uk rather than a pilot that ended at a demo.
One application, one sign-in, and the same data at three tiers - project, programme and portfolio - with records created where the work happens and aggregating upwards. That is the shape an AI operating system actually takes.
What it does
- Matches statutory obligations to the project from a maintained regulations library
- Generates a first-pass risk register for a named owner to accept or reject
- Quantifies exposure as gross and residual Annual Loss Expectancy, in pounds
- Tracks every risk against the organisation's stated risk appetite
- Keeps an evidence trail built for the moment a regulator asks
- Refuses to publish a project until a person has completed and confirmed setup
Where this fits
Related services and sectors
Questions
Questions about ai operating systems
No. It is an architecture we assemble, mostly from platforms you already own - your Microsoft or Google tenancy, your identity provider, your document store - plus the components that are genuinely missing. There is no CedarPro licence fee.
It extends it rather than sitting beside it. Access follows your directory, information governance rules carry over, and the audit trail is designed to be readable by the people who already run your assurance processes.
That is the recommended route. One department, the full stack, proven and measured - then extend. Organisation-wide first builds are how these programmes stall.
The layer is provider-agnostic by design. Models sit behind an interface, so changing provider is a configuration change and an evaluation run, not a rebuild.
See what you already own
The audit maps your current tools, spend and permissions - the honest starting point for an operating layer.