The board wants to see the bottom line of the RFP. Show the receipt.
Financial services boards want to know what they get from the spend on AI in LangChain’s July post titled proving the ROI of agentic AI in financial services. In the case of agentic RFP responses, AML investigations, portfolio management workflows, and financial services compliance reviews, the work crosses documents, systems, approvals, policies, and people that are typically involved in such financial work.
One dashboard showing total tokens / uptime will not cut it.
Financial services already is stressful enough without questioning the value of AI. The data point: 68% of the financial-services respondents who used generative AI in a recent Snowflake survey from Snowflake were able to quantify a positive ROI from the technology, with 30% currently using agentic AI in live workflows. Moody's says Research Assistant users consume 60% more research and cut task completion time by 30%. As a result, financial services moves out of novelty category for agentic AI and goes straight to hard work of proving the value.
The hard part is proof.
Agentic AI ROI starts with work receipts
Agentic AI ROI quickly goes from clear to fuzzy as soon as teams start to measure the “wrong” unit. Spend is not value. Prompts are not work. A simple monthly usage graph proves activity. That’s to show a better board packet. (a pretty low bar).
The unit is the completed work item.
An RFP answer section is a work item. An AML alert disposition is a work item. A KYC exception package is a work item. A risk memo refresh is a work item with input data, a responsible agent, tool calls, model cost, human approvals, policy checks, writes to downstream objects, and so on, until a set of reviews culminates in an outcome for the item, the end result of the agent’s work. The end result has a set of receipts for the finance department (evals, traces, etc.). Each run of a work item through an agent’s tools generates one or more such end result receipts.
That is the receipt.
That connects to prior work on enterprise AI agents as runtime products. Finance needs the same owned boundary if it wants per-work-item proof.
LangChain’s finance piece names RFP processing and AML compliance monitoring as agentic use cases, then connects ROI to observability, governance, and economic measurement in the same stack. The operational discipline is making every meaningful run leave a receipt as it executes.
ROI proof is assembled while the agent runs, not after the fact in a spreadsheet.
The runtime is where the receipt gets written
Whatever live agents execute is already in full view of the runtime, so hiding all that inside engineering tools is the self-inflicted wound here.
An agent runtime handling real work knows the assistant, thread, run, input, tools, retries, costs, interrupts, stream events, and final state. LangSmith Deployment describes its Agent Server execution model around assistants, threads, and runs, with durable execution, real-time streaming, and horizontal scaling for agent workloads. The background-run API accepts metadata, context, webhooks, feedback keys, stream modes, and durability settings. That is enough surface area to attach business context before the work disappears into a trace search screen.
The receipt for a run should be created before the moment the run is created (i.e. before the first tool is called in that run’s execution).
Assign a task type to the run, attach the business object, cost center, policy, expected output contract, reviewer queue, and downstream system that the side effects will be written to. The runtime can then update the receipt as work is completed.
For AI agents in finance, the receipt becomes the control surface.
A receipt finance, risk, and engineering can read
A runtime receipt is boring on purpose.
That all gets recorded, and it is boring by design. There’s run ID and thread ID and task, data accessed, tool calls, model+token cost to run, latency to run, retries, approvals (and all the side-effect receipts), an evaluator score and a reviewer’s result, and business outcomes. For RFP sections we get to know if we’re accepting them with or without SME material re-write. For AML alerts they get escalated or closed or sent back for human review. For research memos they can be cited, rejected or re-written.
A receipt turns a trace into evidence finance, risk, and engineering can all read.
For Engineering it is debug evidence, for Risk it is authority and data lineage, for Finance it is cost per accepted work item, and for Product it is adoption tied to outcome. This receipt answers different questions for the teams and does not force each to make up its own “truth” for how well things are working.
Honeycomb has made similar observations in the past about Observability. As they put it in connect technical signals to business outcomes, because uptime, MTTR, and engineering productivity do not automatically yield a measure of what the business gets from the system. AI increases this already-substantial barrier, in that a healthy model, up service, etc. is not at all sufficient to guarantee that the agent using it will spend its time and money productively, or even at all.
AI agent cost is a runtime signal, and its useful question is whether the agent’s work item can be replayed, judged, explained, and tied to business results.
Aggregate dashboards are too late
They show spend by team, average latency, total runs, error rates, top agents, cost by model, and adoption trends. These are good to keep and to be proud of, but they are late by design, i.e. they cannot be used to prove the value of a single compliance-sensitive action.
Averages hide important details, especially when it comes to individual expensive runs and costly rework caused by high adoption. The expensive run might be valuable to investigate deeply. The cheap run might be garbage. The agent with high adoption might cause rework, whereas the agent with low adoption is the one doing the riskiest work for the firm.
The receipt is what lets the rollup make sense.
OpenTelemetry's graduation post is worth reading. Even though it’s talk of the future of telemetry and how to abstract it away from current vendor lock-in, it’s anchored firmly in current reality. OpenTelemetry is a graduated CNCF project and the maintainers point out that agent execution (running processes or containers) within agentic workflows (running workflows within workflow managers), and GenAI semantic conventions (as used by current AI and expected to be used in the future) are future workloads that OTel will be able to handle. Therefore, the receipt evidence that a run produced needs to be able to travel between all of the queues, databases, identity providers, SaaS APIs, and code review work-flows that the agent is executing in. The receipt cannot be locked in the private vocabulary of any single vendor.
Agent work volume turns measurement into architecture
Delegating work to agents as a regular part of one’s operating work is becoming operating volume, not a lab artifact. The recent Codex usage paper reported that active users grew more than fivefold in the first half of 2026. In addition, there are now more than 10% of users managing three or more agents in current active work at any time, and 26.6% of users using skills in their use of Codex for coding and other knowledge work.
Parallel execution breaks casual measurement.
The runtime needs to know what work item is currently active, which is pending approval, which handled customer data, which triggered follow-up jobs, which exceeded cost bounds, and which have side effects. A recent infinite-agent-loop paper found 68 confirmed failures across 47 projects. All of these failures can cause cost exhaustion, context growth, model denial of service, or repeated external side effects, and are caused by the iterations on the agent and its authority outpacing the system’s ability to observe its runtime behavior.
The Agent libOS paper gets the systems shape right: long-running agents require process identity, parent-child lineage, lifecycle state, explicit capabilities, human queues, checkpoints, events, and audit records. In financial-services language that becomes identity, authority, state, approval, evidence, and accountability.
Just as with money movement, spending authority moves into the runtime and therefore policy, approvals, receipts, and revocation need to be accounted for before the wallet signs the spending of tokens. The runtime should not simply spend tokens and hope finance reconstructs the value later.
Repeated work should become measured paths
The first version of the finance agent is an exploratory one. It will try out various tools, ask for more information here and there, fail evals (which it can recover from), request approval, and in the process learn which path is best.
Then the repeated paths should harden.
A weekly RFP process is not something that should stay in a loose agent loop forever. It’s a process of requirements extraction, approved-content retrieval, answers, citations, SME review, and packaging. And those should be a well defined process with well defined gates. (Even if there are also places for ambiguity).
That is the point behind agentic workflows getting less agentic. Repeated behavior of an agentic workflow should transform into an observable, doable, legible execution path (and remain agentic as soon as reality changes again). Likewise the ROI of a finance agent does not only grow as it becomes more agentic, it also grows as the agent’s work is first discovered, recorded, measured and then hardened.
And, side-effect layer. As we’ve written about before, side-effect receipts are critical to enabling features like retry, compensation, and ownership tracking when various tools are orchestrating work that causes side effects by running to update live systems. For a finance agent, this would include updating CRM records, requesting documents, opening up new case work, generating client-facing drafts, and opening up new compliance work, etc., all of which would need to be issued with an operation key and receive a corresponding receipt.
A trace in the workflow captures all the activity that occurred within the agent as it executed the workflow. A side-effect receipt, by contrast, captures the changes that the agent caused outside of the workflow, i.e., the actual side-effects.
Both belong in the ledger.
Own the ledger before the board asks
A distributed systems lecture is not what the board wants. Fair enough. They just want to know if their money has been converted into real work value.
To answer that question honestly requires a tremendous amount of engineering discipline to create runtime receipts that are dull enough to be understood by people in finance, risk, and engineering, and to attach all relevant metadata before work begins, to track all changes to authority throughout the process, to ensure that all side effects are recorded as first class facts, to tie the scores from evaluators and the results of human review to the work item in question, and to do rollups from the receipt as opposed to from the vibes that were brought to the work.
This also changes how one evaluates vendors for finance agent platforms. A platform without per-work receipts for finance, risk, and engineering to share is magic; a runtime with receipts is evidence, easier to defend when the model changes, when a workflow drifts, when a regulator asks for lineage, or when the CFO asks why the AI budget went up again.
Show the receipt.
Top comments (0)