fork.
Open studio
Under the hood

An execution harness, not another chatbot.

The treasury screen is one application. Underneath is a reusable branch-and-commit engine that controls agent state, approval, and tool execution.

Open the decision studio

How a decision becomes an action

  1. 01 / Propose
    AI planner

    A model drafts alternative plans as validated, structured actions. Its output is untrusted data.

  2. 02 / Compare
    Branch engine

    Each plan is simulated against the same frozen snapshot. Plans the money cannot cover are rejected here.

  3. 03 / Approve
    Human gate

    The CFO approves one plan. Its exact steps are frozen and hashed, and cannot be edited.

  4. 04 / Enforce
    ArmorIQ

    The approved steps are signed as an intent plan. Every tool call is checked against it and against policy.

  5. 05 / Verify
    MCP + ledger

    The payment server accepts only a single-use capability, writes an append-only receipt, and is reconciled.

Two independent permission boundaries. A person approves the plan through the harness. ArmorIQ then verifies intent and policy on every call before the payment server will act. Plain code, not a model, drives the approved steps.

Four ways a call can be stopped

These are separate outcomes from separate systems. The interface never shows one in the colors of another, so you always know who said no.

  • Rejected by FORKBefore ArmorIQ is asked

    The plan itself cannot work, for example it overdraws the account or breaks the minimum reserve. It can never be approved.

  • Blocked by ArmorIQOn a tool call

    The agent's tool call is not in the signed plan, or policy forbids it. A bank-detail change that nobody approved stops here.

  • Held by ArmorIQOn a tool call

    The call is allowed but large. It waits until a person approves it on the ArmorIQ platform. FORK cannot approve it.

  • Refused by the MCPAfter ArmorIQ allows

    The payment server rejects a request with a missing capability, a different recipient, or not enough cash.

What makes it reusable?

The harness owns branches, lifecycle, approvals, execution checkpoints and the event history. A domain supplies its own simulation rules and tools. Treasury is the first one.

Snapshot isolation
Harness
Branch lifecycle and state
Harness
Simulation and feasibility
Domain adapter
Human approval and plan hash
Harness
Intent signing and policy
ArmorIQ
Large-payment holds
ArmorIQ
Payments and receipts
Finance MCP
Audit log and reconciliation
Harness + ledger

The contract

A domain adapter implements one small typed interface.

interface ForkDomainAdapter<Base, Action, Projection, Diff, Receipt> {
  validateActions(base: Base, input: unknown): Action[];
  simulate(base: Base, actions: Action[]): Projection;
  diff(base: Base, projected: Projection): Diff;
  feasibility(base: Base, projection: Projection): Feasibility;
  toToolSteps(
    base: Base, actions: Action[], idempotencyPrefix: string,
  ): CanonicalToolStep[];
  verifyPostcondition(
    before: Base, after: Base, receipts: Receipt[],
  ): VerificationResult;
}

From packages/harness/src/adapter.ts.

What is real in this demo, and what is not?Honest scope
  • Real: the planner and inbox agents are live models, and ArmorIQ verdicts are recorded from real ArmorIQ responses.
  • Sandbox: the company, its vendors, the bank ledger and the payments. No real money moves.
  • The two safeguard tests in the studio are deliberate, and every record labels them as security tests rather than agent behavior.