Alyona here. For those who found this newsletter recently: I’ve spent over a decade in finance, first in PWC, then as a CFO, then building Fuel, an FP&A software, and for the last two years, figuring out how AI fits into finance work. That’s what I write about here.

And right now, I’m living the biggest experiment of my career. After six years of building Fuel, we’re rebuilding the whole company around AI finance agents. We gave ourselves 3 months. Launch is September 29. I don’t know yet if it works. I share the journey in short weekly videos on LinkedIn.

But the videos are two minutes. And the things I most want to tell you, the actual finance engineering, don’t fit in two minutes. How we structure agent context. How we fight hallucinations.

So I’m going to try something: every now and then, between the regular skill issues, a building-in-public special. One piece of what we’re building, with everything you can take for your own work. This is the first one.

And it’s about the part that took us longest.

The context layer.

Some of you will remember the finance context file issue from June, one file that makes every AI answer about your business better. This is that idea, grown up. What happens when one file becomes a system.

Let’s go.

Agents fail on context

You can have the best model, the cleanest workflow, the most beautiful skill files, and the agent will still calculate revenue wrong. Because nobody told it how revenue works in this company.

Which streams exist. Which geographies, which SKUs. Whether that annual contract is recognized ratably or on delivery. What “payroll” even means when it lives under four names in the GL.

None of that is in the model. All of it has to be written down. And in most companies, it’s written down nowhere. It lives in the finance team’s heads, which is a lovely place for knowledge to live right up until someone goes on vacation.

So before our agents could do anything impressive, we had to do something deeply unimpressive for an AI company: sit down and write.

Why 17 context files, not one

The obvious move is one big context document. Everything about the company, one place, feed it to everyone.

We tried. And here’s the thing about context, too much confuses the model exactly like too little does. Hand an agent everything, and it wades through vendor classifications looking for a revenue rule. Like asking someone to find one sentence in a book by giving them the whole library.

So we split it. Seventeen single-topic files:

Why seventeen? Not a framework we invented. A pattern we kept meeting, six years, hundreds of companies, the same seventeen things that actually get asked about.

No agent we built reads all 17. Each one loads only what its task needs. Rev rec pulls the revenue model and accounting policy. AR pulls customers and contracts. The agent reads an index first, then takes only what’s relevant.

Faster. Cheaper (!). And accurate, because the model isn’t digging through vendor rules to find a recognition policy.

One topic per file. Every file carries an owner and a last_updated date. And the quality bar for the whole library, the line I’d frame and hang in the office:

If a new team member could answer a client’s question using only the context files and the data, the context is done.

Not “does it look complete.” Could a stranger run this company’s finance from what’s written here.

Where context comes from (the one-week collection plan)

Day 1-2: Mine what exists.

Your onboarding docs, board decks, accounting policy memos, that one Notion page someone made in 2023. Most companies have 30% of their context already written, just scattered.

Day 3: Run the kickoff interview.

We have a pool of questions we ask every customer on a recorded call; you can do the same with your own team. Ask your controller: how do we recognize revenue, stream by stream? Ask your analyst: which metrics have exclusions and why? Record it. The transcript becomes your first drafts - Claude turns a call recording into structured context files in minutes.

Day 4-5: Read what nobody can tell you.

Some rules are written nowhere. They live inside an Excel file’s formulas, a Google Sheet’s structure, a system’s settings. Open your main model and ask: what rules is this file enforcing?

Then apply the stranger test and fill the gaps it exposes.

You can’t just write your context once

A company is a living organism. Pricing changes. A new revenue stream appears. A vendor gets reclassified. The close gets a new step. And every one of those changes quietly invalidates a line in some file, without telling anyone.

We tested a format where our finance engineer refreshes each customer’s context manually. The verdict: at least once a month, something needs updating. Every time. Small edits, usually. Never zero.

Which means context isn’t a setup task. It’s a relationship. You don’t write it once and frame it, you keep showing up, or it stops being true.

So the next thing we’re building is a context-updating agent.

It watches where the team communicates, Slack, email, calls, drafts the updates, and before anything changes, sends them to a human for approval: the CFO, the Head of FP&A, or our finance engineer. Regular readers know the religion by now. The agent drafts. A human signs off. Even for the context itself. Especially for the context itself.

Nothing here stays stable. That stopped being frustrating the day we accepted it and started designing for it.

Steal the structure

You don’t need 17 files to start. You need this:

1. One topic per file. The test: could an agent load just your COA mapping without reading everything else?
2. Every file has an owner and a date. Context without an owner rots. Context with an owner just rots slower, which is the best anyone can promise.
3. Write until a stranger could answer. If a new hire could answer a question from your context alone, it’s done.
4. Schedule the refresh. Monthly, minimum. Put it in the close checklist, or it won’t happen.

Start with three files: your business model, your COA mapping, your metric definitions.

The wider point

Everyone asks me what’s hard about building finance agents. They expect the answer to be the AI.

IMHO, it’s not the AI. The hard part is that most companies have never written down how their own finance works. The agents just made it visible.

Which is the funny part, honestly. The work we’re doing right now, turning judgment into files, would be valuable in a world with no AI at all. It’s the documentation every finance team was supposed to write and never had time to. The agents didn’t create the need. They were the deadline.

— Alyona

Seven weeks ago I wrote Issue 001 and called this newsletter The Finance Engineer. Half-serious, honestly.

I told you the story of how Clay invented the “GTM Engineer” and a whole career path grew around it, and I said finance was next. The role was already real, I knew that. It just didn’t have a lot of job postings yet.

Six weeks later, it does. Hundreds of them.

Search interest for “finance engineer” is up 700% in 2026 vs 2025.

The Google search for for “finance engineer” is up 700% in 2026 vs 2025.

Now look at the spike. The single biggest week of the year is the week of May 5th. That’s the week Anthropic dropped their finance agents and half of LinkedIn lost its mind (Issue 002, the one where I tested them all weekend).

From a couple of jobs to hundreds

When I started this newsletter in June, I did a LinkedIn search for “finance engineer” jobs. There were a couple. Literally - I could read every single posting over one coffee.

I ran the same search this week. Hundreds. Just on LinkedIn.

And it’s not startups you’ve never heard of. Figma is hiring for this. Mercor (the $10B one) is hiring their first Agentic Finance Engineer and calling it “a rare, foundational hire.”

The salaries: Mercor: $175K-$250K base. Figma: $169K-$245K.

For context, that’s senior engineer money, for a role that reports into Finance.

Same role, seven different names

Nobody’s agreed on what to call it yet, which is very on-brand for a role that didn’t exist a year ago.

On the market right now the same job is posted as: Finance Engineer, Agentic Finance Engineer, FP&A Data Engineer, Finance Systems & AI Engineer, Strategic Finance Systems & AI, Finance Automation Manager, Finance AI & Technology Analytics Architect.

Seven titles, one job. If you’re searching for these roles (or benchmarking one), search all the names.

Here’s the role itself, mapped across every posting I read:

Every single posting sits inside Finance. Not IT, not engineering.

What the role requires (I read every JD)

I went through all of these line by line (and ran through Claude, of course).

Here’s the skills map - save it, benchmark yourself against it, or use it to write your own posting:

Two things jumped out reading these back to back.

First: MCP is in job requirements now. A protocol most finance people hadn’t heard of a year ago is a hiring criterion.

Second: nobody is hiring a prompt person. Every posting pairs the AI stuff with boring, real finance judgment - knowing when an automated output is right or wrong. The foundation didn’t go anywhere. It’s the price of entry.

Finance is a portfolio job now

For our entire careers, finance hiring worked on credentials. Your degree, your CPA, your years at the right companies. Nobody ever asked an FP&A candidate to show something they built, because there was nothing to show. Your work lived inside someone else’s ERP.

That’s over. The postings ask for evidence now. One of them literally says: we will ask for examples. Real, shipped things - an automation that killed a manual process, a Claude skill your team actually runs, a dashboard you vibe-coded, a close that went from 7 days to 2.

Which means finance just became a portfolio job. Like design. Like engineering. The resume says what seats you sat in; the portfolio proves what you can build.

And here’s the good news if you’ve been building along with me: you already have one. The skills from Issue 004. The human-in-the-loop patterns from Issue 007.

Stop treating those as experiments and start treating them as your portfolio - screenshot the before/after, write down the hours saved, keep the skill files.

How we define it at Fuel (steal our JD)

