Deskwise launches the AI workforce platform
A typed, tenant-isolated model of your organisation, an action layer every state change passes through, and an AI workforce that operates inside both.
A typed model, one path for every change, and a workforce that runs inside both.
Today, Deskwise announced the general availability of its ontology and action layer: a typed model of an organisation, a single governed path for every change made to it, and an AI workforce that operates inside both.
The model is not a schema diagram. Object types carry typed properties and a PII class; links are typed with declared cardinality and inverse names; actions are first-class definitions with an input schema, a precondition expression, a risk tier, and a handler. Existing systems of record are exposed as read-through projections — a read compiles to SQL against the native table and rows are never copied — so there is no ETL to maintain, no sync to fall behind, and no second copy of the truth to reconcile.
Isolation is enforced by the database rather than by application code. Every table has row-level security enabled and forced, with the policy keyed on a tenant set per transaction. The application never writes a tenant filter, because a scoping rule living in application code is one refactor away from being dropped. A cross-tenant probe returns zero rows and is indistinguishable from a record that was never there.
Every state change runs the same pipeline: resolve, replay if the idempotency key has been seen, validate against the input schema, apply the approval gate, evaluate the precondition against live state, snapshot, execute, snapshot again. Each terminal outcome writes exactly one invocation row — including denials, invalid inputs, and precondition failures — so what was refused is as auditable as what ran. A role by risk-tier matrix decides who may invoke what, financial and health properties are masked from agents by default, and two kill switches stop every agent invocation while the underlying business keeps running.
Derived data carries its lineage: the job and version that produced it, a digest of the input partitions, and references to the objects behind the figure. Identical inputs yield an identical digest, so re-running a job returns the prior result rather than recomputing it, and any number on any surface can be traced back to the records underneath. The invocation ledger doubles as the usage record — actions can carry a SKU and be entitlement-gated, with no parallel counter to drift out of sync.
Because the engine is indifferent to what the objects are, one platform serves markets that share no vocabulary. Schema packs ship for service operations and enterprise back office, and Deskwise is publishing packs for robotics and space and earth observation, where the objects are robots, sites, satellites, and captures — and where the consequence of an unreviewed action is severe enough that the governance layer stops being a feature and becomes the condition of being allowed to operate.
“Every organisation is being asked to let software act on its behalf, and almost none of them can say afterwards which thing acted, under whose authority, or whether it worked,” the Deskwise founding team said. “We built the layer that answers those three questions, and put the workforce inside it rather than beside it.”
Deskwise is available today at deskwise.co, with a public API, an MCP endpoint, and a typed SDK generated from your own schema.
The questions buyers actually ask.
What is Deskwise, precisely?
An ontology and action layer for your organisation, with an AI workforce that operates on it. The ontology is a typed model — object types, typed properties, typed links between them, and actions declared against them. The action layer is the single path every state change takes. Agents are how work gets proposed and executed inside that structure, not a separate product bolted on top.
How is that different from a database or a data warehouse?
A warehouse answers questions about the past. This is a live operational model that can be acted on. Objects carry typed properties and PII classes; links are typed with declared cardinality; and actions are first-class definitions with input schemas, preconditions, risk tiers, and handlers. You don't query it and then go do the work somewhere else — the work is defined against the same model that describes the business.
Do we have to migrate our data into it?
No, and that's deliberate. Existing systems of record are exposed as read-through projections: a read compiles to SQL against the native table and rows are never copied. There's no ETL job to maintain, no sync to fall behind, and no second copy of the truth to reconcile. Projections declare their own link types and cardinality, so a projected table participates in traversal exactly like a native object.
How is tenant isolation actually enforced?
At the database, not in application code. Every ontology table has row-level security enabled AND forced, with the policy keyed on a tenant id set per transaction. The application never adds a tenant WHERE clause, because a scoping rule that lives in application code is one refactor away from being dropped. A cross-tenant probe reads as zero rows and is indistinguishable from a record that doesn't exist.
What stops an agent from doing something it shouldn't?
Every invocation runs a fixed pipeline before anything happens: resolve the action, replay if the idempotency key has been seen, validate the input against its JSON Schema, apply the approval gate, evaluate the precondition against live state, snapshot the target, execute, snapshot again. Each terminal outcome persists exactly one invocation row — including the denials, the invalid inputs, and the precondition failures. What was refused is as auditable as what ran.
Who is allowed to invoke what?
A role by risk-tier matrix enforced in the engine, never in the UI. Actions are tiered low, medium, or high; a front-desk role never reaches high, a provider role never exceeds low. Property visibility is separate and stricter: financial properties are readable only by owner, manager, and internal admin, and a provider sees their own and nobody else's. Agents are masked from high, financial, and health properties by default regardless of the role they act under.
How do we stop it entirely if something goes wrong?
Two kill switches — one per tenant, one global. When either is set, every agent-initiated invocation is denied and written to the audit trail as forbidden, while human-invoked actions and the underlying operational flows keep running. Stopping the agents does not stop the business.
Can we extend the model with our own objects?
Yes — object types, typed properties, link types, and actions are all customer-extensible, and a typed SDK is generated from your own schema so your code sees your vocabulary rather than ours. Type mutations require an internal-admin role today, because a type change reshapes an entire tenant's graph. Making that self-serve is on the roadmap.
How do you handle derived data and analytics?
Every derived object carries its lineage: which job produced it, at which version, a digest of the input partitions, and references to the objects behind the figure. Identical inputs produce an identical digest, so re-running a job is a no-op that returns the prior result. Any surface showing a computed number can drill through to the records underneath it — a figure you can't trace back isn't finished.
Is it multi-agent?
Yes, and the interesting part is the constraint rather than the capability. Each agent holds its own identity and short-lived scoped credentials rather than a shared key. When one delegates to another the authority narrows and can never widen, the chain is depth-limited and cycle-free, and the whole chain draws on one shared budget — otherwise delegation is simply a way to escape a spend cap.
How is usage metered and billed?
The invocation ledger is the usage record — there is no parallel counter to drift out of sync. Actions can carry a SKU, making them entitlement-gated: without an active entitlement the engine refuses and records why. Rollups aggregate by actor type and SKU for billing.
Is this only for service businesses?
No. That's where the vertical schema packs are deepest, but the engine is indifferent to what the objects are. The same platform runs an agency's client operations, a company's finance and IT back office, and — with a different pack — a robotics fleet or a satellite constellation. A robot, a satellite, and a customer are the same shape: an instrumented thing producing events that need interpreting and acting on, with a human who stays accountable.
What if we want to leave?
Your agents, ontology, and memory export as a documented open format, including an explicit statement of what the file cannot contain and why. Credentials never travel — they're issued to us by the provider and scoped to us, so exporting them would be a security failure rather than a feature.
Is there an API?
The platform is the API. Schema discovery, object query and traversal, action listing and invocation, all reachable with a scoped key or an OAuth client-credentials token, plus an MCP endpoint so an agent you already run can operate your workspace through the same governed path a Deskwise agent does.