TRUST · THE INFRASTRUCTURE

Money-out is human-only. Welded at the database.

Eight money-out action classes are locked to propose-only in the database schema itself — not a checkbox, not a UI guard. Auditable AI agents whose every action lands on a record you can open, with kill switches, physical tenant isolation, and a human confirming anything that matters.

Book a demo View plans
PROPOSE · CONFIRM · AUDIT · UNDO
WHY THIS PAGE EXISTS

Anyone can say “human in the loop.” Command welds it into the database: the platform cannot be configuredto move money out on its own — not by us, not by you, not by an agent. Every trust claim on this page names the mechanism that enforces it.

THE COVENANT

Propose → confirm, with the undo declared first.

Every AI action in Command is a proposal until a human confirms it — and each proposal declares its undo before you decide. A proposed journal entry carries its reversing entry; a proposed change names what puts it back. Where no clean undo exists, the proposal says so plainly, so confirming is never a leap of faith.

And for the eight money-out classes, confirm is as far as autonomy can ever climb — the database caps them at propose-only no matter how much trust an agent earns elsewhere.

PROPOSED · MONEY-OUT

Record bill payment — Hartline Electric · $4,120.00

declared undo: reversing journal entry, ready to post
autonomy: propose-only · platform-locked
No confirm, no action — and this class can never auto-confirm.
THE RECORD

An audit log that opens the real thing.

Most audit logs tell you who-did-what-when and stop there. Command’s audit desk is a first-class, human-viewable surface where every row drills through to the actual artifact— click the event and see the real email that was sent, the real document that was filed, the real journal entry that was posted.

The spine is append-only — touches, agent run steps, and agent definitions can be added to but never rewritten — and failures are first-class red rows, never quietly dropped. That’s what “auditable AI agents” means here: not a report about the record, the record itself.

THE DIFFERENCE

A setting can be flipped. A schema is a wall.

“Human in the loop” is only as strong as where it’s enforced. Most tools enforce it in the interface — Command enforces it where the data lives.

GUARDRAILS AS SETTINGS

What most AI tools offer

An "approval required" toggle someone can switch off
Guards that live in the UI — anything bypassing the screen bypasses the guard
Logs that summarize events but can't show you the artifact
Shared tables for every customer, separated by a column
GUARDRAILS AS SCHEMA

What Command enforces

Eight money-out classes capped at propose-only by a database constraint — no toggle exists
The DB is the wall: the cap holds no matter which surface, agent, or API path asks
An audit desk whose rows open the real email, document, or entry
A dedicated schema per tenant, with row-level security on every read
THE GUARDRAILS

Four more walls, all load-bearing.

The money-out lock is the headline; these hold up everything else. Each one is enforced in the runtime and verifiable in a demo.

KILL SWITCH

Global, tenant, and flow

Kill switches at three scopes, checked when a run is queued and re-checked when the worker claims it. Flip one and agent activity at that scope stops.

ISOLATION

A schema per tenant

Your business lives in its own database schema — the full ontology, not shared tables — and every read runs under row-level security on your identity.

ACCESS

RBAC + MFA

Four tenant roles (owner, admin, analyst, viewer), TOTP two-factor, an optional tenant-wide MFA requirement, and step-up checks on sensitive actions.

HONESTY

Degrade loudly, never fake

A failed read dims its tile and says why — never a fabricated zero. Capped reads are labeled partial. The system tells you what it doesn't know.

How the agents themselves are governed — charters, budgets, run traces, the escalations desk — lives on the AI agents page.

QUESTIONS

Good to know.

No — structurally, not by policy. Eight money-out action classes (refunds, bill payments, payouts, distributions, retainage releases, tax payments, capital returns, payroll) are platform-locked at the database to maximum autonomy 1: an agent may propose, a human must confirm, forever. It is a database constraint, not a setting — there is no toggle, plan, or configuration that makes the platform auto-pay.

Don’t take our word for it.
Take the schema’s.

Book a demo and ask the hard questions — watch an agent propose, open the audit trail to the real artifact, and see exactly where the money-out wall holds.

Book a demo View plans