Inside the Architecture:
How an AI CFO Agent Actually Gets Built

Post #6 of 50 — The CFO & AI Series

In Post #2, I described what an AI CFO agent does — it pulls data, cleans it, calculates KPIs, generates reports, and sends them. Every day. Automatically. Several people asked the obvious follow-up: how? This post is the answer.

The phrase "AI agent" sounds opaque by design. It conjures images of machine learning pipelines, cloud infrastructure, and engineering teams. The reality — for the specific problem of finance reporting automation in a 50–200 person company — is considerably more accessible. You don't need a developer. You need a clear picture of what connects to what.

The full architecture, layer by layer

An AI CFO agent has three layers: source systems (where the data lives), the agent layer (where it gets processed), and outputs (where it lands). Here's what each layer contains and how they connect.

The agent doesn't "think" about finance in the way a CFO does. It executes a defined workflow — reliably, on schedule, with the same logic every time. That consistency is actually one of its main advantages: the KPI definitions don't change depending on who ran the model, and the report doesn't arrive late because someone had a meeting.

What the agent layer actually runs on

This is the question I get most often when I describe the architecture. The honest answer: it depends on how far you want to go. For the basic version — daily data pull, KPI calculation, email report — you don't need AI at all. You need scheduled automation (Make.com, n8n, or even a Python script) and clean data connections.

The AI layer becomes valuable for three specific tasks: anomaly detection (flagging transactions that don't fit the pattern), narrative generation (writing the variance commentary in plain language), and predictive projection (using historical patterns to improve the 14-day cash forecast). None of those require a custom model. They can all run on a general-purpose LLM with a well-designed prompt and clean input data.

Which parts are actually hard to build

Not everything in this architecture is equally difficult. Here's an honest breakdown of where the effort actually goes — and what tends to break first.

Component	Effort to set up	What breaks / what to watch
Bank feed connection	Easy	Open banking APIs are well-documented. Main issue: some smaller banks don't support them yet — manual CSV upload as fallback.
Accounting software export	Medium	API quality varies by vendor. Xero and QuickBooks are excellent. Pohoda (common in CEE) requires more custom work. Data format inconsistencies are common.
Data cleaning rules	Hard	This is the real work. Every company's chart of accounts is different. Normalisation rules need to be built manually and tested against months of real data before they're reliable.
KPI calculation logic	Easy	Once data is clean, formulas are straightforward. The main risk is definition drift — make sure everyone agrees on what "gross margin" means before you automate it.
AI narrative generation	Easy	A well-structured prompt with the delta data produces good variance commentary. Prompt needs tuning for tone and length, but this is hours not days.
Report delivery (email/Slack)	Easy	Standard integrations. Main failure mode: email formatting breaks on mobile. Test on multiple clients before going live.
14-day cash projection	Medium	Accuracy depends on AR/AP data quality. If clients pay late unpredictably, the projection will drift. Flag confidence level in the output rather than presenting a single number.
Alert threshold logic	Easy	Set thresholds conservatively at first — too many false alerts and people start ignoring them. Tune over 4–6 weeks of real operation.

The one thing that takes longer than expected

In my experience building this, the data cleaning layer took three times longer than I planned. Not because it's technically complex — but because you don't know what's wrong with your data until you start looking at it systematically. Duplicate vendor entries. Transactions posted to the wrong cost center. Invoice categories that changed when someone updated the chart of accounts two years ago and didn't tell anyone.

This is not a failure mode. It's actually one of the most valuable outputs of building this system: you discover what your data quality actually looks like, and you fix it permanently rather than working around it every month when you close the books.

What "without pressing a button" actually requires

Full automation — where the CEO's inbox has fresh numbers every morning without any human action — requires three things to be stable: reliable data connections, a scheduler that runs even when nobody is watching, and an error-handling layer that catches failures before they produce wrong output.

The scheduler is the simplest piece. A cloud-hosted cron job (or Make.com's scheduling feature) handles this for almost no cost. The error handling is where most first-version implementations fall short — when the bank API is down or the accounting export is malformed, the agent needs to fail visibly and loudly rather than silently sending an empty or incorrect report.

Building the error handling properly took about a week of additional work after the "happy path" was running. It's not glamorous. It's what makes the difference between a demo and a system you can actually trust at 7:30 on a Monday morning.