A financial AI agent must show its work

Francesco Galletta and Felippe Felisola Caso want to stop treating financial analysis as a conversation with a spreadsheet. Both work in financial-services data at Monzo; Caso builds AI tools for internal data-team productivity. They use a personal example rather than presenting the workshop as Monzo’s product.

Caso says he came to data after studying electrical engineering and working across startups and larger companies. At Monzo, he focuses on helping the data team work more effectively with internally built AI solutions.

Caso says the team approaches AI adoption in terms of impact: spending more tokens is not a goal if it does not deliver concrete business value. Outside work, Galletta has also been experimenting with AI on personal problems that he actually needs to solve.

Galletta argues that the bottleneck in financial analysis is no longer simply producing an answer quickly. The harder question is whether the person who must act on that answer can trust it, particularly when money is at stake.

Galletta uses “financial analyst” broadly, from research for investment firms and banks to an individual’s personal finances. In each case, the important question is how the system connects its work with the person making the decision.

Tests, plans, evaluations and traces can all contribute to trust, but they are components rather than a complete design. The workshop asks what principles should govern the system around the model so that users can delegate work without accepting an opaque result.

The first principle is a shared understanding of the problem; the second is consistency, so calculations come from code rather than a model improvising arithmetic. Evidence connects a result to its sources. Accountability keeps consequential choices with a person, and verification brings in a separate perspective.

Galletta says accountability remains a person’s responsibility even when a hundred agents are running. He contrasts systems that evolve with their users against black boxes into which people throw problems and hope a good result comes out.

The speakers present these as one approach that has worked for them in several situations, not a universal solution. The workshop’s example is designed to let participants experience the principles and challenge the choices rather than simply inspect a list of technologies.

The example is Galletta’s wedding. A budget that sounds like a straightforward calculation becomes complicated when the price per dinner is only one of several variable costs and the number of guests changes. Participants can also try the same approach on a different financial problem.

A price per dinner alone does not capture the full cost, Galletta explains: other variable charges come on top. The example is familiar precisely because an apparently simple total depends on several assumptions that can change independently.

The workshop repository includes a worked wedding example, the demonstration harness and a place for participants to develop their own variations. The presenters say the example is deliberately built to illustrate the principles, not to serve as polished production software.

The principles build on one another: establish a shared plan, make repeatable steps consistent, expose evidence, preserve human control and check the work from another direction. Galletta cautions that neither a complete black box nor a demand to review every line is a practical answer.

The prepared example shows what a completed plan might look like, while a blank interface lets participants begin with their own problem. Galletta says the user interface is a way to experience the agent’s behavior, not the main lesson about visual design.

The first exercise begins with an empty chat and a financial goal. The model’s general knowledge of a term may differ from what the user means in a particular household or organization, so the system must encourage questions and correction rather than assume agreement.

The agent’s job during planning is to ask what it needs, challenge missing assumptions and help the user make the problem more precise. A system that simply agrees with a vague instruction and immediately implements it will produce more variable results.

Galletta describes three wedding payments: the first is $6,000, the next is uncertain and the last covers the balance. Some expenses are fixed, but the number of guests determines a per-person cost. He wants to know whether he can make the payments on time.

He adds that he has no savings, his mother may contribute around 5,000, the cost per guest is about 150 and flowers cost 500. The intentionally messy description forces the agent to separate known inputs, uncertainties and missing information instead of treating a vague request as a complete specification.

The prefilled example skips several rounds of clarification. Once the plan is accepted, the interface shows connected decision steps and highlights whether a piece of information came from the user, was proposed by the agent or still requires a decision.

Galletta describes the shared context as an overlap between what the person knows and what the model knows. Building that overlap takes back-and-forth, but it gives the system a better basis for deciding which components matter.

The interview questions themselves come from instructions inside the surrounding system. In the demonstration, hovering over a principle highlights the relevant plan and nodes, making the design visible instead of asking the user to infer how a chat response was produced.

Opening a step shows why the model included it and which assumptions it made from the user’s words. A user can challenge an assumption within that step. Galletta contrasts this with long linear conversations where an old decision can disappear into the context and the user eventually starts again.

The interface shows both a proposed plan and the connections among individual decisions. Because the plan is broken into nodes, the user can inspect a single assumption without turning every correction into a new global conversation.

Consistency starts once there is an agreed plan. Some parts are calculations: for the same inputs they should produce the same result, so the system should implement those parts as code. A polished formula in a chat window, Galletta says, can still be followed by an obviously wrong answer.

One audience member reports that financial results can look reasonable once but differ when the same request is repeated. The presenters use that inconsistency to motivate a stronger boundary between flexible language interpretation and controlled calculations.

