Post #6 covered the architecture. This is what happened the first time it actually ran — and the data-quality problem it quietly exposed.
The examples and architectures in this series are my personal educational, non-commercial experiments; they are not an offer of IT or consulting services.
In Post #6, I walked through the architecture behind an AI CFO agent — the systems it connects to, the five-step pipeline, and how a report ends up in an inbox without anyone pressing a button. This post is about the first time that pipeline actually ran end to end and produced something a CEO read over coffee.
The report, the figures, and the conversation below are a composite illustration, put together from patterns I've seen repeat across different projects; they don't describe a specific company, dataset, or person.
The report itself looked like exactly what it was supposed to be: a one-page summary generated automatically overnight, covering revenue for the trailing 30 days, gross margin, and a cash runway projection. Two of the three numbers were correct. The third one wasn't — and it happened to be the number the CEO cared about most that morning.
| Metric | What the report showed | What was actually true |
|---|---|---|
| Revenue, trailing 30 days | €187,400 | Correct |
| Gross margin | 41.2% | Correct |
| Cash runway | 14.2 months | Actually 9.8 months |
Nobody flagged the runway number as suspicious because it looked plausible on its own. What caught it was memory, not analysis. The CEO had reviewed a rough runway estimate with the accountant a few weeks earlier — somewhere around ten months — and the automated report now claimed fourteen. That's not a small revision. That's the kind of gap that makes someone stop and ask a question instead of forwarding the email.
"Last month we were at about ten months of runway. Now it says fourteen? What changed?"
Nothing had changed operationally. What had changed was that, in the week the report was generated, a €120,000 short-term loan drawdown had landed in the bank account — money the company would need to repay, not revenue it had earned.
The agent's cash-flow module pulled every inflow from the connected bank feed and used it to project forward. It had no rule for distinguishing an operating inflow — a client payment — from a financing inflow — a loan drawdown, a capital injection, anything that comes with an obligation attached. To the pipeline, €120,000 was €120,000. It landed in the account, so it counted as cash available to burn, and the runway projection stretched accordingly.
"The agent didn't know the difference between money you earned and money you have to pay back. That distinction is obvious to any accountant. It has to be taught to a system explicitly — nobody ships that logic by default."
This is not a dramatic failure. It's a specific, fixable gap in how a data source gets interpreted — and it's a very common category of mistake the first time a reporting pipeline touches real bank data instead of a clean sample file.
Two things were added to the pipeline before the next report went out. First, a classification rule that separates financing activity from operating activity before any cash-runway calculation runs — so a loan drawdown, a repayment, or a capital injection gets flagged and excluded rather than blended into "cash in." Second, a sanity check that compares each new figure against the prior period and holds the report for manual review if any number moves more than a set threshold, instead of sending automatically.
Neither fix required rebuilding anything. Both came directly from watching one real number be wrong in front of the person who would notice.
In my experience, the report that goes out clean and correct doesn't teach you much about whether a system is trustworthy — it just confirms that the easy case works. The report that's wrong, caught, explained, and visibly fixed is what actually builds trust, because it shows what happens when something breaks. A system that fails silently loses trust permanently. A system that fails loudly, gets caught, and gets corrected earns exactly the kind of scrutiny that makes it safe to rely on later.
Post #8 covers what happened a few weeks later, when the agent flagged a problem that turned out not to be one — and what that taught me about tuning alerts so people don't start ignoring them.
Would you trust a number from a system after catching it wrong once?
No spam. One post per week. Unsubscribe any time.