Skip to content
Get access

Use cases · AI-agent platforms · PG-11

Your agents propose. Your policy approves. The chain proves it.

Read and write one ledger with scenario and status filters — propose without posting rights, attributable always.

  • proposal-only credentials
  • hash-bound approvals
  • T0/T1 gates
  • every commit an event

Can agents post? Through a governed path — never raw write access

An agent credential carries propose and read only. Approval, finalization and correction are structurally out of reach — enforced at the credential, not the prompt.

  • Propose agent credential · provision.write + provision.submit

    The agent authenticates with a scoped, expiring credential — bootstrap-issuable programmatically, audited at issuance. It reads balances, entries and provenance with scenario and status filters, and drafts entries that stay Provisional.

    FR-220/807 · PH-1

  • Evaluate server-side · materiality gate

    The tier is computed server-side from stored policy matched on source, actor kind, document type, amount, account class and period state. The T0 path finalizes with no human — attributed to a system actor with a policy id, the requesting agent as attributed_to. No request field or tool argument can downgrade a tier.

    FR-217 · PH-1 T0/T1; T2/T3 Roadmap

  • Approve content-hash-bound · decide inputs recorded

    Approvals bind the entry id, revision, content hash, policy and tier with the decision inputs recorded so the control is re-performable. Any material edit voids a pending approval and returns the entry to Provisional — approvals never carry across revisions.

    FR-215/216/219 · PH-1

  • Finalize T6 · one-way · chain extended

    Finalization is the only writer to the books and it is irreversible: postings become immutable, the chain extends. Later change flows only through typed reversing, adjusting or restating entries.

    FR-211/205 · PH-1

  • Every step is an event material or micro — no exemption

    Every edit commit appends an OCEL2 event on the entry object, even memo-level micro-edits — no write path, tool or storage optimization may bypass event capture.

    FR-208 · PH-1

A substrate, not another app

You keep the agent experience and the client relationship; the ledger supplies the semantics, the gates and the evidence.

read get_balance

As-of and as-believed balances by ledger, book, scenario and account — returned with the chain position of the events that produced them, over MCP and REST with one error taxonomy.

propose create_provision

Propose an entry over MCP. Proposals run the materiality gate server-side; the agent holds no posting rights of its own, and every call appends a provenance event.

read validate_entry

The write-safety check an agent calls before proposing: the full validator — balance, currency, account state, dimensions, equation, policy — with structured errors and nothing written.

read preview_entry

Preview invariants and policy outcomes — evaluated tier, required approvers — provably side-effect-free: no sequence consumption, no events, no aggregate movement.

MCP is table stakes; governance is the product

MCP is a first-class surface with parity to HTTP — same semantics, same error taxonomy — and it works air-gapped against your own local model. What differs is everything around the call: scopes, gates, provenance.

FR-343 · PH-1 read/propose; full tool surface Roadmap

Evidence for the engagement review

The lifecycle — including agent actions — exports as OCEL 2.1: who acted with which credential, when, through which channel, against which entry. A third party can verify it without ledger access.

FR-905/529 · PH-1 (OCEL 2.1 JSON)

T0 scope, honestly capped

Auto-finalization is limited to the clearly-trivial band where template, source, account class and period state all match — and it is reversal-capped. Everything above the line stays human-approved. Auto-reversal accruals arrive with PH-2.

FR-217 (T0), OI-25 · PH-1; accruals Roadmap

“How do you audit what an agent did?”

Make every agent action an event, not a log line. The ledger records who acted (actor plus credential), when (insertion time), through which channel (API, MCP, CLI or streaming), and against which entry — for every mutation — chain-hashes the event stream, and exports the whole lifecycle as OCEL 2.1, so an auditor can reconstruct the agent's exact actions from reproducible evidence rather than vendor assurances.

DP-5 · FR-500/524/905 · PH-1 (OCEL 2.1 JSON export)

The full agent audit trail →

  • Your clients' question: "what exactly did the agent touch?" — answered from the event graph, per entry, per credential.
  • Your duty-of-care story: agent writes are gated, attributable and reversible by typed correction.
  • Your exit story: the record leaves with your client — OCEL 2.1 and open interfaces, no proprietary formats.

Agent-platform FAQ

Can AI agents post journal entries?

Yes — through a governed path, not raw write access. An agent authenticates with a scoped, expiring credential (a test class can never write to a production ledger), reads and proposes entries over MCP, and proposals are evaluated server-side against materiality tiers: above-threshold entries stay provisional until a human approves. Every agent action appends a provenance event. At PH-1 the MCP surface covers read and propose; the full tool surface is on the roadmap.

Does the governed path cover MCP, or only REST?

Both, with the same semantics and error taxonomy. MCP is a first-class read/propose surface with parity to HTTP — including air-gapped, against your own local model. Agents receive no privileged bypasses of the server-side writability matrix, and tool descriptions state the scopes required and the errors they can raise.

When does the full tool surface land?

The full MCP tool surface and approval-gated MCP writes are on the roadmap (PH-2). The shipping surface is read and propose: balances, entries, provenance reads, and proposals that run the materiality gate — plus the write-safety tools an agent calls before proposing, which validate and preview a posting without committing anything.

What Ledgerbook is not

Where the platform ends is exactly where your agent begins.

  • No models in the core (NG-4). Your agent, your model, your prompts. We never see them. What we enforce is what the credential may do — read, propose, and nothing else — so a better model does not become a bigger blast radius.
  • No UI (NG-1). No agent console, no approval inbox. The transitions, the approval objects and the provenance events are queryable; the interface your operators use is yours to design.
  • Not an ERP (NG-2). Agents that operate business processes still operate them in the systems that own those processes. Here they write the accounting consequence, through a path that cannot post on its own authority.

Give your agents a real ledger

The design-partner programme pairs you with the primitives your firm clients will ask about first: gated writes, attributable actions, verifiable evidence.