We’re hiring Finance Engineers ourselves right now - it’s the core role of the whole pivot we’re doing. So here’s exactly how we define it, and yes, you can steal this JD wholesale if you’re hiring for one.

Full JD is here. If you want to apply - even better, we’re actively interviewing.

I’m looking for 50 CFOs to interview

I’m looking for 50 CFOs and heads of finance to interview as we pivot Fuel around AI agents.

If you say yes, it’s not a one-way extraction: I’ll show you the agents we’re building, I’ll help with whatever AI questions you’re stuck on in your own finance setup, and I’ll gift you a forever-free paid subscription to TFE ($199/year), with all the files and skills.

Sign up here.

Takes a minute, and I’m booking every call myself via email or LinkedIn.

Last chance to grab the Claude Guide

A lot of you found me only after The Finance Engineer launched in June - and much of what I cover there assumes you’re already comfortable with Claude.

This spring we published the Claude Guide for CFOs & finance teams - the most comprehensive guide on the internet for setting up Claude in finance work. Since then it’s been downloaded by 10K+ finance experts, including teams at Pinterest, Coca-Cola, Adidas, Atlassian, Okta, and Netflix.

We’re now preparing v2, because a lot has changed since spring (Fable alone deserves its own chapter).

So this month is the last chance to grab the current version. It covers the fundamentals that haven’t changed (setup, skills, prompts, Claude in Excel) and if TFE ever feels like you walked into the middle of a conversation, this guide is the beginning of it.

Grab the Claude Guide here.

Till next week,

Alyona

Okay, I’ll just say it. 9 out of 10 companies I talked to last week weren’t ready for AI. (I’m interviewing CFOs right now as we pivot Fuelfinance, my company, to AI agents - story at the end).

This is the biggest problem in the industry right now, and nobody wants to hear it because the fix is boring: everyone wants AI, but almost nobody spent the last 3 years building the data foundation for it.

I know companies that spent 2-3 years just getting their data ready for automated reports and dashboards. Now they’re ready for AI too. But it didn’t happen in a day, or a week, or a month.

So today is the issue I keep promising. How to actually prepare your data for AI. This one’s not a prompt or a Claude skill.

It’s the 6 layers of checks we run before setting up any agent or automation.

What does the heist movie have to do with AI?

I rewatched Ocean’s Eleven the other night. It hit me: the actual heist takes like ten minutes. The rest of the movie is prep. Blueprints, guard rotations, a literal replica of the vault they built just to rehearse in.

Danny Ocean doesn’t walk into the Bellagio and wing it. The vault scene looks effortless because someone spent months on the boring parts.

And everyone in finance wants the vault scene right now. CEOs especially. (I’m a founder, I get it). Agents running the close. A board deck while you sleep. Nobody wants to be the guy in the warehouse memorizing guard rotations.

Which is how you get the scene I’ve watched all year: a CFO opens Claude, connects it to QBO, asks for a forecast.

And then the numbers are wrong. Because “payroll” lives under four different names across two entities. Because $3M of intercompany was never eliminated. Because February’s bonus run never synced.

You can’t automate chaos. AI just does the wrong things faster.

And in finance, 99% correct is still wrong.

“Clean” for your accountant ≠ “clean” for AI

Ask your accountant if your data is clean and they’ll say yes. And they’re not lying - by their definition, it is. Books close, taxes get filed.

AI needs a different definition. Structured, consistent, connected across systems. QBO, Stripe, your CRM, payroll, ops tools - each one holds a piece of the picture, and the model can only reason across them if they actually agree with each other.

Here’s the full cleanup we run before any dashboard, forecast, or agent goes live. Real numbers from real cleanups (anonymized, obviously).

Layer 1. Category mapping & chart of accounts

One reporting structure. Not one per entity per era per bookkeeper.

Real example: a client’s payroll showed $95K/month as a single line in QBO. After mapping it against the payroll system, $61K belonged in COGS. Gross margin error: 12 percentage points. Every AI analysis of that P&L before the fix was fiction.

Layer 2. Intercompany elimination

If you have more than one entity, this is where consolidated numbers go to lie.

Real example: a balance sheet showed $204K cash; the bank showed $189K. The gap: a $15K transfer between two entity accounts, recorded as income in one and never eliminated. Claude will happily forecast off that phantom $15K forever.

Layer 3. Splits & allocations

One line in QBO is not a data model.

Without this layer, “analyze our R&D efficiency” is a prompt with no possible correct answer.

Layer 4. Cross-system joins

This is where the actual analytical power lives. Each system holds a piece of the picture. Connect them.

Layer 5. Outlier detection

Anything weird gets flagged before it enters the run-rate.

Layer 6. Accounting review

The most value-dense layer and the most overlooked. Most fast-growing companies have accounting gaps that create noise in every report.

The final gate: cross-system reconciliation

One question: do the numbers in each system tell the same story? If they don’t, find out why before anything downstream gets built.

Funny thing about every example above: not a single one was an AI problem.

“But models keep getting smarter”

I know. Won’t Fable-level models just… handle the mess?

Honestly, I wish. It’s the opposite. Remember the human-in-the-loop issue - the better the output looks, the less you double-check it. A smarter model gives you a more convincing analysis of your broken data. It finds patterns in your duplicates. It writes a whole confident story about a margin trend that’s actually a missing accrual.

The output gets prettier while the numbers stay exactly as wrong.

That’s why data is Level 0.

Step 0, in one checklist

Before you build a single skill, honestly answer:

1. Is there one chart of accounts - or one per entity per era per bookkeeper?

2. Does revenue in your billing system match revenue in your GL? To the dollar, or to a known, explained gap?

3. Does balance sheet cash tie to bank statements?

4. Is intercompany eliminated in every consolidated view?

5. Do you know where every number in your board deck comes from - one source of truth, or six spreadsheets that “kind of” agree?

6. Are one-time items flagged and out of the run-rate?

Can’t check most of these?

Then you’re not ready for AI, you’re ready for a cleanup. Which is fine!! That IS the first step. Initial cleanup takes ~2 weeks depending on entities and the state of the books (sometimes a couple of months, I won’t lie to you). Then you get your vault scene.

Imho, the finance engineers who win with AI won’t be the ones with the best prompts and skills. They’ll be the ones whose data deserves the prompts.

How are things going at your company, Alyona?

New thing I want to try: sharing the personal side at the end of each issue.

Last week I posted something I never thought I’d post. That Fuel, as it was, didn’t find product-market fit. Six years of building, ~$3M ARR, a full demo calendar, great feedback - and still. You can feel when it’s PMF and when it isn’t. It wasn’t. Typing that sentence publicly took me about a week.

So we’re taking 3 months to rebuild the company around AI agents that run FP&A. Agents doing the work (close the month, run variance analysis, update the forecast) with a human finance engineer reviewing and approving. We rebuilt one customer’s entire month-end close this way, and 7 days of work became 2. That call is the reason we’re betting the company on this.

Do I know how it ends? No. That’s kind of the point of sharing it now and not after it worked. I’m documenting the pivot weekly in videos on LinkedIn, and the longer thoughts will live here - at the end of each issue, or sometimes as standalone posts.

Write in the comments: what would your team hand to an agent first?

Leave a comment

Till next week,

Alyona

Confession: this issue was supposed to be simple.

The plan was “how to build your cash flow forecast with Claude.” One issue, one guide, done.

Then I started listing all the cash flow forecasts I’ve actually seen across businesses, and the list refused to end:

→ the CFO/CEO playground - the one you use for decisions and what-ifs (and even this one splits into several types, depending on how deep you want your assumptions to go)
→ the 13-week cash flow forecast
→ the monthly cash flow forecast
→ direct vs indirect
→ and every flavor of the above for SaaS, manufacturing, services - early stage, growth, enterprise…

One forecast, it turns out, is never one forecast.

So instead of one issue, you’re getting a series. Cash flow, type by type, each one as a working build.

Today we start with my favorite: the playground.

Subscribe now

What a playground is, and why every CEO wants one

We built this one at Fuel for ourselves first. Then we noticed the pattern: every CEO and CFO eventually asks the same question, usually right before a board meeting.

“What happens to our cash if we...”

Cut this expense. Add two hires. Raise in July instead of September. And they don’t want a report next week - they want to move a number and watch the ending cash balance react. Right now, while the thought is still warm.

