For teams building finance-ops agents

Memory, made legible.
What the demo shows, and what it means for finance-ops agents.

The best finance-ops agents run deterministic steps with minimal LLM dependency, preview every action, and host in the EU. This deck explains the mechanism behind the demo, then maps it onto such an agent: per-user and per-company facts, and a shared procedural memory that gets better with every session across every customer.

How the demo works

Four beats, one kernel.

Four memory scopes

User, team, company, and the agent itself.

Procedural memory

The agent learns how to do things, from everyone.

Fewer mistakes

Three failure classes, and a replay of your logs.

August 2026

1 / 10

The demo

Four sessions played. Everything the agent knows, and why, on one screen.

Left · Conversation

Four scripted sessions, Feb to May

Each session ends with a "dream" line: how many facts were added, reinforced, superseded, or flagged as contested.

Middle · Memory

Profile v4 and the fact chains

The green block is the compiled profile. Below it, every fact with both clocks; superseded facts stay, struck through and dated, never deleted.

Right · Ledger

87 hash-chained events, verified

Turns, facts, supersessions, consolidations, receipts. One turn is opened: payload hash, previous hash, event hash.

2 / 10

What the demo shows

Four beats and an erase button, all against one real kernel.

The demo replays four scripted conversations with one person (a designer who changes jobs and moves house) and asks questions in between. Every beat is a property a finance-ops agent needs on day one.

Beat 1 · Recall

Session 3 knows what session 1 said

No transcript replay. The answer is built from distilled facts plus two short excerpts, under a hard token budget (about 90% cheaper than full context).

In finance: "this supplier always books to 4100", months later

Beat 2 · Correction

Freelance becomes Acme Analytics

The old fact is superseded, not deleted. It is struck through in the profile and one click away.

In finance: "that mapping was wrong, use 4300 from now on"

Beat 3 · Time travel

Truth vs belief on April 1

On April 1 the subject lived in Amsterdam (true since mid-March) but the agent still believed Utrecht (learned May 12). Two clocks, both queryable.

In finance: "which VAT position applied when we booked Q1?"

Beat 4 · Receipt

Click any answer, see why

Each recall writes a hash-chained event listing the exact facts and excerpts the model saw. The ledger verifies live.

In finance: "why did you match this invoice to that PO?"

Finance examples are shown in blue throughout the deck.

Erase. The subject is redacted; the chain still verifies; the facts pane empties. That is customer offboarding with proof, not a promise.

3 / 10

Under the hood

What happens between "play session" and the answer.

no LLM1 · AppendEvery turn lands verbatim in an append-only, hash-chained log. The write is never blocked by a model.

no LLM2 · IndexLexical index, entity graph (local NER), embeddings. Searchable in milliseconds after ingest.

LLM, async3 · DreamBudgeted distillation turns turns into facts. Rules resolve most conflicts; the model arbitrates the residue; every resolution is a logged supersession event.

no LLM4 · CompileA byte-stable profile block per subject. Unchanged bytes keep the prompt cache warm.

no LLM5 · RecallHybrid retrieval (lexical + graph + vector), point-in-time filter, hard token budget, receipt written to the log.

The one LLM call is the dream, and it runs after the session, on a budget, idempotently. "Deterministic steps with minimal LLM dependency" is the same principle applied to memory.

Everything right of the log rebuilds. Indexes, facts, profiles: all projections. That is what makes erasure clean: redact the log, rebuild, scan for residue.

recall(scope, { query, budget: 500, asOf })
→ profile (versioned)
→ ranked facts, each with both clocks and its past
→ two episode excerpts as a safety net
→ receipt_id (a recall.served event in the chain)

4 / 10

The mechanism that matters most for finance

Corrections without deletion: one fact, two clocks.

- The subject lives in Amsterdam
  true since 2026-03-15 · learned 2026-05-12
    previously: The subject lives in Utrecht
    true 2026-02-03 until 2026-03-15 · learned 2026-02-03

# same shape, in bookkeeping:
- Supplier "ACME Analytics" books to 4300
  true since 2026-04-01 · learned 2026-04-18
    previously: books to 4100
    true 2026-01-01 until 2026-04-01 · learned 2026-01-09

Bookkeeping is corrections all the way down. A wrong mapping is fixed, a supplier alias changes, a VAT position flips at quarter end. Retrieval over raw transcripts returns old and new side by side and lets the model guess: the benchmark measured a 12% stale-answer rate on far simpler data than yours.

Valid time answers "what was true on date X" (Q1 close, an audit question).
Belief time answers "what did the agent know when it acted" (the defensible one when a booking is disputed).
Nothing is deleted; the accountant can always see the previous value and who said it.
Contested facts (two people disagree, no rule decides) go to a visible queue for the accountant, not into silent noise.

5 / 10

Applying it to a finance-ops agent

Four memory scopes, one kernel, one `subject_id`.

The kernel's subject is opaque and the org is a dedicated, partition-keyed field. A person, a team, a company and the agent itself are the same machinery with different scope values, and isolation is enforced at the write gate (reject, never default).

