AI Workspace
one private place where your whole company works with AI
A product, not a project
The difference shows up after we leave, which is the only place it matters.
AI Workspace is a single private place where everyone in an organisation works with AI - your documents, your systems, your teams and whichever models you allow - running on your own infrastructure rather than someone else's.
It is a product in the sense that decides how you buy it: the same system arrives each time, already built, rather than a bespoke platform assembled from scratch and priced by the month while you wait for it. What differs between two deployments is the configuration and the connections into your own systems - which is where the work is, and where the value is.
It also does not finish when we do. An engagement closes; a system your staff open every morning does not, and that is why the rest of this page spends as long on what is hard about running one as on what it does.
The problem it exists for
Consolidation, not capability. That is the whole product.
Every new AI tool arrived as another place to go and ask, and the answer got harder to find, not easier.
Knowledge sits in separate repositories, each with its own search behaviour and its own permission model. AI tooling arrived as more separate destinations rather than fewer, so every additional access point made an answer harder to find. And none of it could be governed as a single thing - access control, retention and auditability were as fragmented as the content.
That fragmentation is self-reinforcing. Each new tool is easier to add than to integrate, so the rational local decision worsens the global problem - and the cost never appears on any individual tool's business case.
Which is why one more capable assistant, added to an estate in that condition, makes it marginally worse rather than better. Recognising that determined the shape of the whole build: an environment that hosts many assistants under one set of rules, rather than one more application with its own log-in, its own permissions and its own idea of who you are.
Four repositories with four front doors, replaced by one governed workspace
After
One governed workspace
Data · search · models · agents
One place to set access
Before: separate repositories, each with its own search behaviour, its own permissions and its own front door. Every tool added made an answer harder to find, not easier.
After: a single workspace, which is also the only unit at which access and governance can realistically be applied.
What is in it
A product that cannot be described feature by feature is a slide, not a product.
Four groups. The first is what your people see every day. The second is what it knows. The third is what it can actually do to a system rather than say about one. The fourth is the group your CIO, your finance director and your risk committee will ask about, and it is the group most offers cannot answer.
A place the team works together, not a chat window each
Almost every competing offer is a private assistant: one person, one window, and an answer nobody else ever sees. The difference here is organisational rather than technical, and it is the one people notice first.
- Shared spaces
- A space per team, project or process, where colleagues and assistants are in the same conversation. One person asks, and the answer is produced in front of everyone who needs it.
- The assistant answers when it is called
- Nothing replies until someone addresses it by name, so a shared space does not fill with machine chatter. Present when wanted, silent otherwise.
- More than one assistant in the same thread
- One drafts the response to a tender clause, another checks it against the contract, in front of the people who have to sign it off.
- The conversation becomes the record
- Those spaces stay searchable, and the assistants can search them. The answer someone was given three weeks ago is found rather than asked for again.
- Private work as well
- Personal conversations, direct messages between two people, and working notes that can be attached to any conversation as context.
- Work that runs without being asked
- A check that runs every Monday, a summary that arrives before the meeting, a watch on a queue that reports only when something moves.
It answers from your own material, and only what each person may see
The second half of that sentence is the one a security review actually tests, and it is where most consolidation projects fail: an index that ignores the source systems' own rules will happily hand someone a document they were never entitled to open.
- Your documents, including the scanned ones
- Contracts, drawings, spreadsheets, procedures and correspondence, in the formats they are actually kept in - including paper that was scanned and never typed up.
- Found by number or by description
- Searching an exact contract reference and describing the problem in your own words both work, because both methods run and the results are ranked together. Either one alone misses.
- It reads across the set, not the first hit
- It opens several documents, compares them and answers from what it finds, rather than quoting the first passage that looked relevant.
- Permission checked per person, per file
- A shared assistant with a document set attached does not become a shared document set. Every lookup re-checks whether this person may see this file, and silently leaves out what they may not.
- Every answer shows its sources
- With the document and the passage it came from, so a reader can check it rather than trust it.
- Kept current on its own
- A connected repository re-reads only what changed, so the workspace does not quietly become a snapshot of the day it was installed.
It does the work, not only describes it
A workspace that only reads documents answers questions. This one also reaches the systems the answer lives in - the system of record, the request queue, the document store - and writes back where it is permitted to. That is the part we build, and it is the part that is genuinely yours alone.
- Assistants built for one job
- Instructions, documents and permissions packaged together and published to the team that does that job - a tender reviewer, an invoice checker - instead of one general assistant everybody has to learn to prompt.
- Your method, written once
- The steps, the order of checks and the house rules held in the workspace and applied the same way by everyone, rather than living in the head of whoever has done it longest.
- Connections into your own systems
- Reading a record, raising a request, filing a document, checking a balance. Credentials stay inside the connection - the assistant is given the ability, never the keys.
- Nothing is written back without a person
- An action that changes something waits on a named approver. The workspace proposes; your staff commit. Which of your actions need that is your decision, set once.
- Rules that run on every message
- Remove this before it leaves, add that to the record, never allow the other. Set centrally and applied to everything, rather than configured per tool by whoever installed it.
- The next connection is not a new project
- New systems attach to a standard interface the workspace already speaks, so the second integration costs a fraction of the first.
The parts your CIO, your finance director and your risk committee ask about
None of these is possible until everything goes through one place, which is the real argument for consolidating. Each of them is also a question that gets asked in the second year, when the pilot enthusiasm has been replaced by a renewal.
- Model and data permissions per person or per team
- Each assistant, each document set, each shared space and each connection is granted separately, to named people or named groups. People sign in the way they already sign in, and a leaver loses access when HR processes the leaver rather than when somebody remembers.
- Which model answers is a setting, not a commitment
- Everything reaches the models through one layer, so work that cannot leave your boundary is answered inside it and the rest goes wherever is best, without anyone choosing per question. When a provider is slow, withdrawn or simply beaten - and one of them will be, inside a year - it is changed behind the workspace and nothing anyone uses changes with it.
- It keeps working when a provider does not
- A slow or failing provider is taken out of rotation and the request is served elsewhere. Your staff notice nothing, which is the only acceptable version of that event.
- What AI cost last month, by department
- Every request carries who made it and which model answered, so spend is attributable instead of arriving as one line on a card statement. A department can be given a limit that stops, and a warning before it does. Most organisations cannot answer that question at all.
- Sensitive material caught before it leaves
- Personal data, credentials and whatever your regulator counts as restricted are detected on the way out and masked in what gets stored - so the cost record survives and the content does not.
- A record of what happened, kept as long as you say
- Administrative changes on an audit trail with a retention period you set, usage visible by team and by assistant, and a side-by-side comparison when a model is changed - so the change is evidenced rather than asserted.
All of that is in the product today; none of it is a roadmap. What a given deployment switches on, and what it deliberately leaves off, is a decision taken with you during commissioning - an organisation that does not want its staff generating images at work simply does not get that button.
Our own operating benchmark
We built this for ourselves, we run it, and these are our numbers. Never a client result.
The requirement was set by the people who would live with the result rather than by a procurement specification, and the test applied was whether employees actually stopped visiting the other destinations - a harder bar than an adoption metric. Stating it as our own deployment is the stronger claim, not the weaker one: it means we run what we sell, and it is checkable.
| Measure | Before | After |
|---|---|---|
| Average knowledge-discovery time for indexed enterprise content | ~12 minutes | under 90 seconds |
| Common internal questions answered or routed to the correct source without a further repository search | not measured | more than 70% |
| Separate access points for knowledge, search, and AI tools replaced by a single workspace | not measured | at least 3 |
Figures are drawn from the practice's own delivery records for the engagement named, measured against the process that preceded it. They have not been through third-party audit, and none is presented as an average across clients.
This benchmark is a speed claim and it stands on its own. The answer is known to exist; the problem is finding it faster across too many places to look. That is a different problem from the Semantic Search service line, whose proof is recall and precision - surfacing an answer that would never have been found, or catching one that would have been confidently wrong. The two are related and they are not the same, and a client buying this product's speed benefit is not automatically buying that line's recall benefit.
The hard part, said openly
Any vendor presenting consolidation as a connector exercise has not done it.
- Access boundaries are the hardest part and the least negotiable.
- Consolidating repositories means consolidating permission models that are rarely consistent with one another, and an index that ignores those differences will surface content to someone entitled to see the repository but not the document. Where a source system's own rules are already wrong, consolidation makes the wrongness visible and portable, and fixing it is part of the deployment. This is the work, and it is the part that takes longest.
- Extensibility competes with coherence.
- An environment open enough to host new assistants easily is one where each assistant can present its own interface and vocabulary, reintroducing fragmentation inside the very workspace built to remove it. Common access, retrieval and interaction patterns have to be imposed rather than left to each one to define - which is a governance decision disguised as an architecture decision.
Entitled to the repository is not the same as entitled to the file
Only the overlap may be indexed for a given reader. The gap is the work.
How you get it, and where it runs
Four things, all of them on your side of the boundary.
There is no tenancy of ours to sign up to, because there is no tenancy of ours. The workspace runs on your infrastructure - on your premises, in a sovereign region, or in your own cloud account - and what we sell is the work of putting it there and making it yours.
Standing the environment up on the infrastructure you already run, sized for the number of people who will use it and able to grow by adding machines rather than by replacing them.
Sign-on against your directory, the permission model mapped onto the groups you already have, which models are allowed and which work stays inside the boundary, the budgets and the cost centres, the guardrails, and where the record is kept and for how long.
Connecting your repositories, tuning retrieval against your own content rather than a demonstration set, building the first assistants with the teams who will use them, and training your administrators to run it without us.
The connections into your systems of record and the steps the workspace performs inside them. This is the bespoke part, it is where most of the value is, and it is the reason two deployments of the same product do not do the same work.
We do not resell anything. Any licence you choose to hold sits in your name, next to your infrastructure and your own model contracts - so no margin of ours is buried inside your licensing, and you can change supplier without changing platform. If you want the workspace to carry your branding rather than anyone else's, that is your decision and your licence to hold.
Six of 12 competitor sites raise data sovereignty, which makes it table stakes in the Gulf rather than an advantage: failing to offer it loses deals and offering it wins none. It is stated here because its absence would be noticed, not because it is a reason to choose us.
One thing this page deliberately does not give you: a service level. What support and upgrades look like after commissioning is agreed per deployment, because an air-gapped site and a cloud account are not the same arrangement and a number that covered both would be true of neither.
Start here
Tell us how many places your people look, and we will tell you which of the two you need.
A speed problem and a recall problem look identical from the outside and need different answers. That distinction is a twenty-minute conversation, not a proposal.
You get a reply within one working day, from the engineer who would do the work - not a sales sequence.