Stop Chatting With Spreadsheets — Francesco Galletta & Felippe Felisola Caso, Monzo

A financial analysis can finish in the background while its owner does something else. If the owner then has to reconstruct the work before acting on it, the fast answer has saved very little. Francesco Galletta and Felippe Felisola Caso bring that problem from their work in data at Monzo to a personal finance workshop, speaking in their own capacity. At work, they judge an AI project by the business benefit it produces. At home, Galletta has a similarly practical test. Can he hand off the tedious calculations and trust the result with his own money?

The workshop’s harness is the software around the model that guides the interview, runs calculations and gives the user access to the decisions behind an answer. A trace can show where a number came from. A unit test can catch a broken calculation. The builder still has to decide which assumption a person needs to see before committing money. The speakers organize those choices around five principles. Shared domain establishes what the user means. Consistency makes the arithmetic repeatable. Evidence records what went into it. Accountability gives the person who bears the consequences a say in the decision. Verification brings in a perspective that can challenge what both the user and the agent have accepted.

Galletta has an ulterior motive for convening the room. He needs help working out whether he can make each wedding payment on time. He and his fiancée have already found that a perfectly reasonable number can answer the wrong question. She has the price of dinner. He is counting two additional variable costs on top of dinner. Multiplying the dinner price by the guest count would faithfully reproduce just one part of the bill.

Participants can open an empty workspace for a financial question of their own or load a worked wedding example. The repository includes a setup guide, the harness, the example and a place to save their own work. A successful local setup opens the UI. The empty workspace is where Galletta demonstrates the interview. The prepared plan is where participants can inspect decisions, run tests and try corrections without first having to agree on every wedding expense. Repository QR code and setup instructions at 14:21

In the empty workspace, Galletta dictates the problem into the chat on the right. He owes three payments. The first is $6,000, the second is an unknown amount, and the third covers the remaining balance. The DJ is a fixed cost. Dinner is priced per seat, and attendance is uncertain. Even a correct total for the wedding wouldn't tell him whether he can pay on time. For that he needs the amount due at each deadline and the cash available by then.

What can the planner establish from that first request? The harness instructs the agent to interview the user and specifies what it needs to learn before proposing a plan. Galletta supplies the next details in deliberately untidy order. For the exercise, he has no savings, his mother may contribute 5,000, the price per person is around 150, flowers cost 500, and he still needs a suit. The qualifiers matter as much as the numbers. Counting a possible gift as available cash could make a payment look affordable before a single arithmetic error had occurred.

The follow-up questions put some work back on the one person who knows this wedding. A model can recognize a term and still misunderstand what the user includes in it, just as two people can mean different things by the cost of dinner. The interview gives the user a chance to catch that difference before it becomes a formula. Galletta asks for a proposed plan to keep the exercise moving, then switches to the prepared example to show what comes out of a fuller exchange.

The prepared example picks up after roughly ten minutes of earlier discussion. Its accepted plan breaks the problem into decision points. The graph on the left shows how those points connect, and the plan appears at the upper right. This is an implementation choice in the interview instructions. Specifying what the agent must produce means the user finishes with individual decisions they can reopen.

Who put a particular assumption into the plan? Selecting step three brings up the source of its information and the reason the agent considers it a decision. In the worked example, a word Galletta used prompted an inference about what he meant. The annotations distinguish what he supplied, what the agent proposed and what still needs a decision. Accepting the plan leaves him free to question that inference.

The next exercise is to select step two and challenge an assumption there. In a long chat, a correction joins every earlier proposal, detour and correction in one stream. After ten or more exchanges, it can feel easier to start over than to recover what was agreed. Attaching the discussion to a node gives the user a way to revisit one question with the rest of the plan still in view.

Some nodes in the accepted plan are ordinary calculations. Given the same head count and price per seat, the dinner line should have the same value on every run. Galletta recalls a chat response that typeset a formula beautifully and followed it with a result so far off he could spot the error in his head. The typography had done a better job of convincing him than the arithmetic.

An audience member presses the objection. If the model also writes the code, what has improved? Saving an implementation makes it possible to inspect and test the method independently of the conversation. A forecast can call an established library. A custom calculation can be broken into functions with unit tests, then checked end to end. Asking the agent to generate fresh code for each question gives up much of that benefit. The hundredth run could quietly use a different implementation under the same description.

