DEV Community: Layerz

Persistent Memory for a Financial Model: The Six Things That Must Survive a New Session

anthomakr — Thu, 06 Aug 2026 13:53:41 +0000

The second session is always worse than the first.

The first one goes well. You explain the model, the agent picks it up, you get real work done. Two days later you open a new session and you are back at the beginning: re-explaining what the model is for, which line is a driver and which is an output, why costs are positive, why that one warehouse is excluded from the ramp.

The usual diagnosis is that the AI has no memory. That is roughly true and completely unhelpful, because most memory features solve a different problem. They remember the conversation. What you need is for the model to be readable when the conversation starts.

Those are not the same object, and the difference is why "turn on memory" rarely fixes this.

Why chat memory is the wrong primitive

A conversation is a lossy recording of work. Memory features compress it further, into something like a summary of what was discussed. Summaries of a financial model are exactly where the damage happens: "revenue is driven by headcount" is a sentence that survives compression, and it is not a formula.

A model is a different kind of object. It has a shape, and the shape is either exactly right or it is wrong. There is no useful approximation of a dependency graph.

So the question is not "how do I make the assistant remember more." It is "what has to exist outside the conversation so the next session does not need to remember anything."

That list is short, and it is testable.

1. What the model is for

The first thing an agent needs is not a number. It is the deliverable.

An agent building a lender-facing budget under covenants behaves differently from one filling in a template: it stays conservative, it flags anything that moves headroom, it does not quietly improve your assumptions. Without that framing it defaults to generic competence, which is the wrong register for most finance work.

This is one paragraph. What the model produces, for whom, by when.

Failure mode: the agent optimises for elegance instead of defensibility. It simplifies a structure your bank specifically asked for.

Test: open a fresh session and ask what this model is for. If you have to answer, it does not persist.

2. The conventions

Every number in the model is read through a set of conventions, and almost none of them are visible in the numbers themselves.

Units and sign first, because they change what a figure means: 1 200 is €1.2 million or €1,200 depending on a decision nobody wrote down. Then the working language, the closing calendar, and the terms your company redefined. Most finance teams have at least one term that means something non-standard internally, and it is usually a term the agent thinks it already knows. "Marge brute" that stops at purchases and excludes logistics is not gross profit, and an agent that assumes otherwise will produce a coherent, wrong answer.

This is what FINANCE.md exists for: one versioned file, read at session start, that says how to read the numbers before anyone touches them.

Failure mode: silent unit errors. The worst class of error, because the output looks right.

Test: ask what a value of 1 200 means in this model. A correct answer without your help means the conventions persist.

3. The structure

This is the part people underestimate, and it is the expensive one.

The structure is which items exist, what type each one is (an input you can change, a computed line you cannot, a balance that accumulates), and what depends on what. It is the difference between a model and a grid of numbers that happen to be arranged in a familiar way.

An agent reading a spreadsheet does not receive this. It receives cells, and it infers. Inference on a well-built model is often right, which is precisely what makes it dangerous: you stop checking. Then it meets a row that breaks the pattern for a good reason, treats the exception as an error, and helpfully fixes it.

The real failure here is not amnesia. It is confident reconstruction: the agent rebuilds a plausible structure from what it can see, gets most of it right, and is wrong in the places that took you longest to get right.

Related, but a different question: why spreadsheet access alone is not enough for an agent covers what structure buys you during a session. This is about what has to be there before it starts.

Failure mode: an edit that computes correctly and breaks a link you needed.

Test: ask what feeds gross margin, and what would change if you moved one assumption. An agent that answers from the model rather than from pattern matching has the structure.

4. The grain

Monthly, quarterly, yearly, or a single constant. Where the model changes grain, and how the periods line up.

Grain sounds like a detail until an agent projects a yearly assumption across twelve months by dividing, when your model ramps it. Or annualises a partial period without saying so. Both produce numbers that pass a sanity check and fail a review.

Failure mode: a plausible number in the wrong period. Hard to spot, easy to present.

Test: ask over which periods a given assumption applies, and what happens in the first partial year.

5. The values, kept separate from the structure

A model has logic, and it has the numbers currently loaded into that logic. If those two are the same object, every scenario is a copy of the whole thing, and the copies drift.