That’s a playground. Not the forecast of record, not the 13-week treasury view - the sandbox. Every future expense visible in detail, every line editable, and the monthly free cash flow, end-of-year forecast, and cash ending balance recalculating live as you play.

The problem: building one by hand in a spreadsheet takes days, and it breaks the first time someone drags a formula the wrong way. So we turned the whole thing into a Claude skill. You install it once, hand Claude your numbers, and it builds the playground for you - with the rules that keep it honest baked in.

How the CF playground skill works

Subscribe now

Four stages, and the second one is the whole point:

1. Inputs: your historical P&L (monthly), payroll roster, software spend, revenue roster with each customer’s billing frequency and days-to-pay, and your forecast assumptions. Nothing invented: if something’s missing, it asks.

2. Data-quality gate: before building anything, it checks that the P&L ties out, MRR cascades balance, cash reconciles to $0, AR and deferred roll forward. Fails → ask, never fudge. (Regular readers will recognize the religion: the doer doesn’t get to fudge its own inputs.)

3. Build: one self-contained file, six linked tabs: P&L Playground, Software, Payroll, Active MRR, Cash Inflow, Cash Flow. Actuals locked, plan editable, formulas always computed.

4. Verify & ship: it re-runs the checks on the baked file before handing it over.

And the rules baked in are the ones that make finance models trustworthy instead of pretty: actuals are locked (your edits only touch plan months), expenses keep their sign (a typed minus won’t flip a cost into income), cash ≠ net income (AR and deferred revenue tracked properly, never a naive cumsum), and MRR cascades must balance. The stuff that silently breaks hand-built models, made structurally impossible.

The output is one offline HTML file. Send it to your CEO and they can play without touching your source data.

Set it up (5 minutes)

This is a Claude skill - install once, then just ask Claude to build or update a playground.

You’ll need: a Claude plan with Code execution and file creation turned on. Skills don’t run without it.

On Claude web / desktop / Cowork:

1. Turn on code execution: Settings → Capabilities → Code execution and file creation. (On Team/Enterprise, an owner controls this in Organization settings → Skills.)

2. Go to Customize → Skills.

3. Click ＋ → Create skill → Upload a skill (attach the skill file you can find below).

4. Select the zip.

5. Toggle it on.

Then start a chat and say: “Build me a cash flow playground from these numbers” - and attach your P&L, payroll, software spend, and customer roster (billing frequency + average days-to-pay per customer).

That’s it. First build takes a few minutes. After that, updating for a new month is one sentence: “here are June actuals, promote June to actual and extend the plan.”

My skill file (built and tested by ~20 finance engineers)

Here it is, the CF forecast playground skill. Install the skill, feed it your real numbers, and then do the thing your CEO would do: go to the plan months and cut your single biggest discretionary expense. Watch what happens to end-of-year cash.

Read more

Let’s talk about the least glamorous days of your month: the ones you spend recognizing revenue.

You know the ritual. Terms out of the contracts. Invoices out of Chargebee. What actually posted to QuickBooks. Did the cash truly land. Match it all line by line, apply the schedule, make the calls - and hope this month’s logic matches last month’s, because nobody wrote last month’s down.

Three systems that have never been introduced, and you in the middle, translating.

Today’s issue is a build log: how a finance person on our team (no engineering background) turned that ritual into an agent, the exact structure so you can copy it, the five questions to encode your own rev rec rules - and a live walkthrough on July 9 where you can watch the full thing tear through a real pipeline.

Let’s go.

Why this is the process worth automating first

Rev rec is the top line of the P&L, and the top line drives valuation - get it wrong and every number under it inherits the error. A profitable company can report the wrong profit because of how one line at the top was recognized.

And it’s the easiest number to get wrong, because recognition and cash keep entirely separate schedules. A $120K annual contract paid upfront in January is $10K earned and $110K deferred. Every finance person knows this cold. And still it gets booked wrong constantly, because between MRR, usage-based, and milestone models, contracts that don’t match billing, and payments that may or may not have landed, “the right answer” dissolves into 200 small judgment calls a month.

The real risk is that two competent finance people can recognize the same contract two different ways - and the person who discovers which way you picked is your auditor. Processes that live in one person’s head are loyal to the person, not the company.

Rule-heavy. Monthly. Painful. Expensive to get wrong. That’s the exact profile of a perfect first agent.

The agent, and the structure to steal

Here’s how ours runs. The architecture matters more than the tools, though.

→ A. Contract Parser: extracts client, term, MRR, and billing cadence straight from the contract (DocuSign / Notion).
→ B. Billing Sync: pulls invoices and plan changes from Chargebee, matches them to the contract.
→ C. Books Reconciler: compares billing to what’s posted in QuickBooks, flags every gap.
→ D. Rev Rec Validator: checks deferred revenue and timing against ASC 606.

Notice the shape: each step compares two sources that should agree, and flags where they don’t. Contract vs billing. Billing vs books. Books vs recognition rules. That’s the whole trick. An agent like this isn’t magic - it’s your reconciliation ritual, written down, running nightly.

It produces four outputs: a Break Report (clients where billing ≠ contract or books), Timing Alerts (revenue booked in the wrong period), a Clean Bill (clients fully reconciled, contract to recognition), and an Audit Trail - timestamped evidence for every check.

Everything lands in Slack and Notion, with optional auto-correction posted back to QuickBooks.

The reconciliation that used to eat days of the close now runs in minutes.

Step one you can do today: write your rules down

The agent’s real superpower isn’t the automation. It’s that the rules exist explicitly at all. Before any of the plumbing, we had to answer five questions in writing - and answering them is valuable even if you never build anything:

1. What triggers recognition? Delivery, time elapsed, usage, milestones? Per product line, not “it depends.”
2. What’s the unit of recognition? Monthly ratable? Daily? On-invoice for one-offs?
3. What happens on a plan change? Upgrade mid-month, downgrade, cancellation, refund - each needs a written rule.
4. When is cash confirmed? Invoice sent ≠ paid. What’s your rule for revenue on unpaid invoices past X days?
5. What’s materiality? Below what threshold does a break get logged but not chased?

If your team can’t answer these in writing today, that’s not embarrassing - that’s the discovery.

Most rev rec policies live in someone’s head. This is how you get them out. And once they’re written down, you’ve done the hard part of building the agent: everything after this is plumbing.

This is what “finance manager → finance engineer” looks like

This agent wasn’t built by an engineer - it was built by Anneli, a finance person on our team who got curious.

Her rev rec judgment didn’t go anywhere. It got encoded, once, into something that runs while she does work that actually needs her.

Come watch it run, live

— Alyona

Short one today. One habit, and it’ll do more for your AI finance outputs than any model upgrade you’re waiting on.

Human-in-the-loop: you build your prompts, skills, and agents so the AI stops, shows its work, and waits for your sign-off before it keeps going. No running start to finish and handing you something “finished.”

Obvious, right? That’s what I thought too. Then I caught myself doing the exact thing I tell everyone else not to.

Back when we all had Fable, I almost talked myself out of this habit. (The full saga is in my Fable vs Opus issue.) Fable caught a $30M tax problem Opus missed. It didn’t just audit Opus, it audited me. The first model I’d call senior on my own tests, the kind that catches what a good controller catches (and even more!).

For about a week I let myself believe in the dream: autonomous finance loops, hands off, go make coffee, come back to a finished board pack.

Here’s the thing about trust, though. The better someone is to you, the less you double-check them. Works with people. Works, apparently, with AI models. And the moment you stop checking is the exact moment it tucks a mistake that size into a balanced, perfectly footed model and lets you carry it all the way to the board meeting before you notice.

So I went back to the rule I’d almost dropped.

What human-in-the-loop looks like in my finance skills

Here’s my three-statement skill. Map the template, pull historicals, build the statements, the usual. Then the part I added, the part that earns its keep.

The exact language:

The model builds. I sign off. And the one who did the work never gets to decide the work is done. Doer and grader, never the same hands.

How to add it to any prompt, skill, or agent

Two ways to get yourself into the loop:

1. Eat the elephant one bite at a time. Chop every multi-step workflow into small steps, and sign off after each one. No swallowing the whole model in a single run.

2. Tag your context with confidence. On anything you hand the AI, mark how sure you are, so it knows when to stop and check with you instead of guessing. (More in my context issue).

Or, here’s my prompt

Don’t want to retrofit your skills by hand? Paste this and let Claude do it, with you in the loop:

That’s it for today.

