Prepared for Scott Christensen · Spartan Welding & Diving · 20 September 2026
You wrote the hard part yourself: the system should calculate scenarios rather than have a model invent financial numbers. That single sentence is the architecture. Below is every requirement you set out, what it means in code, how the one agent answers it, what you own at the end, and the order we would build it in.
01 · The rule the whole system is built on
The model never produces a number. It reads numbers that arithmetic produced, and puts them into words.
Every figure you will ever see - usable cash, the ninety-day line, a debtor's expected pay date, a twenty-year scenario - comes out of ordinary, tested code with named inputs. The reasoning layer sits above it and does the work a model is genuinely good at: reading a set of figures, noticing what changed, explaining it in a sentence, and deciding which calculation to run next.
Two practical consequences. A figure can always be traced down to the ledger rows that made it, so it can be checked against your own bank statement. And swapping the model - a different vendor, or your own hardware later - changes the wording of an answer and never the answer itself.
02 · The nine questions you asked before proceeding
The two that need your ledger in front of us - the fixed price and the timeframe - are answered in writing after the first step below, because a number named before anyone has seen the data is a guess wearing a suit.
03 · Stage 1 · the Spartan Agent
This is where a system like this succeeds or quietly fails. Not in the AI - in the definitions. Each line below is agreed with you in writing before it is coded, and each is reconciled against your own bank statement afterwards. One confidently wrong figure is enough to stop trusting the whole thing, so the reconciliation is part of the build rather than a test at the end.
cleared bank balance less your operating buffer less tax and payroll already earned in the period less creditors genuinely due in the window. Uncleared deposits are shown and excluded, never counted.how each customer actually pays rather than by the terms printed on the invoice, plus contracted work, less every dated obligation and the running cost of the business.expected date per invoice = issue date + that customer's own measured average from their payment history. Drift in that average is itself a flag.04 · The agent framework
Your brief asks for five specialist agents, and on a diagram five is the obvious shape. We would build one, and this is the one place where we are proposing something different from what you wrote, so it is worth saying plainly why.
A question does not know which agent it belongs to. "Can I afford the new truck this quarter" is cash, obligations, debtors, risk and both companies at once. With five agents that question has to be split, routed, answered five times and then reassembled by something - and whatever does the reassembling is the sixth agent nobody planned for. With one agent it is simply a question, and the answer comes back whole.
The specialisation does not disappear - it moves down a layer. This is the part that makes one agent possible rather than merely simpler. Each domain below is a set of agreed definitions and a set of tested calculations in the engine, and that is where a specialist's knowledge actually lives: in how usable cash is defined, how a debtor's expected date is measured, which tax calendar applies to which entity. The agent's job is to know which calculations a question belongs to, run them, and explain what came back. So you are not trading depth for simplicity - the depth sits in code that can be tested, versioned and checked against your bank statement, which is a better place for it than inside five conversations.
And it is not a one-way door. If a domain ever genuinely needs to run on its own - its own model, its own machine, its own release cycle - it can be split out later without a single figure changing, because the figures were never the agent's to produce. Starting with one and splitting when there is a reason is cheap; starting with five and merging them is not.
Usable cash, the buffer, the 30/60/90 view, the lowest point ahead, and what it would take to go below it.
Who owes you, how each customer actually pays, when the money lands, and whose behaviour is changing.
Tax, payroll, superannuation, creditors and finance, on each country's own calendar.
Unusual spending, margin drift, customer concentration, and cash approaching the buffer.
Each entity on its own, and the group on one line in one currency at a dated rate.
Holdings, mortgages, rates and insurance, rental yield, equity, amortisation schedules.
Jobs and utilisation, equipment, quoted price against the cost the job actually carried.
Sell, repay, reinvest, expand - scenarios over 1, 5, 10 and 20 years, with sensitivity and stress tests.
The whole position across companies, property and investments, and what it looks like under each scenario.
And you are not at a desk for most of the working day, so the screen is built for a phone first: the same agent, the same figures, in a browser on the handset you already carry. You hold the microphone and ask the question out loud in your own words instead of typing it, and when your hands are busy the answer is read back to you. Voice in and voice out are part of Stage 1 rather than a later idea - on a wharf, in the ute between jobs, the question you would have forgotten by the evening gets asked and answered where it occurred to you.
Every domain above calls the same engine, which is also what makes Stage 2 an extension of this rather than a second project: the property, capital-allocation and wealth work adds definitions and calculations to a layer that already exists, and the agent gains them without being rebuilt.
05 · Dashboards
Asking is right for the question you ask once. For the ones you ask every Monday, asking is a tax on your time: you have to remember the question, type it, and wait. So a large part of your eight questions is delivered as dashboards instead - the same arithmetic from the same engine, computed ahead of you and already on the screen when you open it. Nothing is generated twice and nothing can disagree: a tile and an answer are two drawings of one calculation.
They are grouped, because a single screen of forty tiles is a screen nobody reads. Twelve boards in three families - the money the business makes, the market it sells into, and what could take it away - and each board is one question already answered:
Money what the business earns, holds and owes
Thirteen months of revenue, gross profit and margin on one chart, plus operating profit by month. A seasonal trade read as a trade, not as whichever month has just ended.
Usable cash and the runway it buys, the lowest point in ninety days, what is overdue, what is committed - and the ninety-day line with money in, money out and the closing balance on it.
How long your money spends inside somebody else's business at both ends: days to be paid, days you take to pay, and the gap you are funding between them.
Every category against its own twelve-month behaviour, with the cost of doing the work separated from the cost of having a business at all.
Every facility, what it costs, what is fixed and what can move - and the next twelve months of repayments with interest and principal apart.
Market who buys, what they buy, and where
Who is new, who has gone quiet, who has left, what margin each one actually carries, and whether the eighty-twenty still holds.
Welding, diving, maintenance, inspection, plant hire - which work earns and which merely turns over. Products sit here too when there are products.
The only forward numbers that are not a guess: a quote was sent or it was not, won or lost, and what is still open.
The same revenue and margin cut by where the work was done, this year against last, on each side of the Tasman.
What to watch what could take it away
Every exposure the ledger can measure, scored by the same rule every week - concentration, margin drift, cash cover, dates coming up.
What an hour earns, how many of them were chargeable, and what the wage bill takes out of every dollar.
The holdings outside the trading companies - value, debt, yield and what the interest takes. Stage 2 fills it; the board is built now so it has somewhere to land.
Every one of the twelve has the same three buttons at the top: New Zealand only, Australia only, both together. That is not a filter bolted on at the end - it is the same entity rule the rest of the system obeys, so "both" converts at a dated published rate stored with the result and can always be taken back apart.
And they grow. Each new source you connect adds tiles and cuts to the groups that already exist rather than a new screen to learn: job costing gives profit by job and quoted against actual, timesheets give labour recovery, equipment hours give the real cost of a machine, the property book gives yield and equity beside the trading numbers. The dashboards are built in Step 3, so you have them on your own figures before Stage 1 is finished.
06 · Vendor neutrality, made operational
Model access sits behind one interface. In your settings you rank the providers, and the first one available is the one that writes the words. If it is unavailable the next takes over, and the answer is identical, because the figures were never the model's to produce.
The fourth option is the one most proposals leave out: the subscription you already pay for. A plan seat can drive the reasoning layer directly, the way our own studio runs, so everyday questions carry no per-answer cost and the metered keys sit underneath as the fallback for heavy work.
The same interface is how your own hardware joins later: a local model becomes another entry in that list, ranked wherever you want it.
The plan seat you already hold. No per-token billing, no second invoice, and the routine load lives here.
Your own key and your own billing account, with usage visible in your console.
Fallback for long documents and heavier reasoning.
Fallback, and the cheaper option for bulk classification work.
07 · Ownership, security and the things you were explicit about
Fixed price with handover. Support afterwards is optional and buys nothing the system needs in order to keep running: stop paying us tomorrow and everything continues, because it runs in your accounts on your own code.
08 · Your own hardware, and what it is genuinely good at
The reasoning in this system is small. A few hundred questions a month, each one a page of text, sitting on top of arithmetic an ordinary machine does in milliseconds. Cloud Run, the service you have already started on, scales to zero between questions, so the compute is cents a day on your own account with a cap you set, and model usage is the same order. That is the honest reason to build first: there is a real chance the machine turns out not to be needed for this at all, and that is a better thing to learn before the money is spent than after.
Two things decide whether a 128 GB desktop box answers quickly: the memory bandwidth it reads a model's weights through, and how far the software stack has come for its processor architecture. On the Spark both are real constraints today - it fits large models comfortably and generates their text slowly - so fitting and answering are two different questions. We would put your actual workload on one and measure it before you commit.
High volume, narrow work, running all day, never leaving your building: reading invoices and supplier statements into the ledger, pulling dimensions and revisions off drawings, a quoting calculator built from the orders your customers have actually placed. Purpose-built open models are genuinely good at these, and this is the work we would point a box of yours at first.
Usable cash, obligations, ageing, explaining an anomaly and arguing a scenario are judgment on top of arithmetic. For that class of work the strongest hosted models are still clearly ahead of anything that runs locally - an Anthropic key or your existing subscription, Fable 5.1 at the top tier, with a second provider configured behind it.
None of this is a fork in the road. The engine, the orchestrator, the database and the knowledge base each run as a container, a local model is one more entry in the provider list, and the data is ordinary PostgreSQL and plain files - so moving a piece home is a configuration change and a data move rather than a rebuild. You move one piece at a time, starting with the document work, while the calculation layer stays exactly where it is. And because no figure ever came from a model, swapping one changes the wording of an answer and never a number.
09 · The order we would build it in
Small strong foundation first, exactly as you described. Nothing below depends on the step after it, so you can stop at any point and keep everything built so far.
Usable cash, committed, due, expected, revenue, margin. Your buffer, your thresholds, your filing calendars. Done on a screen share against your own New Zealand ledger, because definitions argued in the abstract come apart on contact with real rows.
The NZ ledger read into your own project on a schedule, every row stamped with when it was read. Secrets in the store, audit logging on from the first query, backups configured.
Each definition becomes a function with test cases, and every result is reconciled against your bank statement and your filed returns before anything is put in front of a model.
The reasoning layer on top, the provider list configured in your settings, and the agent explaining what the figures mean and what changed since last time - asked by typing, or dictated on your phone and read back aloud. The same step builds the twelve dashboards, so the questions you would otherwise ask every week are already on the screen when you open it, with the New Zealand / Australia / both switch on every one of them.
The AU entity connected on its own credentials and its own dataset, its own tax calendar in the engine, and consolidation on top at a dated published rate.
Thresholds you set, checked on a schedule: a cost outside its range, a margin trend, a customer drifting, cash approaching the buffer. One short morning message rather than a dashboard you have to remember to open.
The same engine grows an amortisation schedule, a rate and tax assumption set, growth, yield and inflation, and the scenario runner over 1, 5, 10 and 20 years with sensitivity and stress testing. "Sell property A, repay five hundred thousand of commercial debt, invest the remainder" becomes a scenario with named inputs, a reproducible result and a stored version - so an answer given a year ago can still be explained.
10 · What is still open, from our side
You asked nine questions and they are answered above. These are ours, and none of them is work: each is a sentence from you that fixes an arithmetic definition. We would rather ask them now than meet them inside your data, because a definition discovered late is the one that makes a confident answer wrong.
Those answers, the read-only connection to the New Zealand entity and your buffer and threshold figures are the whole of what the first step needs from you.
11 · Who would be building it
We are twin brothers in Brisbane, and each of us has spent more than twenty years doing two jobs at once: writing production software, and answering for real accounts, month-end and audits. Alex built the accounting system a packaging group runs in twenty of its plants. The system Sergii built for an international voice business ran the whole company, a hundred people working inside it every day, and was afterwards sold and implemented for more than thirty other companies in the same industry.
The longest-lived belongs to a pasta manufacturer: two hundred people, about forty million dollars a year, and for twenty-five years the whole business has run on a system Sergii wrote for that plant and has looked after every one of those years - payroll, contracts, the production plan, barcodes and the hand-held terminals on the shop floor, tax planning, profit, the balance sheet and the P&L, all off the same numbers. The layer built on top of it now prices every product from its real cost and names, each day, the lines selling below their thresholds, without waiting for the month to close.
That is the same problem as yours, in a different industry: a deterministic layer that owns the arithmetic, and a reasoning layer that explains it. With Claude Code we build whole systems - front end, back end, integrations between systems built decades apart, and the agents themselves - and we run them as a fleet, more than a hundred agents on a single build, in parallel and under review. If it is easier to see one running than to read about it, say the word and we will show you.
The definitions agreed line by line and written down. A read-only service that produces usable cash, the committed obligations, the debtor ageing with expected dates and the ninety-day projection - reconciled so you can check it against your own bank statement. And out of that, the fixed price and the timeframe for the rest of Stage 1, with the fee for the step credited against it.
Everything it produces - the code, the definitions, the deployment - is yours whether or not you go further. What we need from you to start is the read-only connection to the NZ entity, your buffer and threshold figures, and an hour on a call where we walk the definitions against real rows.