Keeping them separate is what makes "run this with a 3% ramp instead of 5%" a change to one input rather than a new file. It is also what makes a model reusable next quarter, when the structure still holds and every value has moved.

Failure mode: version proliferation. Six files, none of them clearly the reference, and the differences between them are undocumented.

Test: change one assumption and see whether you produced a variant or a new file.

6. The history

What changed, when, and why.

The first two are mechanical and most tools give you something. The third is the one that matters and the one that is almost never captured: an assumption that moved because the sponsor asked for it in a call is a different object from one that moved because someone was testing. Six weeks later they look identical.

History is also what makes an AI-assisted model defensible rather than merely fast. When a board asks where a number comes from, "the model was built with AI" is not an answer. A traceable chain from output to assumption, with the reason attached, is.

Failure mode: you can see that something changed, and you cannot reconstruct whether it was a decision.

Test: ask what changed since last month and why. The "why" is the part that tells you whether history persists or only diffs do.

When none of this is worth it

Most of the time, honestly.

For a one-off analysis you finish in a single sitting, a chat window and a spreadsheet are the right tools, and any of this would be overhead. Same for exploration: when you do not yet know what you are building, structure is a cost with no return, and you should not pay it before the shape settles.

This list starts paying when a model gets touched again. By you next month, by a colleague, by an agent in a session you are not watching. The cost of reconstruction is roughly linear in how often that happens, and most finance models get touched far more often than the person who built them expected.

The other honest case against: if your model genuinely lives in one person's head and always will, the constraint is not tooling. Writing the six items down would help that person more than any AI setup, and it would help them whether or not an agent ever reads it.

The short version

Persistence is not a feature you switch on. It is six specific things existing outside the conversation:

	What it answers	The failure when it is missing
Objective	What is this for	Elegant instead of defensible
Conventions	How to read a number	Silent unit and definition errors
Structure	What depends on what	Confident reconstruction
Grain	Over which periods	Right number, wrong period
Values	What is loaded right now	Version proliferation
History	What changed and why	Cannot tell a decision from a test

Open a new session and ask three questions with no context: what is this model for, what feeds gross margin, and what changed last. If the answers come from the model rather than from you, it persists. If you find yourself re-explaining, you have located exactly which of the six is missing.

That is a more useful diagnosis than "the AI forgot."

Further reading: Why Finance Agents Need a Model Layer · FINANCE.md: An Open Standard for Financial Modeling Conventions · How to Save Tokens When Building Financial Models with AI

Layerz keeps a financial model as structure separate from data, with its conventions in a FINANCE.md and every change versioned with its reason. An agent reads all six at session start instead of reconstructing them. Excel export is clean, standard, and never paywalled. Explore Layerz →

Your Client's Contract Says No AI. What You Can Still Do.

anthomakr — Thu, 30 Jul 2026 19:05:48 +0000

There is a pattern showing up in financial modeling that nobody predicted two years ago: experienced practitioners are using less AI than they were, not more.

Not because the tools got worse. Because the contracts changed. Engagement letters and NDAs increasingly carry a clause prohibiting confidential information from being entered into a generative AI system, and the practitioner who signed it now has a spreadsheet in one window, a chat interface in the other, and a rule against connecting them. The workaround is deliberately vague prompting: debug this formula, explain this accounting treatment, never a real number.

That is a real constraint and it deserves a real answer, not a reassurance. This article is about what those clauses actually prohibit, what actually happens to data you send to a model provider, and which workflows stay inside the line. Sources are linked throughout, because on this topic a confident claim without a citation is worth nothing.

First: read the clause. Three different prohibitions get called "no AI"

Practitioners tend to collapse three very different restrictions into one blanket "we can't use AI." They have different scopes and different remedies.

1. No training on our data. The most common formulation. It prohibits your data being used to improve a model, not the act of inference itself. This one is often already satisfied by the commercial terms of the provider you were going to use anyway.

2. No consumer-grade or publicly available tools. The second most common. Typical drafting: the recipient shall not input confidential information into any publicly-available or consumer-grade generative artificial intelligence or large language model. This restricts the tier, not the technology. A commercial API account under a data processing agreement is a different object from a personal Pro subscription, and the clause frequently says so.

3. No processing by any third party. The broadest. This one genuinely rules out any hosted model, and the only remaining paths are a local model or no model at all.