I’m prepping the next build issue while surviving the European heatwave, currently at the exact energy level of Haku, my husky, melted into the floor.

I’m also lining up the first round of interviews with finance engineers. Tell me in the comments who I should talk to. I don’t care how “cool” the company is. If you or a finance friend built something worth sharing, say so.

Leave a comment

— Alyona

Bad news first. The smartest AI on earth still can’t read your mind, and right now the mind is, unfortunately, where most of a business lives.

Good news. I built a skill that writes that context with you. It interviews you in chat, walks you through 16 layers of your business, and hands you the finished .md file at the end. It’s the same one our finance team of 20 runs on, and it’s at the bottom of this issue.

So before you implement AI, before you scale it, and well before anyone starts a token leaderboard, you write the context file and set up the data sources. This is step 0, before you do anything else.

Side effect: building this context makes the business less fragile. Right now too much of how your company runs lives in one person’s head, and the day they leave, it leaves with them. Writing the context is how you get it out of heads and into text.

Two rules before you write a word

It’s easy to get a context file wrong, and a bad one makes everything worse, not better. Two rules I live by.

At Fuel (my company) we thought building the agents would be the biggest challenge, and that once we had them, they’d cut 80% of the manual work.

Turns out building them wasn’t the hard part. Supporting them was. Once they exist, you have to keep feeding them the right context, the new finance rules, the new units, the new business streams, and that part never really stops.

And what surprised me most is that this context turned into a finance library the rest of the team uses. We have one at Fuel now that all 20 of our finance analysts and managers use, every day.

That’s where we’re going today. The full 16-layer map of what to write down, the trick that stops AI inventing numbers, and the builder file to do it all with. But first, the obvious question: what is context, really?

So what even is “context”

Imagine a new FP&A manager joins your team. On day one, you or your manager would sit them down and walk them through how everything actually works. If you’re lucky and someone does that for you. And if not, if that manager is you, figuring it out alone, then even better that you’re reading this.

Context is exactly that onboarding, written down. Everything you’d have to explain to a new hire on their first day.

• The business itself: revenue streams, history, types of expenses, business units

• Your key KPIs and goals

• The market you’re in

• Your chart of accounts

• How the team is set up

• And all those financial rules that live in your team’s heads and have never been written down anywhere

That last one is where most of the value hides. The undocumented rules.

If you’re a finance person, you know the case. There’s an xls someone manages, full of formulas and rules, and only the owner knows what the hell is going on in there. None of it is written down anywhere. It just lives in their head, and the day they leave, it leaves with them.

Which, when you say it out loud, is a genuinely insane way to run a company.

It reminds me of that bit in Severance (the Apple TV original), the office self who knows everything about the job and remembers none of it the second they walk out the door. Most finance teams are running a version of that.

Where the context lives

Before you write anything, know where to look. In my experience context sits in four places, and most of it is undocumented.

1. What’s already written. Existing docs, decks, prior notes, team onboarding.

2. Conversations. Call recordings and meeting transcripts. This is where the strategy and the why live.

3. Day-to-day messages. Slack and email threads, where decisions actually get made.

4. Your systems. The accounting tool, billing, payroll, the chart of accounts itself.

The written 10% is the easy part. The other 90% is in conversations, chat threads, and people’s heads.

The 16 layers of context

Here’s the structure I’d use. You don’t need all of them on day one, but this is the full map.

Foundation, who you are

1. General company context. Legal name, country, entity type, industry, business model, stage, currency, fiscal year.

2. Key facts and decisions. Strategic choices already made, known anomalies in the numbers, open decisions, and what’s coming in the next 3 to 6 months (a fundraise, a pricing change, a new product).

3. Glossary. Your terms, your metric definitions, your naming conventions. What you call things, and what you never call them.

Rules, how you operate

4. Business rules and policies. Who approves what spend, payment terms both ways, expense thresholds, capitalisation policy.

Read more

In this newsletter we build the skill set and the mindset of a finance engineer, the new layer landing on every job in finance.

Today’s a short one, more mindset than how-to. But first, someone sent me this and I haven’t recovered:

Earlier this year, an AI consultant told Axios that one of their clients spent $500 million on Claude in a single month.

They gave every employee a Claude license and never set a usage limit. People ran agents, agents ran agents, and an agentic workflow eats roughly a thousand times the tokens of a normal chat. Nobody was watching the meter. The bill just arrived.

The company stayed anonymous. The only mercy in the story. But it wasn’t a single accident. Uber burned through its 2026 Claude Code budget in 4 months. Microsoft started killing internal Claude licenses when engineers hit two grand a month each. AI bills are up 320% while the price per token has dropped 98% since 2022.

Tokens got 98% cheaper. The bills tripled.

Turns out, it’s a behavior problem.

Tokenmaxxing → efficiency-maxxing

And this behavior has a name. Tokenmaxxing. For about 2 years it was the whole industry’s mood, rewarded internally with, I’m sorry, actual leaderboards.

To drive adoption, companies built dashboards ranking employees by how many tokens they burned. Whoever used the most AI won.

Take a second with that. Grown adults with finance functions decided the path to the future was a scoreboard for who could spend the most company money.

Amazon employees reportedly started asking Claude to check the weather, just to climb. Meta’s leaderboard leaked and the reigning “Token Legend” had burned 281 billion tokens in a single month. Amazon eventually pulled the plug, and an executive had to send the most 2026 sentence ever committed to a company-wide email: “Please don’t use AI just for the sake of using AI.”

The president of AI at Replit called it “very dystopian.” His comparison was leaving every light in the house on and not caring about the bill. Generous, honestly. The lights at least do something.

When a measure becomes a target, it stops being a good measure. Reward people for burning tokens, and token burn tells you only one thing: who’s best at burning tokens.

We did a softer version of this ourselves.

One of our monthly company decks at FUEL had a slide. Token usage up 350% month over month. My first reaction was honest and slightly embarrassing: oh, wonderful, adoption is taking off.

I felt good about that slide for ten seconds. Then a smaller, more annoying thought arrived. What did we actually get?

Nothing. The line went up and to the right, it looked like progress, it had the shape of progress, and it told me absolutely nothing about whether we were a better finance team or just a pricier one. The most attractive meaningless chart in the deck.

Token burn tells you who’s spending. It never tells you who’s winning.

Why this is the CFO’s job now

Tracking AI ROI is the most valuable thing a CFO can do for a company in 2026.

I don’t mean cutting AI (we’re the finance engineers here). Making AI mean something.

This is the huge part of having a finance engineer mindset. no matter you’re an analyst, head of finance or a CFO here.

Every other line item in your business needs to have a goal. Marketing has a CAC. R&D has a roadmap. Sales has a quota. AI spend, in most companies, has none of that. Yet.

The polite word for the new era is efficiency. The honest one is accountability. And accountability lands on the person holding the budget.

That’s the role. Not the AI police writing tickets. The only person in the building still asking what all of this is for.

Strategies I’ve seen companies use

A few plays I’ve seen, roughly in order of how much they help.

→ Hard kill switches. Spend ceilings and auto-shutoffs at the agent, workflow, and team level. A runaway agent can rack up a six-figure bill in hours, faster than any monthly review catches it. Uber now caps agentic coding at $1,500 per engineer per month. Set the ceiling before you need it.

→ Banning juniors from AI. A handful of companies don’t give juniors LLM access. Two reasons. They think it slows the learning curve, and unsupervised juniors burn more tokens than seniors without producing better work. At Anthropic, of all places, the biggest token user is the head of tax. Most senior, most expert, pointing the most AI at the most valuable work.

→ Budgets by team, not by person. Individual budgets create the leaderboard problem, every user maximizing their own allocation. Team budgets create collective responsibility. Set the budget by team, alert at 50, 80, and 100%, let the team police itself.

→ Teach the team the cheap habits. Edit the prompt instead of stacking ten follow-ups. Start a fresh chat every 15-20 turns instead of dragging a 30-message history into every question. Small model for grammar and formatting, big model for the actual thinking. None of it is hard. Nobody does it until someone shows them. So I made a one-page cheat sheet. It’s at the bottom. Send it to your team.

→ The caveman method. A fun trick I learned on LinkedIn. You tell the model to “respond like a caveman.” It looks ridiculous and cuts output tokens close to half on routine work.

→ An AI ROI dashboard. A live view of what your AI spend is producing, broken down by team. Three things I’d put on it:

• Cost per task, human vs. AI. What the work cost when a person did it, fully loaded, vs. now. Dollars per finished thing, not tokens.

• Hours saved, as capacity. Translate hours into the hire you didn’t make. But never round up to “we don’t need this person.” I’ve automated half our finance work and never once concluded we don’t need our Head of Finance. The honest version is capacity, not replacement.

• Real time saved. AI feels instant, two clicks and you’re done. Then 40 minutes checking and fixing it. A dashboard that counts the two clicks and ignores the forty minutes is lying to you the same way the token chart did.

I’ll walk you through building one soon. If you’ve already built one, share what’s on it in the comments.

Leave a comment

Your move

Whatever your title, the job of finance department, and of whoever leads it, is to make AI usage mean something for the company.

Start with yourself and your own department. How much do you spend on AI? Which tasks does it actually pay off on? Where does it make more sense to just buy a dedicated tool instead of burning tokens on the same task every week? Then look at your team. How are they spending it?

And before any of that, make sure you’re on the right Claude plan, so you have the admin controls to see and cap all of this in the first place.

So, leaving you with these thoughts today, and coming back soon with the practical one: how to actually build the AI ROI dashboard. Don’t miss it.

I also made a one-page Claude token cheat sheet, the cheap habits that cut a team’s usage up to 70%. Download it, send it to your team, pin it in Slack.

— Alyona

This issue starts something new. Until now I’ve been testing other people’s releases: Anthropic’s agents, Claude Fable. Today we start building your skill stack, level by level.

Level 1 is skills.

In the next 10 minutes you’ll learn what a skill actually is, how to build financial skills that survive contact with a real close, and you’ll walk away with the master file: the skill.md that builds all my other financial skills.

Let’s go.

First, what a skill actually is

You’ve used Claude in chat. Maybe Claude in Excel, Cowork, or Claude Code. And I can bet money on this: you’ve had the same prompt produce three different outputs on three different days.

That inconsistency is the tax you pay for working from prompts.

A skill is how you stop paying it.

In The Big Short, Margot Robbie explained subprime mortgages from a bubble bath in 30 seconds. I’m not Margot Robbie. And I don’t have a bath either. But I’ll try to be just as precise.

A skill is an SOP (Skope of Work) your model follows. It tells Claude exactly how to produce a specific output: the steps, the format, what to check, what to refuse. Every time. In your format. That’s it. That’s the whole concept.

Or even shorter: a prompt is you explaining the task again every morning. A skill is the task explained once, permanently, by someone who was paying attention.

This is the first real game-changer for your time and your mental health. And instead of handing you a library of someone else’s skills you’d still have to customize, I’m going to teach you to build your own.

Then give you the file that does it with you. How about that?

The problem nobody warns you about

When you start building financial skills, the first one is fun. The fifth is fine. By the fifteenth, you end up with a mess.

I know because I opened our skills folder last month and audited it. Every skill structured differently. Half of them with dollar thresholds hardcoded into the prompt. One file says “company profile,” another says “business context,” a third says “client info.” Same file. Three names. And when something breaks during close, you can’t tell if it’s the data or the skill, because there’s no standard to check against.

So here’s the rule I now live by, and I’ll say it the blunt way: a skill stuffed with hardcoded values is not a skill. It’s a script.

A script works for one project, one month, one threshold. A skill survives a new month, a new policy, a new client, without anyone touching the skill body. If your “skill” breaks when the threshold changes, it was never a skill.

The fix: a meta-skill that builds skills

We built a meta-skill. One md file, dropped into your Claude skills folder. From then on it runs in two modes.

BUILD mode. You say “build a skill,” and it interviews you before writing a single line. What’s the one responsibility? (Exactly one. Not two.) What feeds data into it, and what does it feed into next? Which context files does it read? What can’t be automated yet? Only after the interview does it produce the full SKILL.md, in a fixed 10-section template: role, scope, context, tools, input, process, escalation rules, output schema, what it does NOT do, and critical rules.

VALIDATE mode. You paste any existing SKILL.md and it audits the thing line by line. Hardcoded values, missing sections, banned terminology, weak escalation logic. You get a pass/fail report with exact quotes of every violation and the fix for each.

Build with it, then validate its own output. The skill checks its own homework.

3 rules worth stealing even if you never download my skill file (below)

1. The FM approval gate is a hard block. Every skill has a step where the agent stops and waits for explicit human confirmation. Not “human review recommended.” The agent literally cannot continue without it. In finance, this is the difference between an agent you can deploy and an agent you can demo.

2. Confidence scoring with deduction logic. The agent starts at 1.0 and deducts for specific issues: 0.1 per missing data field, 0.1 per unresolved source discrepancy, 0.1 per unclassified vendor. Below 0.7? It escalates instead of deciding. No vibes-based confidence. Remember: every downstream skill is betting on this one’s output being right, so the errors don’t add up, they multiply.

3. Never let the LLM “just calculate.” Every calculation follows the same pattern: find the formula, show it, build the logic, calculate, return formula plus inputs plus result. If the formula is missing, the agent escalates. It never estimates. This one rule kills 90% of the hallucinated-numbers problem.

If you take nothing else from this issue, take these three. Paste them into every skill you ever write. I have.

How to use it

1. Download the SKILL.md below

2. Add it to your Claude skills (Settings → Capabilities → Skills, or drop it into your Claude Code skills folder)

3. Say “build a skill”. Or paste your messiest existing skill and say “validate this”

Start with validate. Watching it tear apart a skill you thought was solid is the fastest way to internalize the standard.

Watch it work: building a revenue reconciliation skill in 8 steps

I ran the full loop so you can see exactly what the interview feels like. The task: a skill that reconciles Stripe/Chargebee revenue against QBO GL for the close month.

The skill asks you eight questions before it writes a single line. These eight questions ARE the method. Even if you never download the file, run your next skill through them by hand and it will come out better. Here’s each one, and why it’s there.

Step 1. What is the one responsibility of this skill? Exactly one. Not two. The moment a skill does two things, you can’t tell which one broke. Mine: reconcile Stripe/Chargebee revenue against QBO GL for the close month, flag mismatches.

Step 2. Which orchestrator does it belong to? Every skill lives inside a bigger workflow: Month-End Close, Controlling, Forecasting. Naming the orchestrator up front means you’re building a system, not a pile of disconnected tools. Mine: Month-End Close.

Step 3. What feeds data into it, and what does it feed into next? The data chain. Mine receives from data-ingestion-agent and passes to revenue-recognition-agent. If you can’t answer this question, you don’t have a skill yet, you have a wish.

Step 4. Which context files does it read? This is where hardcoded values go to die. The thresholds, the CoA mapping, the business specifics all live in named context files.

Step 5. Which connectors does it need? Only what’s actually required, with read/write spelled out. Mine: QBO (read), Chargebee (read). A skill that asks for write access it doesn’t need is a skill your future self will regret.

Step 6. Which steps can’t be automated yet? Anything still manual becomes an explicit [MANUAL STEP] block instead of a silent assumption. Mine: the FM confirms the Chargebee export covers the full month before the skill runs.

Step 7. Who owns it? Every skill has a named owner. A name. When it breaks during close, you know exactly whose Slack lights up.

Step 8. Has it been tested on a real close month? This sets the status field, and I love this part: Idea → Testing (1 month) → Validated (2+ months) → Standardized (team standard). A skill that’s never touched real data is an Idea, and the file makes you admit it.

Eight answers later, it produced the full SKILL.md: the role, the scope, the critical rule (”Never modify accounting records without a human approval. Never guess missing financial data. If confidence < 0.7 or risk is high → escalate.”).

Then I did the part I recommend you do first: I validated it. And to make it interesting, I planted two bugs: a hardcoded $500/1% threshold and a missing connector.

The validator caught both. 28 of 30 checks passed, and the two failures came back with exact quotes and exact fixes. The missing kpi_context surfaced as four separate violations, which is what happens with a real gap in real life: it doesn’t fail once, it leaks into everything downstream.

That’s the loop. Interview, build, validate, fix, deploy. No blank page anywhere in it. Your next skill takes twenty minutes, and it’s better than the ones you spent hours on.

My meta-skill file (built and tested by ~20 finance managers)

Here it is, the most-used file in our entire skill library. The skill that builds all the other skills.

Read more

Then on Tuesday, Anthropic released Claude Fable. Within an hour, our team chat at Fuel turned into a room full of CFOs asking the same question: who’s tested it, and on what?