Caso distinguishes instructions from guarantees. Telling an agent to follow many rules still leaves execution to a probabilistic model; a purpose-built system can combine that flexibility with deterministic behavior where a result needs to be controlled.

An audience member asks how model-written code differs from calculation in chat. Galletta points to trusted libraries, modular code and unit or end-to-end tests. The difference is not that generated code is automatically correct, but that it can be tested and reused under software-engineering practices.

The presenters distinguish their quickly built workshop demonstration from a production implementation. They say the same principle—combining flexible model behavior with deterministic components—can apply in either, while production engineering demands appropriate testing and design.

Galletta had an agent categorize monthly spending, refunds and expenses, only to get slightly different results on repeated runs. He spent time and money coaxing it to reproduce work it had already done. His preferred fix was a script written once and run whenever the same calculation was needed.

The model can still choose the appropriate tool, but the surrounding system should direct arithmetic to code rather than token-by-token improvisation. Otherwise each new session can invent a new implementation for a question that already had a working answer.

The wedding diagram shows which nodes need code, test cases and examples. Galletta also wants the interface to expose code versions: if a calculation changes, a user repeating the same process should see that the result may no longer be directly comparable.

A changed function can retain the same name while implementing a different calculation. The system should surface the version change so that repeating an apparently identical process does not silently conceal a different method.

Participants are invited to inspect a step, open its code and run its tests. The system should guide those checks rather than depend on a user remembering every time that a calculation needs code or that a test exists. Tests run in the environment without requiring the model to “think” through them.

A separate guide in the repository describes how to build a similar system around the same principles. The presenters call it instructions for building instructions: the builder can choose an implementation, but should know what each component is intended to accomplish.

A participant compares the approach with specification-driven development. Caso says the analysis changes as the wedding plans change, so the system breaks what might be one long specification into structured parts and exposes them through a workflow. The same idea of a saved source of definition still applies.

From the data-team perspective, definitions of metrics and dimensions change, as do source data and context. A system must recognize those changes and help maintain alignment rather than require the user to restate the entire problem whenever an assumption shifts.

The underlying saved material plays a role similar to a specification: it records the definition of what the system is building. The difference is that the demonstration surfaces this definition as connected workflow steps rather than relying only on a single long document.

The speakers suggest deliberately changing a calculation to see whether tests catch it. In their example, the system should prevent an analysis from reaching a conclusion when a change breaks the checks designed for that step.

Evidence means being able to show where a number came from and why a decision followed. Not every input has equal standing: a fact from a financial document, an interpretation of a chat and an assumption inferred by the model should not all receive the same label.

Even a seemingly firm guest count can change if someone invites more people. If that assumption is wrong and its origin is invisible, the whole budget can be wrong without anyone knowing which input to correct. The model needs help distinguishing an estimate from a hard fact.

The proposed labels reflect the source: unstructured words in a chat are an interpretation, information drawn from the model’s memory is an assumption, and a submitted bank statement is evidence of an actual transaction. Galletta compares this to carefully labeling a dataset before using it in an analysis.

The evidence trail must also cover how a calculation was made. Galletta recalls a shared master spreadsheet whose acceptable ranges changed. A colleague used the file without knowing it had changed and produced wrong results despite supplying the same inputs. Code changes can create the same blind spot.

In the demo, clicking an underlined figure highlights its source and the steps that depend on it. A correction in the chat can be traced forward through the calculation as well as backward to the person who supplied it. Other financial systems may trace data all the way to a connector or data provider.

Galletta invites users to introduce a correction and then click the changed value. The important behavior is that they can trace the changed input and understand why it matters to downstream calculations.

An audience member says they regularly want to know where a number in an agent-generated presentation came from. Galletta recalls a slide-building agent that took an illustrative example from a revision request and repeated it throughout a presentation; senior leaders then asked where the number came from.

Accountability builds on evidence. The speakers argue that people remain responsible for the results of agents, however many agents they use. Being able to inspect the process helps a person answer for a decision rather than saying that a model supplied it.

A person who delivers an answer carries the real-world consequences of that answer, whereas an agent does not. The speakers therefore frame inspection and review mechanisms as ways to support the human who remains accountable.

That does not mean approving every trivial change. A participant describes reviewing a set of tasks, letting the agent work, then reviewing the result. Galletta says deliberate gates should focus on important judgment calls and ambiguities; constant low-value interruptions lead to unnecessary work.

A useful review gate should have high signal: it should stop for a choice that changes the outcome, rather than require approval before every small action. The audience’s example of reviewing a task plan and then the finished work illustrates the distinction.

The right gates depend on the use case. An agent might prepare three financial scenarios, but the user should compare them before making a decision. For code, tests may provide useful evidence without asking a person to approve every calculation.