The distinction matters because the three clauses have different answers, and because the middle one is the most common while also being the one most often read as if it were the third. Before changing how you work, get the actual sentence in front of you and identify which of the three you are dealing with. If it is ambiguous, that ambiguity is a question for the client, not something to resolve by assuming the strictest reading.

Second: know what actually happens to the data

Most of the fear in this area is calibrated to a 2023 understanding of how these services worked. The terms have changed, they are public, and they are specific. What follows is what the providers themselves document, with the nuances that get lost in summary.

On the commercial tier, your data is not training the model. Anthropic's developer documentation states that retained data "is never used for model training without your express permission," and that inputs and outputs on the commercial API are deleted within 30 days by default (Anthropic, API and data retention). OpenAI documents that since 1 March 2023, data sent to its API "is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)," with abuse-monitoring logs retained up to 30 days (OpenAI, Data controls).

The consumer tier is a genuinely different product, and this is the one your clause is about. Under the consumer terms announced in August 2025, users on Claude Free, Pro and Max choose whether their chats are used to improve the model, with retention of five years if they allow it against the standard 30 days if they do not. That update explicitly does not apply to services under Anthropic's Commercial Terms, including API use (Anthropic, 2025). If you are working from a personal Pro subscription, you are on the tier the clause was drafted to catch. That is worth sitting with, because it is the single most common gap between what practitioners believe about their setup and what is true.

Zero data retention exists, and it is narrower than the name suggests. Under a ZDR arrangement, prompts and responses are not stored at rest after the response is returned. But the documentation lists what the arrangement does not cover: consumer plans, the Claude Teams and Enterprise product interfaces, Console and Workbench, Claude for Excel, Managed Agents, third-party integrations, and the models designated Covered Models, which require 30-day retention. A separate eligibility table puts further features outside it, among them code execution, the Files API, batch processing, the MCP connector and Agent Skills. The trap is that using one of those does not fail loudly: nothing blocks the request, and the documentation is explicit that using an ineligible feature "is a choice to step outside your ZDR arrangement for that specific data." ZDR is enabled per organization and arranged through sales, not toggled in settings (Anthropic, API and data retention).

Nothing is absolute. Anthropic documents that even with a ZDR or HIPAA arrangement, content flagged by automated trust and safety systems may be retained for up to two years. Any claim that data "never touches their servers" is false for every hosted model, and you should distrust any vendor who tells you otherwise.

The honest summary: on a commercial tier with a DPA, your data is processed, retained briefly, not trained on, and subject to documented exceptions. That is a materially different risk profile from a consumer subscription, and it is checkable rather than assumed.

Third: the obligation may exist even if the contract is silent

For US CPAs there is a second layer that does not depend on what the client's contract says.

The AICPA Confidential Client Information Rule (1.700.001) provides that a member in public practice shall not disclose confidential client information without the client's specific consent. Interpretation 1.700.040 addresses what happens when a third-party service provider is involved: before disclosing confidential client information to that provider, the member should either enter into a contractual agreement with the provider to maintain confidentiality and give reasonable assurance of appropriate procedures, or obtain specific consent from the client (Blatch, Journal of Accountancy, 2015 · Journal of Accountancy, 2024). The Code's word is "should", not "must", and the interpretation predates generative AI: it does not name it, which is precisely why it applies to it.

A hosted model provider is a third-party service provider on any plain reading, and the rule gives you two doors rather than one. The contractual door is a DPA with a commercial provider. The consent door is a conversation with your client. Neither of them is "stop using AI."

Silence in the engagement letter is not permission, and it is not prohibition either. It is an unanswered question, and the profession's own rule tells you how to answer it.

The four workflows that stay inside the line

Ranked from the most restrictive constraint to the least.

1. Never send client numbers at all: build the structure, populate offline

This is the one most people miss, and it is the one that works even under the broadest clause.

A financial model is two things stacked together: a structure (the logic, the formula relationships, the timeline, the ordering of a debt waterfall, the shape of a three-statement build) and data (this client's actuals, this deal's assumptions). Confidentiality attaches to the data. It does not attach to the fact that interest expense is a function of average debt balance.

So you can do the expensive part with AI on a structure that contains no client information, using placeholder or synthetic figures, then populate the real numbers in a separate step that no model ever sees. The AI does the work you actually wanted help with, which is the architecture and the formula logic, and the confidential figures never leave your environment.