So I tested it the same night. Both models, side by side. By 1am I had my answer, and the title of this issue.

Fable found 3 issues. One of them is worth about $30M. One of them wasn’t Opus’s mistake. It was mine. Let me show you everything.

First, what Fable actually is

Back in April, Anthropic built a model called Mythos. And then they refused to release it. Too powerful, they said. Too dangerous. They locked it inside a restricted program called Project Glasswing, partners like AWS, Microsoft, Apple, and CrowdStrike only, plus a few biology researchers. The rest of us got to read rumors about it from the outside.

This week’s Claude Fable is that same Mythos model. What changed is the supervision. Fable ships with safeguards: push it into genuinely high-risk territory (serious cybersecurity work, biology, chemistry, attempts to clone the model itself) and it won’t answer. It reroutes you to Opus 4.8. Anthropic says this triggers in under 5% of sessions. Karpathy says the safeguards are “a little too trigger happy” at launch. Both can be true.

The practical part, because the practical part is the job:

→ The full-power Mythos also exists. Businesses that touch it accept mandatory 30-day data retention for safety monitoring.

→ For finance, the guardrails are a non-issue. The reroutes target cyber, bio, and chemistry. FP&A work essentially never trips them. Your forecast is not a bioweapon, no matter what your CEO says about your downside case.

→ Pricing: $10/$50 per million tokens. Double Opus. Ouch.

So that’s who walked in on Tuesday: the dangerous one, on supervised release, wearing a friendlier name. Karpathy called it a major-version-bump step change. I’ve seen one founder had it build a working product live during a customer call.

I was charmed too. But I’ve been a CFO long enough to know you don’t believe charm. You check the references. So I ran an audit.

The audit setup: same company, same prompts, both models

You know Numbr, my imaginary $93M SaaS from Issue 002. Officially our lab rat now.

I took the exact 3-statement model we built last issue and gave Opus 4.8 and Claude Fable two identical tasks. Same files. Same prompts, word for word.

Task one: build the interactive forecast dashboard (the exact prompt from Issue 002).

Task two: “make an analysis of this business using this forecast.”

Here’s what the audit found.

Finding 1: Opus misstated a number and never noticed

Both models built a working dashboard. Both looked good.

Then I checked the numbers. Opus displayed the wrong total revenue. The correct number was in the file I gave it. It showed a different one and never flagged it.

Fable showed the correct revenue. It also added a save-scenario feature and surfaced the metrics that matter for SaaS: NRR, revenue per FTE, Rule of 40, headcount efficiency. Opus gave me the generic revenue-costs-margins set.

Finding 2: a $30M omission

Same analysis prompt to both. They agreed on the thesis: expansion-driven growth, heroic operating leverage, no real bear case. Skim both and you’d call it a tie. It’s not a tie.

Fable caught the tax problem. Numbr’s model runs an 8% effective tax rate flat for five years while pretax income passes $150M. Fable flagged it, quantified $25-35M of overstated cumulative net income and cash, and gave the fix: NOL shields run out at this profitability, model toward 21% plus state by FY28-29.

Opus didn’t mention tax once. Neither has any Claude model I’ve tested.

Two more catches came with it. The SBC add-back: “Adjusted EBITDA” flatters the picture by 3-7 points, net income (44% margin) is the more honest line.

And capital allocation: $744M of cash piling up with no deployment plan. M&A, buybacks, reinvestment, why is this money sleeping? Opus called the cash pile good news and moved on. Board members do not move on.

Uncomfortable part: the tax assumption wasn’t Opus’s error. It was in MY model. Fable didn’t just audit Opus. It audited me. That’s the moment I knew this release was different.

Finding 3: communication issues

My favorite finding, and it’s not a number.

I can spot a Claude-written document from across the room.

Fable writes straight to business. It called the marketplace line “essentially dead.” It said the downside case “would get laughed at” by a board. It ended with marching orders: build an NRR stress case, fix the tax ramp, decouple headcount, kill or fund the marketplace.

Opus ended with a summary. For documents that go in front of CEOs and boards, that’s the difference between one you forward and one you rewrite at 11pm with your name on it.

Fable 5 vs Opus 4.8

So, to wrap up, here’s the full Opus error log vs Fable:

→ Wrong total revenue on the dashboard (the correct number was in the file)

→ A growth multiple anchored to the wrong baseline year

→ Missed the tax problem entirely (~$25-35M of overstated net income and cash)

→ Missed the SBC distortion (Adjusted EBITDA flattered by 3-7 points)

→ Missed the capital allocation question ($744M of cash, no deployment plan)

To be fair to Opus

Here’s what Opus did better. It did do some things better.

→ It produced a proper board-ready scenario table: ARR, revenue, margins, cash, Rule of 40 across all three scenarios. Fable’s document didn’t have one. For a board deck, I’d want that table.

→ It made one genuinely sharp catch: the headcount slider exists in the playground, but none of the preset scenarios ever flex it. That’s a more precise diagnosis than Fable’s flatter “headcount is held identical.”

→ It noticed that every cost line is modeled as a fixed % of revenue, meaning no infra-scaling or support-load risk anywhere in the model. True and useful.

But the pattern of the evening was consistent: Opus produced cleaner-looking structure with more mistakes inside it (it also misquoted a growth multiple, its second numerical slip of the night, stated with full confidence). Fable produced blunter documents with numbers that held.

So, are we really over?

Mostly.

Fable costs double. The high-volume plumbing, categorization, tagging, short summaries, stays with cheaper models. Opus and I are still friends. It keeps the routine tasks. We’re being very adult about it.

But the judgment work, forecast analysis, anomaly investigation, anything where a model has to hold a long chain of reasoning across an entire P&L, that’s Fable’s now.

It’s the first model that performed at a level I’d call senior on my tests. It caught what a good controller catches, including my own mistake.

One evening isn’t a verdict though. It’s a strong signal, the kind you take seriously and verify anyway. This week I’m moving my heavy analysis to Fable and putting it through more experiments. More results soon.

Tell me what you think about Fable in the subscriber chat. I read every message.

And as is tradition in good marketing around here: this issue was brought to you by our founding partners, Hampton, FIF Collective, Light, and Spendesk. Grateful to them for backing this newsletter before model releases started writing my content calendar.

— Alyona

Look at what they pulled off. On May 5th they dropped ten finance agent templates and the whole internet lost its mind on cue. Every AI influencer reposting within the hour. Half my LinkedIn feed, honestly.

And Anthropic’s marketing deserves its own newsletter issue. Their creative team (who, I promise, are not agents, and not Claude) keep coming up with the most human way to sell AI. Go look at their Instagram. It’s art, illustration, in-person Code with Claude meetups, real people making real things.

They recently ran a roundtable in Tokyo where they put painters, bakers, and engineers in the same room, with one of Japan’s last three living sento mural painters working on the wall behind them. Look at that. Crazy that this is what AI marketing looks like now.

Anyway. Away from the marketing for a second: financial services is now Anthropic’s second-biggest source of enterprise revenue, right behind tech.

But as a CFO-turned-founder, I know the single most costly habit in finance is believing the marketing.

So I closed Slack. Opened a fresh Claude window. And spent the rest of the weekend testing Anthropic’s agents on an imaginary company called Numbr. (Sorry, Numbr, if there’s a real one out there. I didn’t mean you.)

First, let’s agree on what a word “agent” means

Before we go further, we need to talk about a word.

I truly hate how everyone is calling everything an “agent” right now. Email automation? Agent. Macro in Excel? Agent. N8N flow with a ChatGPT call bolted on the end? Bro, that’s still just a N8N flow.

We’re all smart finance people here. We do critical thinking for a living. So let’s actually agree on what each word means before someone sells us a product that doesn’t do what we think.

→ Automation. A rule-based workflow. You write the rules, it follows them, forever. A lot of the “AI-native” stuff you see marketed in finance is simply rule-based workflows.

→ Skill. A Claude feature. A reusable instruction set you hand the model: how to do a thing, the steps, the format, what to check, what to refuse. Find them under Customize → Skills (toggle any on or off). Build your own with the built-in Skill Creator, which interviews you and writes the file. You’ll see a lot of my skills on the pages of this newsletter.

→ Plugin. A bundle of skills, connectors, and helpers packaged together. Basically an app inside Claude. Add one under Customize → Plugins → “+” → Add marketplace, then paste a GitHub URL, which is exactly how we’ll install the finance ones in a minute. You can build your own too.