The example does not move money from a bank account; the person reviews the analysis and decides how much to save. That final decision is a gate, even though the presenters acknowledge that their demonstration could include more accountability mechanisms.

In the wedding example, a contribution arriving on the same day as the third payment creates a meaningful timing question. The interface records whether a decision was assumed by the agent or revised by the user, and shows how branches of discussion rejoin the larger plan.

A user can later correct the guest count and see the effect on the plan. Galletta wants course correction without losing the whole analysis: in an ordinary chat, an incidental sentence can redirect the work, and removing just that sentence while preserving everything else is difficult.

If the user changes guest count to at least 150, the system can reconsider the plan and suggest how the input affects later steps. Galletta emphasizes designing this feedback deliberately rather than assuming a correction will propagate in the intended way.

The demo also permits a side conversation as a branch. The speakers want users to decide whether an aside should affect the main plan, instead of allowing every question to become permanent context. The feedback mechanism should match the way people actually work.

Verification adds another set of eyes without transferring responsibility. Galletta notes that review can itself become a burden: a colleague may hand over something that looks plausible, leaving the reviewer responsible for finding every mistake. An additional perspective is information for the decision maker, not an escape from accountability.

Experienced finance professionals often check a few revealing cells rather than redo an entire spreadsheet. A surprisingly large marketing total, for example, can trigger a closer look. The point is to obtain another reference for what a plausible answer should look like.

Asked about known correct examples, Galletta says they establish a useful baseline but may reflect the same selection biases as the original work. Looking at a neighboring domain or an independent source can expose a mistake that all the chosen examples missed.

He recalls producing a business-intelligence dashboard whose query and result looked reasonable to him. A stakeholder from another team immediately recognized the number as impossible because it conflicted with information that team already knew. Their different experience supplied the missing check.

The speakers describe this kind of quick judgment as drawing on small slices of domain experience. A model’s general patterns may miss a five-percent difference that matters greatly to a particular organization. The system needs a feedback loop for users to say when a plausible-looking output does not fit their domain.

An answer can look approximately right yet fail an organization’s specific needs. The reviewer’s domain knowledge supplies a different point of reference and can send the discussion back toward the shared understanding established at the start.

In the demo, a separate agent reviews a plan and challenges an assumption. The user can merge a useful suggestion back into the main plan or dismiss it. The speakers say a second model acting as judge is of limited value if its feedback cannot change the actual financial decision.

The five principles are shared understanding, consistency, evidence, accountability and verification. The presenters suggest using them together as a framework for financial systems in which users need to trust both the analysis and the process behind it.

An audience member asks how many dedicated systems a team should build and how specific they should be. Caso says there is no fixed schedule or universal answer: consider how often the generic approach fails, how much reproducibility matters, how many people will use it and how critical the decision is.

For a low-stakes task, a person may be able to review and steer an existing agent through a few extra turns. A tool supporting decisions by 50 credit analysts has a different need for consistency. The team should weigh that need against the effort of building and maintaining another system.

Galletta notes that the same degree of evidence and review may not be necessary for every creative task. The workshop’s recipe is shaped by the higher stakes of financial work, not by a claim that every agent needs identical controls.

Galletta compares excessive tooling to sharpening an axe instead of using it. Start by adding instructions or tools where needed; if the same awkward sequence of copying, restarting chats and correcting results recurs, that repetition may justify designing a dedicated workflow.

Asked whether specialized agents helped plan his wedding, Galletta says web research was useful for comparing photographers and venues. Financial planning was less forgiving: he recalls repeating essentially the same budgeting conversation three times while driving because something kept going wrong.

A participant asks how to manage leaders’ expectations that AI-assisted analysis must be perfectly accurate. Caso returns to outcomes: agree on what success means, such as fewer back-and-forth exchanges over a dashboard or fewer tickets about suspect numbers, then measure whether the tool helps achieve it.

On the boundary between an agent skill and a separate tool, Caso says instructions can work well but still leave edge cases and conflicting user-level instructions. As a workflow reaches more users or becomes more consequential, deterministic backend code can enforce behavior that a prompt merely requests.

Caso gives an example of a shared agent extension that tries to handle many unsupported user requests with additional instructions. As distribution expands, such instructions can conflict with other context; a backend boundary may make the supported behavior more predictable.

Finance combines reliable arithmetic with interpretation. A payment may be recorded in a different month, and understanding the implications requires judgment; the calculation itself still needs to run reliably. Galletta says the system should be intentionally designed for both kinds of work.

Models may improve, but the speakers say trust must still be earned through the surrounding process. Some users need to inspect the code, others need traceable evidence or independent challenges. The demonstration combines these mechanisms because no single display will establish confidence for everyone.