This is not a trick and it does not need a vendor. You can do it with a blank workbook. It does require a tool where structure and data are genuinely separable, because in a normal spreadsheet the logic and the numbers live in the same cells and there is no clean line to cut along.

2. Move to a commercial tier and paper it

If the clause targets consumer-grade tools, the remedy is to stop using a consumer tool. A commercial API account or an enterprise agreement with a DPA, plus ZDR if your use case qualifies for it, addresses the substance of most clauses in this family, and it happens to be exactly the contractual-agreement limb of AICPA 1.700.040.

Read the exclusion list before you rely on it. If your workflow depends on file uploads, code execution or a hosted connector, check whether those specific features are inside your arrangement.

3. Ask for consent, specifically

The most underused path. Practitioners assume the answer is no and never ask.

A specific request works better than a general one: name the tool, name the tier, name what data would be sent, name the retention and training terms, and offer the alternative. Clients who would refuse "can I use AI on your file" quite often approve "I would use a commercial account under a data processing agreement with no training on your data and 30-day retention, for the model structure only." You have also just created a written record, which is the thing your professional obligation actually wants.

4. Run a local model

If the clause prohibits any third-party processing, a model running on your own hardware is the only remaining option that keeps AI in the workflow. The trade is real: local open-weight models are meaningfully behind frontier models on multi-step numerical reasoning, and financial reasoning is one of the areas where the gap shows. For structural work, boilerplate and formula debugging on a straightforward build, they are usable today. For a complex model, they are not a substitute.

Most practitioners in finance do not know this is even possible. It is worth two hours of your time to find out where the ceiling is for your own work, rather than assuming it either solves everything or nothing.

What not to do: the quiet regression

The most common response to a restrictive clause is none of the four above. It is to keep using the same consumer tool, and simply be vaguer about it. Paste less. Describe the problem in general terms. Rename the client.

This is the worst available option, and it is worth naming clearly.

It does not actually achieve compliance, because "less confidential information" is not "no confidential information," and a pasted formula from a live client model with the numbers changed is still derived from confidential material. It removes the audit trail, because the work is now happening in a chat window nobody can reconstruct. And it degrades your output, because you have deprived the model of the context it needed while keeping every risk that mattered.

It also has a measurable cousin. In one analysis of 22.4 million enterprise AI prompts and uploads, financial data (projections, investment analysis, sales pipeline) was the single largest category of sensitive information detected, at 16.6% of all exposures (Harmonic Security, 2025, vendor telemetry rather than a representative panel). The vagueness strategy is how most of that happens: not deliberate exfiltration, just practitioners who believed they were being careful enough.

Pick a real path. An informal one is not a path.

Where a model layer helps, and where it does not

Full disclosure of the obvious: we build Layerz, a workspace that holds a financial model as structure separate from data, which Claude drives from the outside through MCP. So take the following with the appropriate suspicion, and note what it does not claim.

It does not make you compliant. If you point an AI at a model that contains your client's real numbers, those numbers go to the model provider exactly as they would from any other tool, and no architecture changes that. Anyone telling you otherwise is selling you something.

What separating structure from data does change is that workflow #1 above stops being a discipline you have to maintain by hand and becomes the default shape of the work. The logic, the dependencies and the timeline are one object. The values are another. You can hand the first to an AI and keep the second out of scope, then export a clean Excel file and populate it where the confidentiality obligation lives. That is a narrow claim, and it is the only one worth making.

The related question of whether the tool itself introduces new exposure, through dynamic code execution on files you did not author, is a different problem covered in AI and Confidential Financial Data: What Actually Happens to Your Numbers.

The checklist

On the contract:

Get the actual clause in front of you. Which of the three prohibitions is it?
If it is ambiguous, it is a client question, not an assumption.

On your setup:

Which tier are you on? Consumer subscription or commercial account with a DPA?
If you rely on ZDR, have you checked your specific features against the exclusion list?
Would you be able to describe your data flow to the client in three sentences? If not, you do not yet know what it is.

On the work:

Which parts of this engagement need real numbers, and which are structural?
Can the structural part be done on a model that contains no client data?
Is there a record of what the AI touched, or only a chat history?

The bottom line