→ Routine. A scheduled workflow you set once and let run. Smarter than automation, not as independent as an agent. In Cowork these are Scheduled Tasks: describe the recurring job, it fires on a schedule (as long as your laptop’s awake and Claude’s open).

→ Memory. LLM remembering your context, preferences, and files across sessions, so you’re not re-explaining your business every morning. Turn it on in settings. Tip: you can also move your memory from ChatGPT to Claude. Open Claude, go to Settings > Capabilities > Memory, and click Start Import. Copy the extraction prompt provided and follow the instructions.

→ Cowork. A Claude feature. The desktop workspace where Claude works with your files, tools, and skills in one place instead of you copy-pasting between tabs. The finance version of the setup engineers have always had.

→ Agent. A model that decides what to do next on its own. It plans, picks its tools, checks its own work, tries again when it’s wrong. Calls you never scripted.

Most things being marketed as “agents” right now are actually plugins, skills, or automations. That’s not bad! It’s just not what the word means.

So the ten “finance agents” everyone lost their mind over?

They’re plugins. Packaged skills with a defined workflow, called from inside Cowork, with mandatory human review on every output. That’s not an agent in the strict sense. That’s a really well-engineered plugin.

Cool. Now we can talk about them honestly.

They’re not even inside Claude. They’re on GitHub.

This was the first thing that surprised me. The whole thing lives on GitHub. As code.

At github.com/anthropics/financial-services.

For anyone not from the engineering side, GitHub is where code lives on the internet. It’s the version-controlled filing cabinet of the entire software industry. Anthropic publishing finance agents there means: here’s the open-source recipe, you go install it.

And once you’re on GitHub, you start noticing things.

There are other finance agents up there. From other people. From other companies. Some of them, honestly, better than what Anthropic shipped. The marketing made it sound like Anthropic invented finance-flavored AI on Tuesday. The repo tells a different story.

My first impression: the marketing was louder than what’s inside.

That’s not me being a hater. Anthropic is one of the companies I bet on hardest. I’d call myself a Claude psycho on a public post, and I have. But part of building your finance engineering skillset is being able to read marketing carefully - not just receive it.

Okay. Let’s install them.

How to add them (5 minutes, no engineering required)

The install is the easy part.

You need three things: Claude desktop (the app, not the browser), a paid plan, Cowork enabled.

Then:

1. Open Claude desktop

2. Settings → Plugins → Add plugin → Add marketplace

3. Paste: https://github.com/anthropics/financial-services

4. Hit Sync

Done. The marketplace shows up in your plugin directory.

When you open it, you’ll see the full list:

Built for corporate finance (us):

• Model builder - DCF, LBO, 3-statement, comps, live in Excel

• Financial analysis - same core, broader scope

• GL reconciler - finds breaks, traces root cause, routes for sign-off

• Month end closer - accruals, roll-forwards, variance commentary

• Earnings reviewer - earnings call + filings → draft update to note

Built for investment banking / PE / wealth management (not us):

• Equity research

• Investment banking

• Fund admin

• KYC screener

Other:

• Finance (general), Marketing, Small business

A lot of these are calibrated for investment banking, private equity, and wealth management workflows. Not for the FP&A manager, controller, or head of finance at a SaaS company.

For corporate finance (the people this newsletter is actually for) three of them are worth your time today:

→ Model builder (with caveats, see below)

→ GL reconciler

→ Month end closer

I’m going to walk through Model Builder in detail right now.

Inside the Model Builder

When you open Model Builder, it offers four model types:

→ DCF - discounted cash flow

→ LBO - leveraged buyout

→ 3-statement - IS / BS / CF, integrated

→ Comps -trading multiples

A thing I noticed immediately and I think it tells you exactly who Anthropic built this for.

There’s no model for recurring revenue forecasting. No unit economics. No MRR waterfall. No cohort retention. No usage-based pricing model.

If you run finance at a SaaS company - that list is your whole job. And it’s missing.

DCF and LBO are pretty standard banker-side instruments. Most corporate finance teams don’t live in those models day-to-day. The only one from the four that genuinely maps onto operational corporate finance is the 3-statement.

So that’s where we’ll go deep.

What’s good inside the 3-statement skill

I went into the repo and read the 3-statement skill file line by line. (Reading skill files is now part of my actual job. I did not expect to ever type that sentence, and yet here we are.)

Three things Anthropic got right.

1. Formulas over hardcodes. Every projected cell is a formula. Every assumption is labeled, cited, and traceable to an input. No typed numbers in calculation cells. This is the right discipline — every cell can be audited, every driver flexed, and the model behaves like a model instead of a printout.

2. Verify step-by-step with the user. This part I love. The skill is explicitly told NOT to build the entire model end-to-end and present it complete. It’s told to stop at each statement. Show the work. Wait for confirmation. Catch errors early.

The exact language from the skill:

→ After mapping the template → show the user the sections, confirm before touching any cells

→ After populating historicals → show the historical block, confirm values/periods match source

→ After building IS projections → run subtotal checks, confirm before moving to BS

→ After building BS → show the balance check (Assets = L+E) for every period

→ After building CF → show the cash tie-out (CF ending cash = BS cash)

→ Do NOT populate the entire model end-to-end and present it complete. Break at each statement. Show the work. Catch errors early.

This is human-in-the-loop done right. After every wrong number I’ve watched Claude confidently produce, this is exactly the discipline I want.

Steal this pattern. Paste it into every skill you ever build. I have.

3. Real integrity checks. Master Status reads PASS across all periods. Every reconciliation gets its own tab. Every guardrail shows up visibly on the Cover and Checks tabs. That’s good engineering, full stop.

What to keep in mind before we start

The Model Builder agent ships as a general template. No business context. No industry assumptions. No idea what your revenue model is.

To get a forecast that actually reflects your company, you have to customize the underlying skill file first. With business-specific context, drivers, assumptions, metrics.

You can do this inside Claude Chat. No engineering required. But you do need to do it. Out of the box, the model is generic.

Let me show you what “out of the box” actually looks like, and what happens after you customize.

Meet Numbr, my imaginary company

To test this honestly, I needed real-looking data. So I generated a fictional company with Claude and tested on that.

Meet Numbr, Inc. – a $93M ARR fintech SaaS selling financial intelligence tools to banks, hedge funds, and asset managers.

→ Three legal entities (US, Netherlands, Singapore)

→ Two revenue streams (recurring subscriptions + usage-based API billing)

→ Freshly cash-flow positive in 2025

→ Complex enough to be interesting, clean enough to follow along

The inputs are three Excel files exported straight from their systems:

→ QBO export — Cash-basis P&L with $3M intercompany, Balance Sheet that doesn’t tie

→ NetSuite export — proper accrual books, $89.5M revenue, $12.6M operating income

→ HubSpot export — pipeline, customer data, deal stages

This is what real corporate finance actually looks like.

I’m dropping the Numbr files here. Took me ~3 hours to generate and clean. You can run the same test yourself.

Numbr Hubspot Export

78.9KB ∙ XLSX file

Download

Download

Numbr Netsuite Export

45.3KB ∙ XLSX file

Download

Download

Numbr Qbo Export

42.4KB ∙ XLSX file

Download

Download

Let’s see what we got out of the box

I switched on Model Builder, pointed it at the three files, and asked for a 3-statement model.

It worked. It ran the step-by-step verification exactly like the skill promised. Stopped at each statement. Showed the balance check. Tied out cash. As pure engineering, it did what it said on the tin.

It built a generic 3-statement model.

And it had no idea Numbr was a SaaS company. It skipped the recurring revenue build. It ignored churn. It never split subscriptions from usage-based API billing, even though that split is sitting right there in the HubSpot and NetSuite files.

ARR, net revenue retention, cohorts, all gone. It forecast revenue as one line growing at one rate, the way you’d model a company that sells a single widget to a single kind of customer.

I gave the Financial Analysis plugin a shot too. It was a little better. A few more ratios, a bit more commentary. But still average.

Lesson learned: Anthropic’s plugins are good, technically, but they don’t work out of the box.

So I went further, and customized the skill, which really is great, to fit my imaginary $93M SaaS.

Let’s see what happens when we customize the skill

I did it in Claude Chat.

I described the business model, the challenges, the revenue streams, the markets, and the exact financial model I wanted out the other end.

