My thoughts on OpenAI CFO's lessons from building an AI-native finance function

Sarah Friar wrote the best public account of an AI-native finance function. Here's what matches what we see inside real companies, what's missing, and the map I'd start with.

Hey Finance Engineers,

Last week, OpenAI’s CFO Sarah Friar published her lessons from building an AI-native finance function.

If you haven’t read it yet - do. It’s the most useful thing a sitting CFO has written about this transition, and it’s rare to get this view from inside the company with every AI advantage available.

Her two ambitions: a zero-day close, and forecasting that continuously updates itself.

Her five lessons:

1. Give everyone access but pair it with structured experimentation.

2. Redesign workflows around decisions instead of automating steps.

3. Let finance people become builders.

4. Pair speed with accountability.

5. Measure value per unit of intelligence - not seats bought.

I nodded through most of it. We’re building AI finance functions for companies every week now, and her lessons match what we see.

But reading it, I kept thinking: this is the view from the top of the mountain. Most finance teams are at the bottom, asking a more basic question - where do I start on Monday?

So this issue is my field notes on top of her lessons. What we do with real customers, and the two risks she didn’t mention that I see everywhere.

Where I’d start: draft the map

When we start with a customer, we don’t start with AI. We start with a map:

→ Every workflow the finance team runs - what finance people do, day to day
→ Every data flow - where numbers come from, where they go
→ Every person - who owns what

The best way to create an agent is to take the experience and knowledge of the person who does the work and automate what that person does. Not what the process chart says they do. What they do.

And while mapping, ask the uncomfortable question: is this workflow even worth automating as is - or does the process itself need to change first? Sometimes what you find is a person manually re-typing data that should just flow through an MCP connector. Automating that manual step preserves a workaround. Fixing the flow deletes it.

This maps directly to Sarah’s second lesson - redesign around the decision, don’t automate the step. Same idea, from the trenches: the map is how you see which is which.

Then pick your direction: speed or hours

Once the map exists, there are two good entry points:

1. Add speed to what you use most often. The weekly report. Daily updates. Marketing performance. Weekly CFO metrics. Things that already work but arrive too slowly to act on.

2. Reduce the hours. Ask: which workflow eats the most manual hours in the team? Start there. Every hour you free comes back as strategic capacity - or gets reallocated to something the business needs more.

Both are right. What matters is choosing deliberately instead of automating whatever someone got excited about on a Friday afternoon.

The two risks

Sarah’s lessons come from a company with strong engineering culture and infrastructure. Here’s what happens at normal companies - we see both of these constantly.

Risk 1: the shadow automation problem

There’s a honeymoon period when everyone on the team starts building - their own apps, their own automations, their own little solutions. It’s great. Genuinely. For a while.

Then you realize: it’s all saved on personal laptops. And every automation lives in exactly one person’s head. If that person leaves, the automation leaves with them. You haven’t built an AI-native function - you’ve built a collection of personal magic tricks.

The fix is boring and non-optional: set up GitHub for your finance team. Yes, finance. A new sentence for most CFOs, I know.

The rule we set: anyone who builds any automation or agent must ask Claude to make a skill from it - a file - and that file goes into the team’s GitHub folder. That’s it. Now the knowledge survives the person, the team can reuse it, and you can see what exists.

(If GitHub sounds intimidating: it’s a drive for your code and skills, with history. Claude will walk you through the setup in an afternoon. This might become its own issue - tell me in the chat if you want it.)

Risk 2: attention decay

This one worries me more.

When agents start working - and working accurately - people begin to trust them. Then, some weeks in, they begin to over-trust them. They stop checking. Attention decays exactly as fast as accuracy builds confidence.

But agents can still hallucinate. Accurate for six weeks doesn’t mean accurate in week seven, on the weird invoice, in the messy month.

So this is a genuinely new skill for finance teams: staying attentive when the system is usually right. Auditors have trained this muscle for decades. Now every reviewer of agent output needs it.

What helps in practice:

→ An audit log on every agent - full visibility into what the agent did and why, so checking is easy instead of heroic
→ Confidence scores per data type - so attention goes where the model itself is least sure
→ The approval gate as a hard block - the human sign-off isn’t a courtesy, the workflow physically stops without it

Sarah’s fourth lesson - pair speed with accountability - is this, seen from the org-design side. Mine is the behavioral side: accountability structures only work if the humans in them are still paying attention.

So, where do I start on Monday?

Friar’s article is the strategy. This is the Monday morning version:

1. Draft the map - workflows, data flows, people

2. Pick the entry: speed or hours

3. Set up GitHub before the shadow automations multiply

4. Build the attention habit before the trust gets comfortable

5. Cash flow, dashboard, rev rec - in whatever order your map says

The transformation she describes is real.

I see it land in normal companies every week. It just starts smaller, messier, and more human than any lessons list can capture.

That’s it for today.

Have you noticed the attention decay in your own team - or in yourself?

Tell me in the subscriber chat or comments. I think this might be the most underrated risk of the whole transition.

Subscribe (and stay for the ride)

If you made it this far, you’re one of us. Subscribe for the weekly drop and these specials.

Every issue: my real builds, step by step - the prompts, the skill files, the screenshots, and the mistakes I made. Plus interviews with finance engineers, starting soon.

Pro subscribers get the full library: every skill file and prompt from every issue, deeper tutorials and behind-the-scenes builds, and the subscriber chat, and the .md files.

→ If you’re a vendor and you genuinely have something to offer this audience, email me at team@thefinanceengineer.io or DM me on LinkedIn.

— Alyona