A clause prohibiting confidential data in a generative AI system is not a prohibition on using AI. It is a constraint on which data, on which tier, and with whose consent. Practitioners who read it as a total ban give up most of the value while frequently retaining the actual exposure, because the vagueness workaround is not compliance.

The most durable answer is also the least technological: keep the confidential figures out of the part of the work you delegate. That was good practice before any of this existed. The tooling question is only whether your tools let you draw the line cleanly, or force you to hold it in your head.

The Finance Engineer Job Description Is a Spec for Infrastructure Nobody Has Built

anthomakr — Mon, 27 Jul 2026 09:21:39 +0000

VulnCheck, a security company in Boston, is hiring a Finance Engineer. The posting asks the hire to connect the GL, billing, CRM and spend management systems "via API/MCP." To build Claude-powered workflows that draft variance commentary and flag anomalies. And to own the financial model's technical architecture, "including version control and forecast logic."

Read that last one again. Version control. For a financial model. Owned by someone whose team is listed as Finance.

That is not really a job description. It is a systems requirement, written by a company that needed a capability, found no product that provides it, and hired a person instead.

We went looking to see whether this was one unusual posting or a pattern. It is a pattern, and the pattern says something uncomfortable about the tooling underneath.

What the postings actually say

So we counted. In July 2026 we queried the public job board APIs of 1,061 candidate employers across the US and Europe, scanned all 27,278 open postings on the 421 live boards that answered, filtered on the department each employer assigns to the posting itself, and coded every survivor from full text. That produced 37 qualifying requisitions across 26 employers, published with the full method, the adjudication rules and the corpus in The Finance Engineer Role: Job Posting Statistics. Three findings matter here.

Nobody agrees what to call it. Thirty-seven requisitions, thirty-seven distinct titles. No two employers word it the same way, and exactly one calls the job plainly "Finance Engineer." The rest are Agentic Finance Engineer, Tech Lead for Finance & Supply Chain Engineering, Head of Engineering for Finance Systems, Finance System Architect Manager, Order to Cash Track Lead for Finance Engineering, and so on. Sixteen of the thirty-seven carry no finance word in the title at all: Brex's "Data Engineer," OpenAI's "Workday Engineer," Attentive's "Anaplan Application Developer," ElevenLabs' "Systems Architect," each sitting inside a finance or accounting department. A title search cannot find this population, which is the first thing anyone counting it should know.

It is also rare. Of the 987 open finance-department roles across those 421 employers, 26 were engineering roles. That is 2.6%, or one in thirty-eight. This is not yet a wave. It is a small number of companies making a specific and expensive bet.

And they are making it alone. The obvious alternative is to let a vendor deploy an engineer instead, which is exactly what the forward deployed engineer boom is for. On the same boards there are 348 open FDE postings across 66 employers. Precisely one requisition is finance-facing. Widen it to every deployment-shaped role, solutions architects and implementation engineers included, and you get 545 requisitions of which 14 touch finance, nearly all of them presales attached to a platform sale. Nobody is coming to build this for you.

And it is not only an American story. A dedicated European pass over 91 additional employer boards found the role in Germany, the UK, Spain, Sweden and Poland: Helsing hiring a Finance Data Engineer in Munich, Zilch a finance analytics engineer in the UK, Celonis a Finance Systems Engineer in Madrid, Lovable a Financial Systems Engineer in Stockholm. Europe runs at 1.9% of finance-department openings against 2.6% in the US, so the gap is real but narrow. What Europe does not have is the vocabulary: not one European posting calls the job a finance engineer.

It mostly, but not always, sits in Finance. Twenty-six of the thirty-seven are placed by their employer in a Finance, Accounting or Finance Systems department: Anthropic, OpenAI, Coinbase, Databricks, Brex, Stripe, Twilio, Attentive, Cloudflare, SoFi, Mercor, Affirm, VulnCheck. Where a reporting line is spelled out, it names a finance leader: VP of FP&A, Head of Finance Systems, Senior Manager of Finance Data and AI.

The eleven exceptions complicate the tidy version of this story. Klaviyo runs an entire "Finance Engineering" function out of IT & Security. Block puts a Senior Finance Systems Engineer in Engineering, CoreWeave and Epirus theirs in IT, Harvey in Product, Whoop in Business Intelligence. So the direction of travel is real, and finance is staffing its own systems rather than filing tickets for them. But roughly one role in three is still owned outside finance, and anyone claiming the shift is universal has not counted.

