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 →
Top comments (0)