Renzo DemartiniSystems / The finance fleet
Case study · The finance fleet
A finance team that runs on tested code, with AI where judgement is needed.
Built and run inside the multi-entity group where I lead finance, described here without naming it. I designed and built a fleet of agents that can run a large share of a finance function’s routine work. It reads the core systems and reconciles them, forecasts forward, prepares what a person posts, and publishes board pages on a schedule.
01 What it can do for a business like yours
What the owner sees.
Entities
Intercompany matching and consolidation run on their own, with no reconciling by hand.
Units
Live reporting for the business as a whole and for each unit.
The close
Balance-sheet reconciliations, lease and prepayment schedules, and correcting journals drafted for a person to post, on a set routine.
Supplier bills
Read, matched to the order and coded, then approved by a person before anything is paid.
Cash and the forecast
A 13-week cash view, and a rolling 12-month forecast with ranges, tested against past month-ends before any change goes live.
Swipe
02 The fleet at a glance
The fleet in numbers.
- 30specialised agents, each with a narrow tool list
- 41skills: packaged procedures and domain knowledge
- 119scheduled steps across 4 routines
- 87%of scheduled steps are pure code, with no model call
- 11connectors across 7 business systems
- 2write tools in the whole fleet, both guarded and read back
- ~10Kautomated tests
- ~530data-layer modules (extract and build)
- 65page families, publishing 184 static pages
- 14watcher rules that start work from events
- 8live operational automations on a private server
03 How it’s built
Tested code in the middle. AI at the edges.
The design rule is simple: AI works at the edges, where judgement is needed. The middle is ordinary, tested code.
A model may explain or flag a figure. It never calculates one.
- Claude reads
- Rules check
- A person decides
Every gate has a threshold.
The reference file holds what each build gate checks against.
Then the reporting-day build runs.
Tested code computes every figure. It looks routine.
Reference file
Gate thresholdsReporting day
What each build gate checks against
- Tie-out toleranceA$1.00Ledger to every page
- Back-test limit10%Forecast against past month-ends
- Minimum cash bufferNot set13-week cash view
Reporting-day build
This buildTested code
Every figure computed, nothing written yet
- Ledger tie-outA$0.00Largest difference
- Forecast back-test6.4%Error over past month-ends
- 13-week cash viewNeeds a bufferLowest week found
Claude (Anthropic’s AI model) reads both.
Claude turns the thresholds and the build into the same fields. It calculates nothing.
Plain rules match them, line by line.
Build gates that fail closed: no threshold, no page.
- ✓Ledger ties out
- ✓Back-test within limit
- ✕Minimum cash buffer missing
The mistake, in pages.
One threshold is missing, so nothing is written.
Reporting-day pages
Written0pages
- Thresholds the gates need
- 3
- In the reference file
- 2
- Default used instead
- None
- Missing
- Minimum cash buffer
The build fails closed: it never falls back to a default.
It waits for the owner.
Nothing is written until a person decides. Here, that’s you.
OwnerDecision queue
Blocked. Nothing written.
Needs your decision
The build stopped: the minimum cash buffer isn’t in the reference file, so nothing was written. Set it and rebuild, ask finance to confirm it, or keep the build blocked?
You decide: pick one to see what happens, or the run goes with “Ask finance to confirm it”.
Blocked: nothing written.
Claude (Anthropic’s AI model) reads. Rules check. A person decides.
RebuiltEvery gate has its threshold, so the pages are written.
The threshold in the reference file, the gates passed and the pages written.
Reference file and buildRebuiltSample
Reporting-day build
- Minimum cash buffer
Was Not set→, now Set by the owner- Gates passed
Was 2 of 3→, now 3 of 3- Pages
Was None written→, now Written on schedule
Figures explained by ClaudeThreshold set by the owner
- Claude read the reference file and the build into the same three fields, then explained the computed figures in the pages. It calculated none of them.
- The build gates found the minimum cash buffer missing, so the build stopped before writing a page.
- The owner set the minimum cash buffer in the reference file and the build ran again.
Every gate ties out, so the reporting-day pages are written and published on schedule.
Blocked. Nothing written.No page is written on a guessed threshold.
A task on the decision queue: finance confirms the minimum cash buffer.
Decision queueBuild blockedSample
Confirm the minimum cash buffer
- To do: Finance confirms the minimum cash buffer
- To do: It goes into the reference file
- To do: The build runs again
- From
- Owner
- To
- Finance
- Due
- Before the next reporting-day build
Asked by the owner
- Claude read the reference file and the build into the same three fields. It calculates nothing.
- The build gates found the minimum cash buffer missing, so the build stopped before writing a page.
- The owner asked finance to confirm the minimum cash buffer. The build stays blocked until it is in the reference file.
With every threshold in the reference file, the gates tie out, Claude explains the computed figures and the pages are written.
Blocked. Nothing written.No page is written on a guessed threshold.
A note on the build: kept blocked, nothing written.
Decision queueSample
Reporting-day buildKept blocked
- Gates passed
- 2 of 3
- Pages written
- 0
- Missing
- Minimum cash buffer
Kept blocked: no page is written on a guessed threshold.
Note by the owner
- Claude read the reference file and the build into the same three fields. It calculates nothing.
- The build gates found the minimum cash buffer missing, so the build stopped before writing a page.
- The owner kept the build blocked, with the missing threshold on the decision queue.
With every threshold in the reference file, the gates tie out, Claude explains the computed figures and the pages are written.
Illustrative run: sample thresholds and figures.
One guarded write: from the agents to the bill-capture tool, read back after every write.
Illustrative run with sample thresholds. Claude reads and explains; tested code calculates every figure; the gates and the owner decide what happens.
Where it runs
- One dedicated host. A small always-on machine runs every schedule, watcher and commit. A machine lock stops a second host from running anything at the same time.
- Code and data live apart. Code, prompts and docs sit in a local git repository, with no remote and no third-party hosting. Data, pages and logs sit in the group’s own backed-up document library. A hook writes a verified backup bundle of every commit there, so recovery is one clone.
- One path module resolves every machine-specific path, so the same code runs on any host.
- A private automation server, hosted in Australia, runs the operational workflows. Only a private network can reach it.
04 What it does
Units with a charter and a lane.
The work is split into units. Each unit has a charter, its own outputs and its own lane, so each agent gets very good at one job and never interferes with another.
Accounts payable
Triages the supplier-bill queue every weekday morning. Identifies each document by its tax number, matches it to its order, codes it and prepares it for approval through one guarded write path.
Board and management reporting
Profit and loss by entity and by unit, debtors and a month-end pack, rebuilt from tested code every reporting day.
Forecasting and planning
A rolling 12-month forecast with P10, P50 and P90 ranges. It is back-tested over past month-ends and has to pass a ship rule before any change goes live.
Cash
A 13-week cash forecast and the payroll cash call. Every payment figure is taken from the accounting ledger.
Payroll and people
Leave balances, utilisation and month-end payroll journals, prepared as import files for a person to post.
Month-end and group close
Balance-sheet reconciliations, lease and prepayment schedules, and intercompany matching across entities. Correcting journals are drafted and never posted.
Internal audit
Controls testing, sampling and fraud analytics over payables, receivables, payroll and the close, with a control register and deficiency grading.
Operations workflows
Event-driven workflows between operational systems and email, such as filing a delivery docket against its purchase order.
Reliability and assurance
Agents that find and fix the fleet’s own failures, and an independent check that each fix did what it claimed.
05 Where I draw the line
The fleet does three. A person does the fourth.
One supplier bill, at four levels.
- The fleetReads
Reads the bill.
- The fleetChecks
Against the order and the limits.
- The fleetPrepares
Ready for approval.
- A personDecides
A person approves the payment.
The fleet does the first three. A person always does the fourth.
06 The five layers
The five layers.
AI appears in one layer only. Open any layer for the detail.
Read-only at the bottom. Static pages at the top.
Layer 5Static pages
- Each page is an HTML snapshot with its data fixed at build time. It never fetches anything when it’s opened.
- It leads with a chart and a one-line takeaway, is written in plain English for a non-technical board, and works on a phone.
Layer 4Agents for judgement onlyAI here only
- The work they do: bill identification, narrative over computed figures, failure diagnosis and repair, audit testing, and cited advisory drafts on tax, accounting standards and payroll law.
- Agents never do arithmetic, or anything a script can do.
Layer 3Schedules and watchers
- Four routines walk the steps the registry lists: weekday, reporting day, weekly review and monthly.
- A step runner checks connector health, records the start, runs the step, verifies the output parses, and commits by explicit path.
- Watchers poll for change within a call budget and trigger the tested build that a change needs. Events come first; the clock is the backstop.
Layer 2A tested data layer
- Extract code is the only code that calls a system. It pages to the last page and proves every filter changed the result.
- Pure calculation functions compute every figure.
- Builds run the gates. On any failure they exit with
BLOCKED: <reason>and write nothing.
Layer 1Connectors, read-only by construction
- Each system has a small connector service with a health check and a diagnose call.
- Write tools are denied by exact name in the harness settings, so “read-only” is enforced by the platform, not requested in a prompt.
- Each connector has a data skill that records what was measured about its API: which date field a filter really honours, which parameters are silently dropped, and where paging stops early.
The registry is the spine. Routines, page families, write grants, model routing, connectors and units live in TOML files. Everything else is generated from them or linted against them. An agent with no routing row, a page with no family, or a write tool with no grant fails the lint.
07 How data is handled
Every output carries a data class.
The class decides where it may live and who may see it.
INTERNALCONFIDENTIALRESTRICTED
Bill preparation writes back, but the raw write tools stay denied.
- 1Fetches the record fresh
- 2Applies a structured decision, not a free-form payload
- 3Validates the whole document in code: the lines add to the subtotal, the subtotal plus tax equals the printed total, and payment details can never change
- 4Writes
- 5Re-reads and compares every field it wrote
A live write needs two registry settings to agree: the rollout stage, and the list of bill types cleared for live writing. Anything missing or unreadable refuses the write, and a dry run is always available.
How data is handled, in detail
- Business data stays home. It lives only in the group’s own document library. The code repository holds no data, and data outputs are never committed.
- Restricted data (payroll, HR, tax file numbers, bank details) is written in exactly one place per unit, and never linked from a business-wide page. A lint checks every page for it before publishing.
- Credentials are never read. A hook inspects every file read, search and shell command, including strings inside code, and blocks the credentials folder. Connectors load their own keys when they connect.
- Read-only by default. The whole fleet has two write tools, into one system. Each is granted in the registry, validated in code before it writes, and read back afterwards.
- Safe writes to synced files. Every document in the synced library is written atomically: snapshot, temp file, sync to disk, rename, read back. A hook blocks raw edits, because a sync tool once handed back a partial file.
- Live, never cached. Sources are read fresh on each run. A missing source stops the build, rather than falling back to yesterday’s copy.
- Some facts come only from a person. Statutory due dates are supplied by the owner and are never looked up.
08 Why the numbers can be trusted
One path for every number.
Every number on a page takes the same path, and no model sits on it: read-only extract → pure calculation → build gates → page lint → static page. A model may explain or flag a figure. It never calculates one.
PASS pages read 9/9, rows match the system's own count PASS date filter cut 940 rows to 62 PASS section totals tie to the ledger's reported net profit PASS assets − liabilities = equity BLOCKED threshold "retention_days" missing from reference file. Nothing written.
Run log, illustrative.
Five rules behind every figure
- Fail closed. If what a check looks for is missing, that’s an error. A missing threshold switches off the rule that needs it, rather than falling back to a default.
- Absence is not zero. A feed that isn’t available shows “not measurable yet” and the reason. It never shows a zero that reads as “nothing overdue”.
- One figure, one home. 142 headline figures are registered with a single source, so every page shows the same value.
- Lineage on demand. A command traces any headline figure to the function that computes it, its inputs and their as-at dates, and its top contributors.
- A forecast that publishes its misses. It is replayed at past month-ends, blind to anything after each cut-off. It is scored on bias, typical miss and how often the actual fell inside its range. A change ships only if it passes the ship rule at every horizon. Expert judgement goes through the same gate as the code.
09 Governance: few rules, hard ones
The rules that stop work.
The standing instructions fit on two pages. These are the only things that stop work. Everything else gets done.
- Money and outside commitments belong to a person. The fleet prepares payments, journals and lodgements, and a person executes them. No tool that executes them exists in the fleet.
- Connectors are read-only, with the two guarded write tools as the only exceptions.
- Business data stays in business storage. No git remote, and no third-party code host.
- Restricted data lives in one place per unit.
- Credentials are never read.
- Statutory dates come from the owner.
How the rails are enforced
The rails are enforced by configuration, not by prose:
- deny rules on every write tool;
- 11 hooks that run on every matching tool call. They cover credential reads, raw file writes, git safety, lane boundaries and agent model routing, and include a check that sends back any reply that puts off work;
- a registry lint after every commit.
Decisions with a memory. When a run needs the owner’s call, it files a structured multiple-choice question with the recommended option first, and keeps going on everything else. Every answer goes into an append-only journal, with the expected result as a measurable target. The journal scores each decision automatically at 30, 60 and 90 days.
10 A fleet that improves itself
It finds and fixes its own failures.
A failed step is fixed, tested and re-run inside the same run.
- A scheduled step failsThe run log records it
- Root causeA reliability agent finds it
- Fix and testThe tests run before anything is kept
- CommitIn its own lane only
- The step re-runs onceIn the same run
A weekly check then confirms each fix did what it claimed.
How the fleet improves itself, in detail
- Same-run repair. When a scheduled step fails, a reliability agent finds the root cause, fixes it, runs the tests and commits. The step then re-runs once in the same run.
- Daily detection, weekly assurance. A weekday sweep reads every unit’s run log. A weekly check confirms outputs landed, figures tie and each fix did what it claimed. A watchdog reports any scheduled run that never started or stopped part way.
- Lanes. A scheduled agent fixes only its own unit’s files. Anything outside its lane goes to the one reliability agent that is allowed to work across units, and a hook enforces this.
- It learns from corrections. Lasting ones are recorded as signals and turned into replay cases, so the same mistake can’t quietly come back.
- A replay harness. Real agents re-run against recorded incidents, with their connectors swapped for local fixture servers that record attempted writes instead of making them. Money fields are compared in code, against a tolerance. Every prompt change on the money path is replayed before it ships.
- Model routing by evidence. Each agent is pinned to a model. A monthly bake-off replays frozen inputs through cheaper options, and scores them against facts computed in code. A cheaper option is adopted only when it matches across repeated runs.
11 Principles I’d carry anywhere
Each principle, and the failure it prevents.
- Code computes, models explainA confident, plausible, wrong total that nobody can reproduce next week.
- Paginate to the last page, and prove itA report built on page one, the most common silent error in any API.
- Prove every filter changed the resultA connector that drops an unknown parameter and returns all of history for a one-month request.
- A write’s echo is not proofA partial update that wiped the rest of a record and reported success.
- Remove the danger at the sourceWeeks of guardrails around a risk that one change would have removed.
- One committerParallel agents overwriting each other’s work in a shared git index.
- Verify against disk, not memoryThe most common agent failure: a claim checked against recollection.
- Rails over review chainsA slow approval chain that costs more than it catches.
Swipe
12 My role
I own the fleet end to end.
- ArchitectureThe layering, the registry, the connector pattern and the hosting.
- ControlsThe rails, the guarded write path, the data classes and the enforcement hooks.
- Engineering standardsFail-closed builds, tests on every figure, and replay before release.
- Finance methodThe forecast, its back-test and ship rule, and the close and reconciliation logic.
- Operating modelThe schedules, lanes, decision journal and self-repair loop.
The fleet takes over the analysis, preparation and status work. People keep the decisions, the money and the relationships.
13 Could this run in your business?
Built inside your business, owned by your team.
This is one way I deliver the ‘Lead the change’ engagement: I build a finance function like this inside your business, and your team owns it at the end.
Lead the changeBuilt in Python, with language models at the edges. The log lines in section 08 are illustrative.
What’s happening in your business?
Tell me in a few sentences. I reply personally within one business day.