Every month, a finance team checks its own cash records against the bank statement, and every month the same kinds of differences turn up. A fee nobody booked. A payment still on its way. A number typed wrong. So the pitch for AI agents with memory is easy to make: the agent remembers how last month’s difference was settled, recognises this month’s, and handles it.
Most of the time, that would work. Here’s the time it doesn’t.
Last month, the bank charged a 45.00 custody fee that the firm hadn’t booked. The agent proposed “unbooked fee, book it”, and a person approved. This month, a 45.00 custody fee from the same bank turns up unmatched again. Same amount, same counterparty, same description. An agent that remembers answers will say what it said last time.
But this month the firm did book its fee. The unmatched line is a second charge: the bank took the fee twice. Copy last month’s answer and the firm books the same fee twice, and the 45.00 it should be reclaiming disappears into its expenses. Nobody notices, because the answer looked exactly like one a person had already approved.
The two fees sit near what researchers call a decision boundary: a place where cases that look almost identical were decided differently. Finance is full of them. The same amount from the same counterparty can be a timing difference one month and an error the next, and nothing on the surface tells you which.
A paper from Amazon, presented at a workshop at ICML this year, describes what happens to agents there (Dong and Shang, 2026). Most agents that learn from experience store past cases one by one and pull up the most similar ones as examples. Near a boundary, that gives them similar examples with conflicting outcomes and nothing to explain the difference.
Their fix isn’t to forget. When their system meets two similar cases that went different ways, it writes down the smallest thing that separates them, and refines that as more cases arrive. Instead of copying examples, the memory turns experience into an explicit rule. And the authors add a caution I’d underline: in high-stakes work, those learned rules should be decision support that experts review, not authority.
This matters more now because agents are about to get a lot more memory. Last December, Jaya Gupta and Ashu Garg of Foundation Capital argued that companies record what happened but not why it was allowed to happen: the exceptions, the approvals, the precedents. They call that record a context graph, and expect it to become the foundation for agents, with autonomy growing as similar cases repeat and precedent becomes searchable.
On the first half, I agree completely. A record of who decided what, when and why is exactly what an auditor wants and what most systems throw away. What I’d add is a condition for the second half: a repeated decision should start a search for a rule, not justify automation on its own. Searchable precedent is what puts the 45.00 fee in front of the agent this month. The question is what the agent is allowed to do with it. A context graph can preserve why a decision was made. It can’t turn a previous approval into permission for the next case.
The line I’d draw is this. The history of the same item is evidence, though a past decision isn’t proof of where it stands now. When a payment booked last month finally reaches the bank, its history tells you which open item to look for, and this month’s bank line, linked to that item, shows it has cleared. A past decision about a different item that looks the same is only a hint about where to look. It can never be proof. Put simply: don’t let an agent inherit a conclusion without the conditions that made it correct.
That line shouldn’t depend on the agent being honest about itself. A log of every record shown to the agent tells you when it saw a decision about another item, though not whether that decision influenced its reasoning. That’s why the check before a proposal is accepted matters most. It shouldn’t ask how much evidence is attached. It should ask whether the cited records establish what this item needs, under the rules that apply to it. A look-alike’s approval never does.
If memory can’t supply the answer, what is it for? Go back to the 45.00 fee. Last month shouldn’t tell the agent “this is an unbooked fee”. It should tell it what to check. Is this month’s fee already booked, and matched to another line? Does the fee schedule allow a second custody fee this month? Do the amount and billing period match the schedule? Last month answers none of those questions. It tells the agent they’re worth asking, and this month’s records answer them. The first two catch the double charge: the firm’s fee is booked and already matched to one 45.00 line, and the schedule allows only one, so this second line isn’t a fee the firm owes.
That’s the shift I’d make. An agent that has seen many months shouldn’t be quicker to conclude. It should be better at knowing where to look. Memory makes the questions sharper, and the evidence still has to answer them. The agent still proposes an answer; memory changes what it checks before proposing one, not whether it proposes.
Sometimes the evidence won’t settle it: a record is missing, or two sources disagree. Memory can tell the agent what might be missing, but it can’t turn an absent record into proof. Then the right answer is “not clear yet”: the item stays open, carried into next month with a reason, rather than closed with a confident guess.
Others are moving the same way. Agent Workflow Memory has agents learn reusable routines from past tasks, and Google’s ** ReasoningBank** keeps strategies and lessons from failed attempts rather than past answers. What finance adds is a strict line between the two: how you investigated last time can guide this investigation, but only this month’s evidence can settle it. None of this research is about finance, so it suggests a principle rather than proving one. Whether it holds for reconciliation is what I still have to test.
This doesn’t mean the agent never gets faster. It means it earns speed the right way.
Suppose the same question keeps getting the same answer from the evidence, month after month: the fee arrives, the firm hasn’t booked it, the amount matches the schedule. At some point that stops being an investigation and becomes a pattern worth automating. The agent can draft that rule itself: the condition the evidence kept confirming, tested on months it wasn’t built from, with a report of what it would have matched and where it would have failed. A person reviews that and approves it before it joins the rules the system runs before any AI is involved. What the agent can’t do is quietly promote its own pattern into a rule. Once approved, every match the rule makes records the rule and its version, the records it used and the conditions that held, so anyone can trace it and challenge it.
The test is where the boundary paper helps most. Checking a new rule against the cases it would have matched proves little. Check it against the cases that looked the same but were decided differently. One duplicate charge teaches more than three ordinary fees, because it forces you to say what tells them apart. If the rule would have got that one wrong, it isn’t ready. And repetition proves less than it seems: twelve approvals can be the same misunderstanding twelve times.
Copying last month’s answer and following a rule can look identical from the outside. The difference is where the guess lives. Copying happens quietly, one item at a time, and nobody sees it. A rule is written down, tested and approved, and when it’s wrong, its name on every match lets you trace where. So the agent’s job isn’t to remember answers. It’s to ask better questions until the evidence reveals a condition that can be tested and approved as a rule.
I’m building Liquet in public: a monthly bank reconciliation on synthetic data, where rules match, an AI investigates the rest, and a person approves. My plan for its agent was case-based reasoning: learn from past decisions and the reasons people gave, and use them to suggest why this month’s items don’t match. The custody fee example grew out of its test data.
I still think the past is the agent’s best teacher. Reading the research changed what I think it should teach. Not answers to assume, but questions to ask. The memory stays the same; its job changes.
Liquet doesn’t train a model to learn these questions. Its workflow defines the investigation, and its graph connects the current item to relevant records and past decisions. The next step is to use that context to identify which checks matter for this case, rather than treating a similar case as a reusable answer. Whether that improves investigations is something I still have to measure.
Don’t teach your agent the answer. Teach it the question, and let the evidence answer.
I used Claude to help with research and editing. The ideas and the project are my own.
Your AI Agent Should Remember the Question, Not the Answer was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.