How to Test an AI Agent Through ActantOS on Any Computer

One command, four governance checks

ActantOS v1.2.0 adds a portable first-run path for Windows, macOS, and Linux. If the computer has Node.js 22 or newer, you can test the enforcement loop without installing Docker or configuring Postgres.

git clone https://github.com/kotobuki09/actantos-releases.git
cd actantos-releases/actantosd
npm run quickstart

The command installs exact dependencies, builds the kernel, starts an isolated in-memory server on 127.0.0.1:4310, sends agent-shaped tool requests through ActantOS, reports the decisions, and stops the server.

What the test actually does

The portable runner is deliberately small. It exercises four boundaries that define the product:

This is not a mocked policy function. The requests travel over HTTP through the running actantosd server and the same /v1/intercept/tool-call boundary an adapter uses.

The startup sequence

npm run quickstart performs five steps:

1. npm ci installs locked versions in a Git clone; a packed release uses npm install because npm excludes its lockfile from the tarball.
2. npm run build compiles a source clone; a release tarball uses its shipped dist/ build.
3. Node starts dist/index.js in memory on a loopback-only address.
4. The runner waits for /health/ready, then sends the four agent checks.
5. The runner terminates the server, including the real child process on Windows.

If port 4310 is already in use, select another one:

ACTANTOS_QUICKSTART_PORT=5310 npm run quickstart

In PowerShell:

$env:ACTANTOS_QUICKSTART_PORT=5310
npm run quickstart

Where the decision happens

The agent does not decide whether its own action is safe. It describes the intended tool call to ActantOS. The kernel then evaluates deterministic policy and risk rules before returning one of three outcomes:

• allow: the adapter may continue with the bound decision.
• deny: the adapter must not execute the action.
• approval_required: execution pauses until a human makes a separate decision.

This separation matters. Prompt instructions can influence an agent, but they are not an independent enforcement boundary. ActantOS sits in the action path.

Portable test versus persistent self-host

The quickstart uses in-memory state so the first test has one runtime dependency. It is meant for evaluation, CI smoke checks, workshops, and adapter development.

For normal persistent operation, use the existing Docker Compose path. That adds Postgres-backed audit timelines, evidence packages, migrations, and durable operator state. The frozen /v1 API is the same in both modes.

What success looks like

A successful run ends with:

PASS safe workspace read: allow
PASS credential read: deny
PASS remote agent action: approval_required
PASS agent decisions returned audit evidence identifiers
Portable agent test passed: 4 checks, 0 failed

That output is the minimum proof: ordinary work proceeds, secrets stay blocked, remote effects wait for approval, and the control plane leaves evidence.

Next: use it at work

Portable green is step one. For Compose install, coding-agent wiring, policy dry-run, approvals, and a one-week rollout checklist, see How to Use ActantOS at Work.

Try the release

• Work guide: /blog/how-to-use-actantos-at-work
• Release: v1.2.0
• Repository: kotobuki09/actantos-releases
• Product page: /v1
• Changelog: /changelog