Scope	Subject is	The agent remembers things like	Who writes it
User	one person	"Sanne (owner) wants whole euros in the dashboard, never in the books." "Pieter (accountant) wants anything over 5,000 flagged for review."	Their own sessions
Team	a finance team	"Closes the month on the 3rd; sales expense reports arrive late and lack VAT numbers."	Everyone in that team
Company	one customer org	Chart of accounts, supplier aliases ("Acme B.V." = "ACME Analytics"), VAT positions, "this vendor sends photos of screens".	All users of that company
Agent	the agent itself	"In the ERP, create the contact before the invoice; amounts with three decimals are rejected." "PSP payouts net out fees; match on gross."	All sessions, all customers

Resolution at recall time is a real open question: when a user preference contradicts a company policy, which wins, and is the resolution itself receipted? A design partner is the right place to settle it, and it fits a preview-before-execute model: the preview can show which scope a rule came from.

6 / 10

The interesting scope

Procedural memory: the agent learns how once, for every customer.

A procedural fact is a fact about the world of systems, not about a person. Its subject is the agent itself; its provenance points to the sessions where a procedure was learned, failed, or corrected. Because it is a fact like any other, it gets versioning, supersession when an API changes, and receipts for free.

org: shared · subject: agent/erp-connector
- Posting a purchase invoice requires the contact to exist first
  learned 2026-03-04 · seen 3× · from 2 customers
- Amounts with more than two decimals are rejected (HTTP 422)
  learned 2026-03-11 · seen 14× · failed 0× since (next)
- Rate limit is 60 req/min → 300 req/min
  superseded 2026-06-02 (API v2 migration)

The loop that removes repeat mistakes: a session at customer A hits a quirk → the dream distills it into an agent-scope fact → the next run at customer B recalls it before touching the API → the receipt shows which sessions taught it. Getting smarter does not make the prompt longer: the hot procedures compile into one cached block.

Exists today

Runs in the demo

Procedure as a versioned fact with both clocks
Provenance to the sessions that taught it
"Seen N×" reinforcement when re-learned
Supersession when a later session contradicts it
Receipt on every recall; compiled, cached block per subject

Next, shaped by your logs

Three additions

Outcome feedback: the agent reports "used fact X, result 422"; failures are counted
Trust-weighted recall: confirmed, never-failed procedures rank up; ones that start failing are flagged for supersession
Agent-scope content check: reject procedural facts that carry customer data (amounts, names, IBANs)

Isolation

What crosses tenants, and what never does

Only statements about systems and procedures live at agent scope. Customer facts stay partitioned by org_id today; the content check above is the piece that makes the boundary a rule instead of a convention.

7 / 10

What it buys your agent

Fewer mistakes, cheaper runs. Compliance comes along as a consequence.

Preview

"Why is the agent proposing this?"

Every preview carries its receipt: the exact facts (with scope and source session) behind the proposed booking, reminder, or match. A wrong proposal becomes diagnosable in one click, which is the precondition for fixing the cause instead of the symptom.

Cost

Zero-token retrieval, cached profiles

Memory operations use no LLM; the profile and procedure blocks only change bytes when something changed. For a colleague processing every invoice 24/7, memory that pays for itself versus memory that does not.

Dispute

"What did the agent know when it did that?"

Belief-time replay answers it as a query, not a forensic project. Useful for accountants defending a booking, and for AI Act logging that cannot be retrofitted later.

Offboarding

"Forget this customer, and prove it."

Erasure cascades: redact the log, rebuild every projection, scan for residue, keep the chain verifiable. Procedures learned from that customer survive (they contain no customer data); their provenance edge is redacted.

8 / 10

Proposal

Three kinds of mistake finance-ops agents make today, and the mechanism that removes each.

Mistake 1

Repeating a correction someone already made

A wrong account mapping, a supplier alias, a VAT position: fixed in March, applied wrong again in April because the fix lived in one chat.

MechanismSupersession with two clocks. The corrected value wins at recall time for everyone on that company; the old value stays one click away.

Mistake 2

Relearning a system quirk per customer

The ERP rejects three decimals, the contact must exist before the invoice, PSP payouts are net of fees. Each customer pays the tuition again.

MechanismAgent-scope procedural facts: learned once at customer A, recalled at customer B, superseded when the API changes, with outcome counts as the next step.

Mistake 3

Acting on stale or unexplainable state

The proposal is wrong and nobody can say which fact caused it, so the fix is a manual override that does not stick.

MechanismReceipts in the preview and belief-time replay: every error is traceable to the facts and sessions behind it.

Stale-answer rateanswers built on a superseded fact (12% for RAG on the bench)

Repeated correctionssame correction made twice per customer per month

First-attempt postingsERP writes that succeed without retry

Tokens per invoicememory package vs transcript replay

What we need from you

Session logs to replay: a handful of customers over a few months, anonymised or on your infra, including the sessions where things went wrong
Your known quirks per ERP, PSP, and bank connector
One dispute story, end to end: what the agent did, what the customer said, how it was resolved

If logs take time: we start on a synthetic fixture shaped like your world (one SME customer, an owner and an accountant, an accounting-package switch, a late-reported account change) so the four beats run in your vocabulary on day one, then swap in the real replay.

9 / 10

Next steps

Two questions decide the fit; both answer yes for finance-ops.

Will anyone ask your agent why it believes something?

Every preview, every disputed booking, every auditor. Yes.

Will anyone ask your agent to forget someone?

Every churned customer under GDPR, and your ISO 27001 auditor. Yes.

Disclaimer. This is a measured prototype, not a product; the alternatives on the market are products. Outcome feedback, trust-weighted recall, and the agent-scope content check are design intent, not shipped; your logs would shape them.

10 / 10