Galletta ran into this while closing his own monthly budget. He let an agent categorize statement entries, aggregate them and handle refunds and expenses. It got the result he wanted three times and missed on the fourth. Reconciling the slight differences cost time and money. His correction was to put the repeatable work in a script. The model can still choose a tool for the problem. Once the method is settled, next month’s close can run the same calculation.

Which implementation produced a figure? The wedding graph identifies nodes that need code, and the UI offers to build that code once the user accepts the plan. Galletta also describes a practice from other implementations that matters on repeat runs. Record the version of the code and flag a change, even if the function has kept its name. A result earned with an earlier formula tells you little about what the revised one will do.

To inspect the first wedding calculation, select step one, open Code, open Tests, and run the tests. The tests execute in the participant’s environment. There is no model deliberation to wait for. The prepared tests are expected to pass, and the same action is available after an edit. Putting the tests beside the node gives the user a way to check the implementation at the point where they depend on it.

The repository’s build-your-own guide works a little like an IKEA guide for the harness. It gives each component a job, such as gathering enough information to propose a plan, and leaves the implementation choices to the builder. An audience question about spec-driven development brings out the result of that choice. The saved workspace acts as a specification. As the wedding changes, the analyst can revisit a decision or a calculation through its own workflow. A single growing document would ask the agent to interpret the whole specification afresh.

Changing an input and changing a definition are different operations. A new guest estimate can go through the existing calculation. A change to what a metric counts may require new code. The suggested stress test is to replace a multiplication with an aggregation and save the file. The edit can save successfully even though it breaks the analysis. On rerun, a failing test is designed to stop the harness before it draws a conclusion from that node.

Suppose Galletta supplies the number of people invited and his fiancée has just invited three more. The code can calculate dinner costs correctly for a head count that is already out of date. Evidence lets someone work backward from a total to the input the calculation used, then ask who supplied it and what that person knew.

Three kinds of information can end up looking equally certain in a cell. The harness needs to preserve the difference.

• Interpretation. Turning an unstructured remark in chat into a budget item requires a reading of what the person meant.
• Assumption. A value the agent infers or recalls needs to remain identifiable as its contribution.
• Recorded fact. A bank statement documents the amount of a recorded transaction. That amount has a different standing from an estimate of a future expense.

In Galletta’s master-file story, someone entered familiar numbers into the spreadsheet everyone used on the shared drive. Everything looked fine. The file had changed, including its assumptions about the range of reasonable values, and the person using it had no reason to know. The inputs stayed the same and the results were entirely wrong. Tracing the origin of every input would have missed the problem. The trail also needs to identify the process that transformed those inputs and what changed in it.

Which part of the wedding plan came from the assistant? The evidence view highlights where information entered the plan, including the assistant’s proposals. A financial analyst might need finer detail still, down to the supplier or connector that reported an Apple share price at a particular time of day. The follow-along exercise tests the same idea with a chat message. Enter a correction, inspect the affected inputs, then select an underlined figure that changed. Its trail should lead back to the user’s correction and explain why it matters to the rest of the calculation.

A slide-building experiment shows how easily an example can acquire the status of evidence. Galletta’s agent gathered relevant documents and helped pick points for a team presentation. During revision, he supplied an example to explain a change. The model repeated it throughout the deck. When senior leaders asked where a number and an assumption had come from, he couldn't account for them. An instruction about how to edit had become a claim about the business.

The person who acts on the analysis bears the consequences. Asking that person to press Enter for every edit spends their attention quickly. One participant describes reviewing a task, letting the agent carry it out and reviewing the result. The financial equivalent is to let the system evaluate three scenarios, then put them side by side for the person making the choice. A test can settle whether a function still performs its calculation. Choosing which scenario to budget for calls for judgment.

What timing assumption could change the savings decision? The prepared wedding plan has one final human checkpoint. Galletta reviews the scenarios and chooses how much to save each month. One assumption worth opening is an incoming 20,000 expected on the same day as payment three. Sharing a calendar date still leaves a question about whether the cash will be available when the payment is due. Accepting that premise records a decision that later work can use. The exercise stops at choosing a savings amount, short of transferring money or reporting a final figure.

A user can also reopen a decision after learning something new. Hover over the guest-count chip, add that item to the chat and tell the planner to expect no fewer than 150 guests. That supplies a lower bound. It changes which attendance scenarios make sense and, through the per-seat costs, what those scenarios cost. The planner can suggest a change to the plan or revise the input if the existing calculation already fits. The history distinguishes an assumption the user allowed to stand from one they corrected.