It wants two careers in one person. Spring Health's Senior Finance Engineer posting asks for "4+ years designing and deploying automation, AI, and/or ML systems in Finance" and, separately and additively, "4+ years in FP&A, Strategic Finance, Accounting, or Finance Transformation." Its named tool list runs NetSuite, Pigment, Airbase, Claude, ChatGPT, Gemini. Commercial LLMs, listed by name, in the requirements section of a finance role.

The tell is in what these postings assume already exists

Strip the postings down to their verbs and a shopping list appears. Across the corpus, employers casually assume the following are available to a finance team:

Version control over a financial model. Not over a file. Over the model: what changed, when, by whom, and what it moved downstream.
An API surface over financial logic, not just over financial data. Model Context Protocol is now named by protocol in four postings across three employers, all inside finance departments: VulnCheck, ElevenLabs, and both of OpenAI's Enterprise AI Platform roles. An agent interoperability standard released in late 2024 has become a line item in corporate finance hiring.
Conventions that persist between sessions and between people. When the posting says "assemble reporting packages," it assumes the definition of ARR used in October is the definition used in March.
An audit path from an output number back to the assumption that moved it. Every posting mentioning close, variance commentary or ASC compliance assumes this implicitly.

Every one of those four is unremarkable in software engineering. Git, APIs, schemas, commit history: solved decades ago. None of the four is standard in finance. And the reason is not that finance teams are less sophisticated. It is the substrate.

It is also expensive, and the shape of the expense is the tell. Seventeen postings disclose a US base range, spanning $112,000 to $385,000, with a median band midpoint of $231,500.

The sharper number comes from OpenAI, which publishes structured bands on every role and has enough openings to compare like with like. Its five finance-department engineering roles carry a median band midpoint of $307,500. The other forty-five roles in the same finance department: $228,000. Its two hundred and ninety-seven product engineering roles: $309,000.

So a finance-department engineer there is paid 35% above the rest of the finance organization, and within half a percent of a product engineer. The premium is not for finance expertise, and it is not a cost-centre discount. These companies are paying full engineering rates for engineering work that happens to sit in finance, which is what you do when you have concluded the capability has to exist and no vendor sells it to you.

The spreadsheet is an excellent calculator and a poor substrate

This is worth saying plainly, because the anti-Excel genre is tiresome and mostly wrong.

Excel is extraordinary at what it does. It is the lingua franca of finance, readable by anyone in the building without training, the format your investor and your auditor and your acquirer all accept, and the fastest way in the world to answer a question with numbers. Nothing here argues for replacing it as the deliverable. It is not going anywhere and it should not.

But a spreadsheet has properties that make it a bad foundation for the four requirements above:

A file copy is not a version. Model_v4_FINAL_rev2_JD.xlsx records that something changed. It does not record what, or why, or what it broke.
The API is over cells, not over logic. You can read D14. You cannot ask what D14 means, what feeds it, or whether it is an input or an output. That distinction does not exist in the file format.
Intent does not persist. The reason a growth rate is 12% lives in the modeler's head, or in a comment, or nowhere.
There are no types. 0.12 might be a tax rate, a margin, a churn assumption or a rounding artifact. A human infers it from context. An agent guesses.

So when a company writes "own version control and forecast logic for the financial model," the honest answer available to a finance engineer today is a stack of workarounds: a naming convention, a folder of .xlsx files in a git repo that nobody can meaningfully diff, and a page of documented conventions that goes stale within a quarter. It works right up until someone changes an assumption and half the links quietly stop following.

That is the gap the job postings are papering over with a hire.

"We will ask for examples"

There is a second thing happening in these postings, and it is the part most likely to change how the role is filled.

Finance hiring ran on credentials for a long time, and for a defensible reason: the work was invisible. It lived inside someone else's ERP, under an NDA, in a file you could not take with you. There was nothing to show, so people showed a CPA, an MBA, a bank on the résumé.

The postings in this corpus are not asking for that. They are asking what you built. The automation you shipped, the close you cut from seven days to two, the agent workflow your team actually uses. That shift only works if the work is showable.

