Program case study
ActantOS
Runtime safety and verification for multi-agent systems.
The shipped v1.2.0 enforcement kernel, the path a tool call takes through it, and the multi-agent safety questions that remain research targets.
v1.2.0 “Quiet Open-Core” — shipped, self-hosted
- Multi-agent Systems

Research context
ActantOS sits in the Multi-agent Systems area, and it works on the question the lab returns to: what should an autonomous system be allowed to do, and who decides?
The program keeps two things apart that are easy to confuse: an enforcement baseline that is shipped and self-hosted, and coordination guarantees that are still being tested.
Approach
- Intercept the tool call before it reaches the system it would act on.
- Evaluate the call against policy and return one of three outcomes: allow, pause for a person, or block.
- Record the decision, so the path to an action can be reconstructed afterwards.
System architecture
Caller
Agent tool call
An action an agent asks to take. The kernel treats it as untrusted until policy decides.
Interception point
Self-hosted enforcement kernel
Sits between agents and the systems they act on, so no call reaches a target system unexamined.
- Fail-closed enforcement
Decision
Cedar policy engine
Evaluates the intercepted call against the organisation's policy.
- Cedar policy engine
Outcome
Allow, pause, or block
The three outcomes the program states. A paused call resumes only with a one-use human approval.
- One-use human approvals
Record
Hash-chained audit trail
Keeps the decision and the order of events, so the path to an action can be reconstructed.
- Hash-chained audit trail
Contract
Frozen /v1 API
The release freezes its versioned interface, so integrators can rely on it.
- Frozen /v1 API
Current implementation
- Published status
- v1.2.0 “Quiet Open-Core” — shipped, self-hosted
The status above is the published one: the kernel runs on the operator's own infrastructure, and the release is documented on the program site.
What this does not claim
- The multi-agent safety properties are research targets, not v1.2.0 claims: shared approval admission, coupled approval–decision–effect safety, and omission-aware effect evidence are still being tested.
- A shipped kernel is not proof that those properties hold, and this case study does not present it as proof.
Evidence
What the record establishes
The evidence is a shipped, self-hosted release with a frozen API and a documented release page at actantos.com — and ActantBot, the employee-facing bot family that runs on the same kernel.
What it does not establish
The release does not establish the multi-agent coordination properties. The program states them as hypotheses, and this page repeats that wording.
Roadmap
Every item below is planned, proposed, or under investigation. None of it is shipped, and this list is not a release schedule.
Under investigation
Shared approval admission (C1)
Under investigation: at most one successful authorization admission across heterogeneous executors, under declared races, duplicates, crashes, recovery, and partitions.
Under investigation
Approval–decision–effect safety (C2) and omission-aware effect evidence (C3)
Under investigation: the coupled invariant under a declared failure model, keeping attempted, accepted, committed, observed, and unknown outcomes apart.
Proposed
Managed deployment beyond self-hosting
Proposed: the program site lists multi-tenant managed deployment as conditional roadmap, not as part of the public baseline.
Collaboration
ActantOS grows through platform and safety teams that already run agents against real systems and want the calls governed rather than trusted.
Work on a program with us.
Each program takes on partners where the research question meets real practice — clinical review for AIMed, agent runtime governance for ActantOS and Agent Platform, academic workflows for ScienzaOS, and document-heavy collections for AgenticOCR.
Discuss a collaboration- Clinical pilots
- Research collaborations
- Dataset partnerships
- Student theses
- Open-source contributions