Step five offers a different exercise. Open a branch conversation and explore a question about that decision. Galletta had often opened an entirely separate chat to ask a speculative question because a stray sentence in a long conversation could redirect the analysis. A branch gives the aside a home beside the decision it concerns. Whether its conclusion should enter the main plan is a separate choice.

A second pair of eyes can catch something the author has stopped seeing. It can also become a way of handing a colleague a pile of plausible work and making them responsible for every mistake. Galletta’s model for verification comes from finance teams. An experienced reviewer opens a spreadsheet, checks a few cells that reveal the rough total, and asks how marketing could possibly have spent that much. The discrepancy tells the analyst where to investigate. Responsibility for the analysis stays with its owner.

Golden examples give a test known cases with expected answers. They also reflect the cases their author chose. In an earlier business intelligence project, a query looked sound, its result seemed reasonable and the analyst’s checks found nothing wrong. A stakeholder from another team saw the dashboard and immediately questioned it. They knew roughly how many sales the company had made that year. That outside estimate exposed a discrepancy without requiring the stakeholder to read SQL. The tolerance for a discrepancy also comes from the people using the result. A figure within 5% might look plausible while missing by enough to change the team’s decision.

When does a review actually change the wedding plan? A separate agent reviews the plan and its assumptions. The user can open a tagged challenge in a branch, and a decision can carry a note with an outside point of reference. These contributions have different jobs. The second agent can raise a question. An independent source or a person’s domain knowledge can supply the evidence to resolve it.

The fork has two outcomes. In the demonstration, a branch rejoins the main conversation and changes the plan. The join records where that revision came from. The companion exercise is to open another challenge and dismiss it when it has no bearing on the decision. Giving the review a route back into the analysis matters more than collecting verdicts. A judge could issue an opinion after every step and leave Galletta with precisely the savings plan he started with.

The Q&A opens with a question about how many harnesses a team should build. Felisola Caso ties the decision to repeated failures, the number of users exposed to them and the cost of a wrong answer. A person doing an occasional, low-stakes task may be happy to steer an existing agent for a few more turns. A team of 50 credit analysts using the same tool to support key company decisions has a stronger reason to control variation. The five principles reflect the stakes in finance. Producing a stream of social videos, Galletta suggests, would put a different value on gathering evidence for each output.

Galletta’s warning about spending too long sharpening the axe comes with a practical test. Try a skill or a command and watch what the user still has to do by hand. If the same task repeatedly involves opening a fresh session, copying text from another chat and explaining the context again, that sequence is a candidate for software. His wedding provided both outcomes. Web search produced a usable shortlist of five Madrid photographers to compare. Financial planning by voice had him repeating the same conversation three times on a drive. He could point to the work a dedicated harness would save.

Another participant asks how to talk to leadership when mentioning AI seems to raise expectations of accuracy. Felisola Caso starts with a measurable outcome. If a new dashboard takes too many exchanges to validate, count the exchanges. If users keep opening internal tickets because a number looks wrong, track those tickets. These are proposed ways to evaluate the change. They give a team and its leaders something specific to look for once people start using the tool.

One participant already has a skill that asks questions and runs the numbers with a Python script. Why add a UI and a database? The script can perform repeatable arithmetic while the model still decides whether to call it and how to interpret the surrounding instructions. Distribute that skill to other users and their own agent settings may conflict with it. For a critical calculation, even an occasional decision to skip the script can defeat the purpose of writing it.

Felisola Caso had seen the cost in reviews of internally shared extensions. Teams would add prose for each unsupported case, down to what the agent should tell a user who tried it. Each new clause became another instruction the model had to interpret. Backend code can decide which operations are available and enforce those conditions directly. The reason to move a rule into the harness is that users need it to hold across runs.

There is still room for interpretation. A cash-flow figure can look odd because someone attributed revenue a month later. Recognizing that possibility is a different job from adding the entries once their dates are settled. The checks build confidence together, and that confidence has a limit. Galletta’s illustration is financial: even a 1% error can represent a lot of money. The percentage describes what a small error could cost, rather than a measured failure rate for the harness.

The final audience question asks where, exactly, a user can see trust in the UI. For someone puzzled by a total, the answer spans several places. They can follow the input to its source, inspect the code that ran and see how it was tested. Someone worried about paying on time may care more about opening the challenge to that incoming 20,000. Both are looking at the same plan. The interface earns its keep when the person about to make the decision can follow the particular doubt they have.