Here is the problem: most finance work still is not showable. A spreadsheet is something you attach, not something you show. It carries your employer's real numbers, it takes forty minutes to explain, and its structure is inseparable from its data, so you cannot share the thinking without also sharing the confidential inputs.

A model whose structure is separable from its data is a different artifact. The logic, the dependency graph, the conventions, the timeline: shareable, forkable, reviewable, and provably yours, with nobody's actuals inside it. That is a portfolio piece. It is also, not coincidentally, the same property that makes version control and API access possible in the first place.

What a substrate for this role would need

If you are stepping into one of these roles, or writing one of these job descriptions, the underlying question is what you build on. The requirements are consistent enough now to name:

Structure separated from data, so the logic can be versioned, reviewed and reused without dragging the numbers along.
A dependency graph that is explicit, so a change to an assumption produces a knowable set of downstream effects rather than a surprise.
Conventions written down in a form the tooling reads, not just the humans. This is what FINANCE.md is for: currency, units, sign convention, what your organization means by ARR, carried with the model instead of in someone's memory.
An agent-addressable interface, because the postings already assume the LLM is in the loop. If your agent has to re-read the entire model to change one number, you will pay for it in tokens and in drift.
Excel on the way out, always. The deliverable is still .xlsx. A substrate that traps you is worse than the spreadsheet it replaced.

Layerz is built for exactly this shape: structured models an agent drives over MCP, with the structure versioned separately from the data, and clean Excel export that is never paywalled. It is worth being clear about what it does not do. It is not an ERP and will not run your close. It does not replace NetSuite, Workday or your billing system, which are the systems most of these postings spend their time integrating. And if your work is genuinely one-shot analysis, a spreadsheet and a good prompt will beat it on speed every time.

Where it earns its place is the part the postings keep describing and no spreadsheet can hold: a model that persists, that an agent can change without breaking, and that you can hand to someone else with the reasoning intact.

The bottom line

The finance engineer role is real, it reports into Finance, and it is being asked to deliver software engineering guarantees on top of a substrate that offers none of them. Right now the gap is being closed by hiring unusually capable people and letting them improvise infrastructure out of file naming conventions.

That works, for a while. It is not a foundation. The postings have already written the spec. The question is only whether the person filling the role has to build it from scratch.

Layerz is a financial modeling substrate that keeps a model's structure separate from its data, versioned, and drivable by any AI agent over MCP or REST. Finance teams use it as the layer their agents and their Excel exports both sit on top of. Explore Layerz

The corpus behind this piece is open: 37 requisitions, 26 employers, method and exclusion rules published, with the coded data on Hugging Face under CC BY 4.0. Recount it and disagree if you think we drew the line in the wrong place.

Why Finance Agents Need a Model Layer, Not Just Spreadsheet Access

anthomakr — Thu, 02 Jul 2026 13:14:25 +0000

You have built the agent. It calls a spreadsheet via API, reads the relevant cells, and produces something useful: a variance analysis, a scenario update, a summary for a board meeting. It works. Until you change the spreadsheet layout. Or until you start a new session and have to explain the model structure all over again. Or until the agent produces a number that is technically correct from the cell values it read, but violates a convention you have maintained for three years without anyone knowing to encode it.

Connecting an AI agent to a spreadsheet is a reasonable first step. It is not a model layer. And the difference turns out to matter a lot for anything you would call real financial work.

What spreadsheet access actually gives an agent

When an agent reads a spreadsheet (through an API, a plugin, or a code execution tool), it gets cells. It can read values, detect patterns in ranges, and make inferences about structure from formatting and proximity. That is more than nothing.

What it does not get:

Types. A cell with the value 0.12 could be a tax rate, a growth assumption, a margin, or a rounding artifact. The agent does not know.
Dependencies. Whether that 0.12 feeds into three downstream formulas or is an isolated value, the agent cannot see this without parsing every formula string in the file.
Timeline semantics. Which columns represent months vs. years, where the actuals end and the forecast starts, whether a value is per-period or cumulative: all inferred, none explicit.
Roles. Whether a line is an input assumption, a formula driven by other lines, an aggregation, or an output: these are categories that do not exist in spreadsheet format.
History. What the value was last week. What changed and why.