I kept Anthropic’s skill as the base, because most of the rules in it are good. No reason to start from scratch when the bones are right.

You can download my custom SaaS 3-statement skill file below (+ prompt I use to turn the agent's model into an interactive dashboard you can play with).

Read more

I was on a morning run with Haku, my husky, listening to My First Million. The episode with Amjad Masad, founder of Replit. Haku was sniffing every tree like usual. I was half-listening like usual.

Then Amjad said something I haven’t been able to shake.

He was talking about the singularity.

The concept comes from astrophysics. A singularity is what happens at the center of a black hole. Past the event horizon, the math breaks. The equations that describe everything else in the universe just stop working. Gravity, time, distance. All of it goes weird.

You can’t predict what happens next, because the rules you’ve been using no longer apply.

The future stops being uncertain and becomes literally undefined. There are no formulas for it. It’s the universe shrugging at you.

At this point, stay with me: this is a finance newsletter, I promise.

Vernor Vinge, an early computer scientist and sci-fi writer, borrowed this idea in the ‘90s and applied it to technology. His argument: at some point, AI advances fast enough that the pace of change itself becomes unpredictable. Fast, then faster, then accelerating. The second derivative goes exponential.

Once you’re past that point, you can’t project forward anymore. The planning tools we use to think about the future stop being useful. Five-year strategy decks become creative writing.

Amjad’s point was: we’re there. Right now.

Honestly, when you look around, it’s hard to argue.

In 2022, GPT-4 dropped and felt like a revolution. Before that, we got a major model every two years. Now we get one every few weeks. Sometimes every day. Sometimes I check X in the morning and someone has built a thing I didn’t know was possible by lunch.

Each new model unlocks capabilities that haven’t been productized yet. A pile of potential energy just sitting there, waiting for someone to figure out what to build with it.

I’ve been a CFO. I’m now a founder. I’ve pivoted our strategy three times in the last month. Three times. In one month. The ground just won’t stop moving.

Nobody knows where this goes. But the people who figure things out in undefined moments are the ones who win the next decade.

For finance, I want to call them Finance Engineers.

How we vibecoded so hard we accidentally became engineers

A few years ago, a company called Clay (yes, that Clay) had this problem. Their go-to-market team had people doing something that didn’t fit any existing title. They were too technical to be SDRs. Too sales-brained to be engineers. This weird hybrid - data, revenue, automation - all in one person.

So Clay made up a name: GTM Engineer.

Today, 100+ GTM Engineer roles get posted every month. Every growing startup needs one. A job title that literally didn’t exist became a career path - because one company said “this is a real thing” and built the infrastructure around it.

There’s something similar happening in finance.

In 2025, Andrej Karpathy - co-founder of OpenAI, former head of AI at Tesla, and now a part of Anthropic, probably one of the five smartest people working on AI right now - wrote a post that changed how an entire industry thinks about building software.

He described a new way of creating things. You don’t write code. You describe what you want - in plain English. The AI writes the code.

He called it vibe coding.

This blew up in engineering. And then (because apparently finance people can’t resist a good tool) it jumped the fence.

I’ve been vibe coding for months now. I built a cash flow forecasting tool. I spend my weekends testing the new finance agents from Anthropic (more on this + a full tutorial in the next issue). I went to one of Rillet’s vibe coding workshops and watched a CFO build a pricing calculator from scratch in under 20 minutes with Claude Code.

Aesha, a financial manager on my team at Fuelfinance, built an interactive dashboard that pulls live data and visualizes it dynamically. She’s not an engineer. She just opened the tool and started building.

This is happening everywhere. Finance people (FP&A managers, controllers, heads of finance, CFOs) are building software.

They didn’t plan to become engineers.

They vibecoded so hard they accidentally became one.

The skillset and the mindset of a finance engineer

So who are these people?

Let’s get specific. Take a Head of Finance at a $15M company. Series A, maybe early Series B. Small team - maybe it’s them and two analysts. Maybe it’s just them.

The core finance skills didn’t go away. AI doesn’t replace any of that, it amplifies it. Without the foundation, you’re just someone with Claude and a very, very dangerous amount of confidence (in finance, 99% right is still wrong).

But the layer on top is new. And it’s expanding every month.

Here’s what I’ve come to believe: finance engineering isn’t a job title. It’s a skill layer that’s being added to every finance role. The Controller still closes the books, but now they automate the close. The FP&A Manager still forecasts, but now they vibe code the dashboard. The Head of Finance still runs the function, but now they build the systems that run it. Same people. Same titles. Fundamentally new capabilities. And nobody’s teaching it, which is kind of why we’re all here.

And here’s the thing nobody’s saying (well, maybe only on reddit) - this transition isn’t always easy.

Sometimes your CEO is pushing AI on the team while you haven’t even gotten the data right yet. You’re being told to “implement AI in finance” while your chart of accounts is a mess and your ERP hasn’t been updated properly. Cool. Sure. Let me just connect Claude to our garbage data and see what hallucinations we get.

Sometimes you’re doing this out of pure fear. You think “how fu*ked are we?” when someone fed AI two budgets and got back a complete variance analysis that looked like a real analyst wrote it.

And you thought: wait. Is that my job? Can it do my job? Should I be scared right now??

And sometimes - honestly? Sometimes you open a vibe coding tool for the first time and build something in 30 minutes that would’ve taken you two weeks, and your brain just... short-circuits. You can’t have another reaction. It’s like seeing a magic trick except it’s real and you did it and now you don’t know what your job even is anymore.

All of these reactions are valid. All of them are happening simultaneously in finance teams everywhere.

Here’s what I think is true:

I don’t know exactly where this goes. I really don’t. Anyone who says they have a five-year roadmap for AI in corporate finance is selling you something.

But I’m pretty sure about one thing: if you don’t learn this new skillset - whatever we end up calling it - you can be replaced by someone who did.

So stay for the ride :)

Building your skill stack for the new era of finance

So here’s what this newsletter actually is.

My team and I are personally testing dozens of tools and workflows every week to figure out what actually works for the new era of finance.

My dear CFO and head-of-finance friends (the ones I’d genuinely call finance engineers) are testing too. And they wanna share.

Right now, the newsletter runs on two formats:

→ My guides on engineering stuff in finance. When I automate something, I’ll show you the prompts, the setup, the output, and what went wrong. When I test AI agents on our close, you’ll see the screenshots. This is a build log, not a thought piece.

→ My finance friends sharing what they built - step by step, tool by tool. Maybe we’ll be eating bagels or having a filter coffee on a lunch break while we prepare these.

You’ll also find thoughts beyond the finance role. Going from CFO to founder building AI taught me things I never would’ve learned inside the department. I’ll share those too - between all the practical stuff this newsletter is truly about.

The founding partners

The founding partners of The Finance Engineer are the people and communities who shaped me, both as a finance person and as a founder.

→ Hampton

Founded by Sam Parr, who built and sold The Hustle newsletter to HubSpot. A lot of what I know about writing on the internet, I learned from Sam directly.

Hampton is Sam’s founders community I’ve been a member of, and a huge part of why I’ve grown as a founder over the last couple of years. One day I hope The Finance Engineer becomes for finance leaders what Hampton is for founders. If you’re a founder doing $3M+ a year, Hampton is the room you want to be in.

→ FIF Collective

Run by Megan Curtin McKenna, FIF is the best women-in-finance community I’ve ever been part of, and one of the most generous, sharp networks of finance leaders I know.

Megan has built something rare. Whenever I’m testing something new or building content, FIF gets to see it first and give honest feedback. If you’re a woman in finance, I cannot recommend joining strongly enough.

→ Light ERP

Light is an AI accounting platform. AR, AP, expenses, bookkeeping, and reporting, running automatically across every entity. It’s all-in-one, built for fast-moving SaaS companies that never needed a heavy ERP. I’m watching this space closely, and they’re building it the way I’d want it built if I were starting an accounting platform today. They’re also the platform Lovable runs on. Worth a look if you’re rethinking your stack.

→ Spendesk

Spendesk is one of the most established spend management platforms in finance, and the team behind CFO Connect, one of the largest communities of finance leaders. What I’ve always respected about them is how seriously they take the finance community itself. The events, the content, the actual investment in helping CFOs become better operators. Not many vendors do this.

Grateful to all four of them for backing this early.

You’re not behind. You’re early.

Thank you for being here. Truly.

— Alyona