Alpha · Aya-led
Work OS is the operator control plane for a fleet of agents — and the place the generation-verification loop stops.
Autonomy is easy to demonstrate and hard to govern. The interesting question is not whether an agent can act, but who authorised it, on what evidence, under which clearance, and what the system did with the alternatives it discarded. Work OS answers those four in the interface itself.
Composed from
Aya · Cortex · Vault
Work OS is where the module layer becomes visible to an operator: Aya reasons, Vault decides what may be touched, and every action carries an Evidence Ledger entry. View the module layer →
§ 01
Governed autonomy
An agent detects an opportunity and proposes an action. Before an operator sees an approve button, the case carries a clearance level, the purpose the access was granted for, the data scope it is bounded to, and the lineage from raw ingestion through every transformation.
Purpose-based access
Clearance is scoped to a stated purpose and a named data boundary, not to a role.
Data lineage provenance
Raw ingestion and ontology transformation are both shown, with the mapped object named.
Human in the loop
The patch is drafted and held. Execution requires a person to approve it.
§ 02
Fleet capability
Agents are not a black box you either trust or don't. Each subsystem reports its own load and readiness, so an operator can see which part of the fleet is under strain before it becomes an incident — and which capability is carrying the work.
Readings shown are from a demonstration environment.
§ 03 — The engagement
Most teams find the approval gate is cheaper than the incident review. A Mission Sprint tests that on a workflow you already run.
All powered by Serpens
Aya · Cortex · Vault
Every Serpens product is a configuration of the same four engines and a shared set of reusable modules. How Serpens is built →