For a one-shot query ("what is the EBITDA in 2026?"), this is fine. For anything iterative (updating assumptions across scenarios, understanding why a number changed, rebuilding context across sessions), spreadsheet access is a thin foundation.

The session reset problem

The most underrated cost of running agents on spreadsheets is the context overhead on every new session.

A well-built financial model has logic that took days to develop: revenue drivers, cost structure dependencies, debt waterfall rules, EBITDA normalization conventions. An agent working on this model in session one learns all of this through your prompts and its own inference. Session two starts from scratch.

You re-explain the model structure. You re-establish the conventions. You re-orient the agent toward the right interpretation of ambiguous cells. Then you do the actual work. For anyone running regular AI-assisted financial workflows, this overhead compounds quickly.

A model layer solves this structurally. The model's structure (its variables, their types, their dependencies, their timelines) is stored and queryable. The agent reads it at the start of every session without explanation. The context is persistent, not reconstructed.

The convention problem

Financial models carry organizational conventions that are not visible in cell values.

Your EBITDA excludes IFRS 16 lease costs, a decision made three years ago for comparability reasons. Your FX rates are ECB end-of-period, not average, because an auditor asked for it once and it became the standard. Restructuring charges from 2024 are excluded from adjusted figures: that was a board decision, documented in a memo nobody can find anymore.

These conventions are real. They are defensible. They are the difference between your numbers and a competitor's numbers when a PE board asks why the EBITDA margins differ. And they exist nowhere in the spreadsheet.

An agent working on your model does not know any of this. It calculates what the cells tell it to calculate. It reports what the formulas produce. If the conventions are not encoded somewhere the agent can read, every run is a convention violation waiting to happen.

This is what FINANCE.md addresses: a structured file that encodes organizational financial conventions in a format any agent can read at session start. EBITDA definition, FX policy, restatement rules, declared once, versioned, queryable. The agent knows the rules before it touches the numbers. See the FINANCE.md open standard for the specification.

What a model layer actually provides

A model layer sits between an agent and a data store. It exposes not just values, but structure.

Typed variables. Every variable in the model has an explicit type: assumption, formula, aggregation, output. An agent knows whether it is looking at an input it can change or a derived value it should only read.

Dependency graph. The relationships between variables are explicit and traversable. An agent updating a revenue growth assumption knows which downstream variables will be affected before it makes the change.

Timeline semantics. The model's temporal structure is declared: monthly, quarterly, annual, the start and end of the forecast, where actuals end. The agent does not infer this from column headers; it reads it from the model definition.

Query interface. An agent can ask "what are the revenue drivers?" and get a structured answer, not a range of cells to interpret. It can ask "what changed since last week?" and get a diff, not a request to compare two file versions.

Convention encoding. The model layer stores not just the structure but the rules: what this organization means by EBITDA, how FX is applied, which items are normalized. These travel with the model, not with the analyst who built it.

When spreadsheet access is enough

This distinction only matters for agents doing iterative, multi-session financial work with real conventions and real stakes.

For one-shot automation ("pull these ten values from this spreadsheet and put them in this report"), spreadsheet access is entirely sufficient. The agent reads cells, formats output, done. No model layer needed.

The model layer becomes necessary when:

The agent needs to modify the model, not just read it, and modifications need to respect the model's logic
The agent operates across multiple sessions and cannot reconstruct context each time
The model's conventions need to be respected, not just its formulas
Multiple people or agents work on the same model and need consistent interpretation
The model's history matters: what changed, when, and why

For finance professionals building agent workflows around their core models (budget, deal model, unit economics), these conditions are almost always present.

The bottom line

The gap is not whether AI can work with financial data. It can. The gap is whether the infrastructure behind the agent is designed for financial logic: structured variables, typed dependencies, persistent conventions, traceable history.

Spreadsheet access is a starting point. For agents doing real financial work (iterative, multi-session, convention-bound), it is not enough. The model layer is what makes the agent's output defensible, its context persistent, and its conventions consistent with what your organization actually means by its numbers.

If you want the numbers behind this, we keep a source-backed library on AI in finance and AI financial model risk, every figure linked to its primary source.

Layerz is a financial modeling infrastructure that exposes structured model layers to AI agents via REST API and MCP. Finance professionals use it to build agent workflows where context persists across sessions, conventions are encoded and versioned, and every output is traceable. Explore Layerz.