SenangAI — your data, your infrastructure, your control
Home · Platform
Sovereign AI · the platform

The sovereign AI platform, stage by stage.

The platform is organised as five capabilities — connect, understand, build, govern, scale. Each is something you can inspect in an evaluation. They are not a gated install sequence, and they are not a claim that every organisation needs all five on day one.

Every request, in orderNo exceptions
IdentityWho is asking
ScopeWhat they may see — checked first
BudgetWhat it may cost — enforced live
ApprovalA person, before anything leaves
Cited answer delivered
There is no ungoverned path through the product
01 · Connect

Approved sources, with their permissions intact.

Connecting a source does not flatten it. SenangAI reads the permissions that already exist in the system of record and carries them through, so a document restricted to the legal team stays restricted here. You decide which sources are approved; anything not connected is simply absent rather than half-available.

Permissions read from the source, not reimplemented
Sources come online in the order your rollout needs
Scope evaluated before retrieval, never as an output filter
Unconnected sources cannot be reached by any agent
Connect · sourcesPermission preserved
SourcesPermission read from origin
Contract archiveLegal only
Finance driveFinance only
Company handbookEveryone
Board papersNot connected
Scope gate — evaluated before retrieval
02 · Understand

Organisational memory, built as a knowledge graph.

Your knowledge becomes a living map of nodes and edges — people, projects, decisions, contracts and obligations, connected as they actually relate. That is why “why” and “who decided” have answers here: the connection is the answer, and it arrives with its sources. It finds meaning, not just matching words, and it speaks in your organisation’s own terms — which is also why agents act reliably here: they work from how your business actually connects, not from loose text.

Questions that span sources resolve as one answer
Every answer traceable to its source and version
“Why” and “who decided” are answerable, with proof
Delete a document and everything derived from it goes too
Understand · memoryGraph view
Organisational memoryNodes · edges · answers
Project AtlasDecisionContractOwnerInvoicePolicyVendorMinutesRisk logTeamBudget
Ask “why” and the path is the answer
03 · Build

Agents, workflows and automation — built, not coded.

Skills compose into agents; agents and approval steps compose into workflows; workflows on triggers and schedules become automation. All of it is assembled by the person who understands the work rather than the person who can write code — and all of it is created paused, inside the scope of the space it lives in.

Agents, workflows and scheduled automation, no code required
A personal agent for every person; unlimited per teamspace
Human approval steps anywhere a consequence begins
Nothing can exceed the scope of the space it lives in
Build · agent composerPaused
Legal teamspace4 agents · add more anytime
Read a documentCompare to playbookDraft a summaryNotify a personGenerate a file
Contract ReviewerBorn paused
Read a document
Compare to playbook
Add a skill
Inherits the scope of its teamspace
NDA TriageRenewal WatchClause Finder+ new agent
04 · Govern

One console for models, budgets, scopes and evidence.

You register which models are permitted to run, and nothing else runs — not as a fallback, not under load. Within that set, routing keeps cost down automatically, and every choice is recorded. Budgets are enforced at organisation and person level rather than reported after the fact, and the audit trail is produced as work happens.

Approved model registry, enforced at request time
Budgets enforced automatically at two levels
Cost visible and attributable, per request
Audit records exportable for internal or external review
Govern · admin consolePolicy active
Approved model registryNothing else runs
Open-weight 70BOn-premisesPermitted
Regional APISovereign regionPermitted
Public consumer APIExternalBlocked by policy
Organisation budget62%
EnforcementAutomatic
05 · Scale

The same controls, wherever you run it.

Sovereignty follows governance. On-premises, private cloud and hosted deployments share one control model, so the boundaries you designed during an evaluation do not have to be redesigned when you move. The knowledge layer moves with you; it is not rebuilt.

Identical scope, approval, audit and budget behaviour
Open-weight models inside your own perimeter
Retrieval stays local in every mode
Knowledge layer is portable between deployments
Scale · deploymentPortable controls
DeploymentSame controls, every perimeter
HostedManaged · tenant isolated
Private cloudYour tenancy or a sovereign region
On-premisesYour own perimeter
One control model — scopes, approvals, audit, budgets
Where it sits

The missing layer is knowledge, not compute.

Sovereign compute and sovereign models already exist. Institutional applications stay blocked until knowledge is governed — scoped, cited, approvable and auditable. That layer is SenangAI. Custom skills live on it: written procedures, authored by the people who own the work, so an agent follows a process rather than inventing one.

Compute and models are available; the knowledge layer is not
Custom skills are instruction sheets, not code
Institutional apps become possible only once this layer exists
The stackWhere SenangAI sits
01Sovereign computeBuilt
02Sovereign modelsBuilt
03 Governed knowledge layer ← Us
Custom skillsA written procedure — how the work should be done
04Institutional AI appsBlocked
What it produces

Four outcomes, continuously.

These are not features to switch on. They are what the five stages produce once the platform is running, and what disappears the moment an ungoverned tool is introduced beside it.

Controlled knowledge flowApproved sources in, permitted answers out.
Work orchestrationAgents and workflows that stop for a person.
Continuous governance evidenceEvidence produced as work happens.
Measurable impactQuestions, citations and spend, visible.
Connect

Everything you already work in.

Documents, drives, intranets, mailboxes, chat, wikis, databases, services and repositories — one governed intake for all of it, so knowledge arrives with its permissions rather than despite them.

One intake, every ecosystem

Documents, cloud drives, productivity suites, mail, chat, wikis, databases, code and the public web — plus a custom route for anything with an interface.

If your teams use it, it can feed the platform.

Permissions inherited, then enforced

The permissions that exist in the source system carry through, and scope is checked before every answer. Connecting a source never widens who can see what it holds.

Connect without expanding access.

Always in step with the source

When content or permissions change in the source system, the change follows here. And every answer cites the exact version it drew on — so you can see, rather than assume, that nothing is stale.

Freshness you can verify.
Documents & filesPDFs, Office, text
Cloud drivesShared folders
Intranets & portalsInternal sites
Productivity suitesDocs, sheets, slides
EmailMailboxes
Chat & messagingTeam channels
Wikis & knowledgeInternal knowledge
DatabasesStructured data
APIs & servicesInternal systems
Code repositoriesEngineering
Web contentPublic sources
Webhooks & customAnything else

Not listed is not a no. The connector framework is open — internal systems, databases and APIs join through the same governed intake, scoped during the evaluation.

Do connectors preserve our permissions?

Yes. Permissions are inherited from the source system and enforced before an answer is produced — not filtered afterwards. Connecting a source never widens who can access what it holds.

Does connecting a source mean everyone can see it?

No. A connected source is available only within the scopes you map it to. Personal and teamspace boundaries apply on top, so the same platform answers differently depending on who is asking.

What happens when a source changes?

The platform follows the source of record, including permission changes. Every answer cites the version it used, and deleting a document removes everything connected to it.

What if our system is not listed?

Ask. The framework is open, and internal databases, services and custom sources join through the same governed intake — scoped and agreed during the evaluation, before you commit to anything.

Start with one governed use case

Bring the question your organisation keeps arguing about.

Thirty minutes. We will map one use case, demonstrate scope isolation, and show the audit evidence the platform produces — or tell you plainly that you do not need us yet.