Panel Session 4: Agentic AI in Finance & Legal

Panel: Agentic AI in Finance & Legal

Nikhil Chandhok、Faraz Shafiq(主持:Matt Carbonara) — Nikhil Chandhok — Chief Product & Technology Officer, Circle / Faraz Shafiq — Head of AI, Wells Fargo(主持:Matt Carbonara — Investor, Mayfield)

Sunday, August 2 · Plenary Stage · 02:32:19–02:59:07 · afternoon stream

Finance and legal aren't just "harder agent problems" — they have a fundamentally different verification cost structure. Easily verified tasks (coding) automated first; a credit decision may not be verifiable for five years. That verification axis determines what agents take over first and what they take over last.

TL;DR

  • Verifier's Law framed the whole session (Shafiq): tasks that are easy to verify are ripe for agentic processes. Sudoku is hard to solve and trivial to check; coding has QA and test suites. Hard-to-verify work has a much longer lead time — self-driving is hard to fully verify, and a credit or loan decision made today may only be verified five years later when the borrower defaults.
  • Finance and legal already run on agents (Chandhok), because everyone uses coding agents — and coding agents have the wonderful property of verifiability and testability. The same techniques apply to finance and legal, but the cost of failure is far higher: SOX compliance, getting earnings ready ("I know this because we have earnings next week"). Auditability of the agent's decisions, the data sources it can reach, and the verifiability of its output all move to a very high bar. "We don't want to get hauled in by regulators just because our agent made a mistake. They're going to hold us responsible, not the agent."
  • Home mortgage is a ~1,100-step process (Shafiq), so it will never be one agent and never be entirely homegrown. The hard part isn't the protocol — A2A is good and protocols usually aren't the issue — it's which data to grab for which task, and how a ServiceNow agent, a Salesforce agent, and a homegrown agent share the right context.
  • Eval heterogeneity runs deeper than people say (Chandhok): a morning speaker noted every organization is idiosyncratic about evals; his correction is that every team within an organization is idiosyncratic. Circle locks down the model, the harness, and every variable outside the input, and adds shadowing — the agent works the same inbound alongside a compliance analyst, and the comparison feeds a reinforcement learning loop.
  • The most expensive enterprise mistake is asking the wrong question (Shafiq). Leaders say "we have this large process, can you use AI to make it simpler, faster, more automated?" — typically the wrong approach. The right question is what the art of the possible looks like with AI, whether the whole experience can be reimagined, and then how to work backwards. His diagnostic: developers and PMs each claim ~30% more efficiency, and that often fails to translate into workflow-level gains.
  • "There are not going to be any individual contributors" (Shafiq). Of Wells Fargo's 200,000 employees, most are ICs — and ICs become managers of agents. ICs aren't used to delegating; they own work end to end. Now you still own it but you're delegating it. They're working with HR on rolling out "everyone is a manager."
  • The moat is in the hard physics (Chandhok). Software-only businesses will be hard to defend — broad consensus, in his view. Circle's bet is that network businesses beat software businesses: USDC as a stablecoin network, the Circle Payments Network on top, and Arc, a new blockchain that needs validators and aligned participants. Plus the literal hard parts: real computational problems in Arc, and being chartered by the OCC and subject to exams to issue a stablecoin. Software is the accelerant, not the moat.

Key Points

Moderator framing: where Mayfield sits (~02:32)

Matt Carbonara opened with positioning: Mayfield is a 57-year-old venture fund currently investing out of funds 19 and 20, based in the Bay Area, having backed over 700 companies — 125 of which went public and 250 of which were acquired. He emphasized a people-first approach: entrepreneurs build companies, company-building is a marathon not a sprint, and they don't panic through the ups and downs. They invest from seed and inception through Series B, and up and down the stack — semis, optics, switching, and models; infrastructure software; cyber, cloud, and dev tools; all the way to the application layer.

His question for the session: how do you use the agents everyone had been discussing in high-risk domains like legal and finance?

Theme 1: What's different about high-risk agents (~02:32–02:36)

Chandhok started from the observation that every finance and legal organization he knows is already using agents — because they're using coding agents. And coding agents have a wonderful property:

Verifiability and testability. You can go in, read the code, decide if it's too verbose or not verbose enough, whether it has design docs — and you can run a test suite against it and make sure the agent is doing what it's supposed to.

You can do the same things in finance and legal, but the cost of failure is much higher. His own example: SOX compliance, or an agent whose job is getting earnings ready ("and I know this because we have earnings next week"). You cannot take a mistake, and the scrutiny on that agent will be tremendous. Three things move to a very high bar simultaneously:

  1. the auditability of the agent's decision-making
  2. the data sources the agent can access
  3. the verifiability of the output

His conclusion: these are among the last flows to get automated, because so much of a company's existence depends on its ability to get finances right and to keep its legal surface area appropriate. The same holds in other functions like compliance: "We don't want to get hauled in by regulators just because our agent made a mistake. They're going to hold us responsible, not the agent."

Shafiq added the framework that anchored the session — Verifier's Law:

Tasks that are easy to verify are going to be ripe for agentic processes. Think of Sudoku — the puzzle is hard to do but very easy to verify.

Coding qualifies (QA and tests give you fast verification). Things that are hard to verify are harder to solve and have a longer lead time. Self-driving is the classic case: it's very hard to fully verify that the vehicle did the right thing at the right moment. Banking is more extreme still:

Someone submits a credit card or loan application, and in some cases we don't have a lot of data. If we make an incorrect decision based on the information we have and the person defaults, that may be five years from the decision. The decision to give them credit was today; the verification is five years down the road. That becomes very hard.

So their filter is: which tasks are genuinely ripe for agents that will surpass the human probability of being correct? Those are where they start.

Theme 2: Build vs. buy, and how agents connect (~02:36–02:38)

Asked whether the same judgment applies to in-house and third-party agents, Shafiq said hybrid. The models and the intelligence are largely the same for everyone, but Wells Fargo has IP and data others don't, which gives homegrown agents an edge for specific things. At the same time, off-the-shelf agents are becoming so powerful out of the box that it doesn't make sense not to use them — and the real variable is economics: once costs come down, they'll be pervasive.

The bigger question, in his view, is how agents connect to each other:

The home mortgage process I keep coming back to is a very large, very complex, roughly 1,100-step process in the bank. It will not be one agent, and it's not going to be a collection of homegrown agents either — it'll be a combination of many things. And it can't be that this agent does its job really well while the other one doesn't, because they need to talk and connect to each other.

Especially for long-running systems: "You give a prompt, you get a response back — that's easy, you'll be right. But when you want something done over multiple hours or days or weeks, the context is where it starts getting a little shady."

Theme 3: Two gaps for entrepreneurs (~02:38–02:39)

Asked whether the long, hard-to-verify work is an entrepreneurial opening, Shafiq named two:

  1. The agentic harness. "The concept sounds so simple — a harness that holds everything together and sits on top of the agent — but it is incredibly hard to do, especially for long-running processes." It's something they're actively looking at.
  2. Cross-agent context exchange. He stressed these are industry problems, not Wells Fargo problems. Protocols aren't the bottleneck: "A2A is a great one, and a lot of organizations are building on standard SDKs — that typically is not the issue." The issue is:

Optimizing which data to grab for what task. How would a ServiceNow agent collaborate with a Salesforce agent, collaborate with a homegrown agent, and share the right context and the right information? Very difficult to do. That is a big, big opportunity.

Theme 4: Measuring reliability, and when an agent ships (~02:39–02:42)

Chandhok said it varies by use case. Citing a talk that morning about how hard evals are and how idiosyncratic each organization is about them, he sharpened the granularity:

I would say within organizations, each team is idiosyncratic about evals. What to measure, how to measure, what "good" means — it needs to be defined process by process by process.

Circle is standing up frameworks for scalable evals. He also warned that evals break for all kinds of reasons: model drift, data issues, all manner of things that change how an agent performs. So where they have implemented, they lock down the model, the harness, and every variable going in besides the input itself.

They also use what he calls shadowing:

The agent sits with the human. A compliance analyst gets an inbound, they're making a decision and looking at the case; we observe what the human does and what the agent does, then we evaluate that and run it in a reinforcement learning loop.

On KPIs he was candid that things are fuzzy. They're trying to work out how much token spend equates to what kind of automation, but they are deliberately not optimizing for token savings right now — letting people use the tokens and seeing how much productivity comes out. Productivity shows up in three shapes: more output per human, occasionally revenue (still small), or an obvious cost saving / substituting labor that was doing X to do Y. "It's all of the above. But there's no rule of thumb saying this is how you do KPIs or evals."

Theme 5: Weighting engineering effort, and the question enterprises get wrong (~02:42–02:46)

Asked how to weight model vs. harness vs. workflow integration vs. context and memory, Shafiq said this is where he spends much of his time. He contrasted the traditional product development lifecycle: an idea, iterated back and forth in a Word doc or PowerPoint, then engineering builds a Figma or prototype, then the development lifecycle with architectural patterns, vulnerability and risk assessment. "Very archaic, very human-driven, very sequential."

In the agentic world he sees two paths: the technical choices (memory, infrastructure, own cloud or public cloud) and, more decisively, the business choices. Here he flagged another startup signal: only a handful of companies are building frontier intelligence, but a slew of companies will build the engine that makes it work inside enterprises, because enterprises need security, governance, and compliance.

Then his sharpest critique:

Generally the leaders would say, okay, we have this large process — can you use AI and make it simpler, faster, better, more automated? And that is typically the wrong approach. The approach would be: what is the art of the possible using AI, and can we reimagine this whole experience, and then find a way to go from your current process to that.

He calls this the gap in the enterprise, and paired it with an observation he and Chandhok had discussed in the green room: ask developers or product managers individually and everyone claims roughly 30% more efficiency — writing code faster than ever before. But in many cases that doesn't translate into workflows.

The gap is process engineering: understanding the domain, the specific data, the use cases, and then working backwards into the right architecture — because the architecture is starting to become the easier factor in all of this.

Theme 6: Org design and the human-to-agent ratio (~02:46–02:50)

Chandhok said Circle is rolling out the ability for employees to self-publish agents, along with an agent gateway: you can see what all the agents are, find them in Slack, and talk to them.

But he refused the framing:

I don't foresee a future in which the point person on a project is not a human. A human can go invoke any of the many agents inside this company, query our agent gateway — what agents are available, what finance agent do we have, what marketing agent do we have — and compose them into some kind of solution. I don't think about it as an org design question, because I don't tell the people working for me how many Google Docs they can open. They are creating an outcome for us.

His focus is therefore infrastructural: being able to self-publish, having the data access to self-publish, having the right ACLs to self-publish, and getting agent-to-agent communication figured out.

On whether organizations change: he thinks they'll be more productive (everyone's experience), and may reorganize because the lines between function A and function B are blurrier. The real questions are about team composition: do product managers do more product marketing, does product marketing do more brand, does BD do more product? "Even who shows up on sales calls — maybe our agent shows up and takes notes. There are all kinds of efficiencies like this being figured out. But in terms of org design, old-school McKinsey stuff, we're not thinking about it."

Shafiq answered the same question from the other end — the biggest non-technical barrier to adopting agents at scale:

There are not going to be any individual contributors. Out of our bank of 200,000 employees, largely they're individual contributors. What does that mean? It means the ICs now will be managers of agents.

The friction is that ICs aren't used to delegating — they're used to owning work end to end and being fully responsible. Now you get a body of work, you use ChatGPT or Claude or any model, and you still own the work but you're delegating it — and that will be the dominant way of working going forward.

So one thing they're doing now is emphasizing that everyone is going to be a manager:

Just like you give feedback to humans, you need mechanisms to give feedback to your agents, to grow your agents and get more out of them. That's very new, because the playbooks really don't exist. You're not used to a world of no ICs and all managers.

They're working with their HR team on how to roll that out.

Theme 7: Where's the moat once intelligence is democratized (~02:50–02:56)

Chandhok started by noting Circle is much smaller than Wells Fargo — at least two orders of magnitude smaller in engineering. Then two layers of answer.

Layer one is speed, via a jetpack metaphor:

There's always a race on — you're in a race with somebody, and now suddenly you can wear a jetpack. If you can master the jetpack you take a lead over the competition. They'll catch up; they'll wear their jetpack and get there as well. So first, I want to make sure I put my jetpack on and get my organization to put on the jetpack before everybody else does.

Layer two is the shape of the business. He agrees a lot gets commoditized, and that software-only businesses will be hard to defend — "I think this is broad consensus." But Circle has harder things:

We are a company of networks. USDC is our core product, and we think about it as a stablecoin network. We have a payments network on top of that, the Circle Payments Network. And we're building a new blockchain called Arc, which is also a network, because you need validators and participants aligning incentives to participate.

His claim: network businesses are superior to software businesses, and software is an enabler of these network businesses — the question becomes how to use software to build software-enabled networks. On top of that sits what he calls the hard physics of the business: real computational difficulty in Arc, and the complexity of issuing a stablecoin at all — you are chartered by the OCC and you have to submit to the exams. The strategy is to do the hard physics extremely well, move into adjacencies that are also hard physics, and use software as the accelerant on top.

Shafiq made the non-technical bottleneck explicit:

There are going to be amazing changes in banking, and many of those are not technological challenges. 24/7 trading — why does trading end at 4:00 PM Eastern? The answer is largely not technological. It's not a big issue to enable that technologically. It's that regulators want the movement of money regulated, protecting consumers.

Instant global money is the same: "Yes, I can make the money available — but if the other bank takes two days to close the book, who's paying for that delta, and what happens when the money doesn't reach?" The regulatory side has to catch up, and new use cases will arrive as better regulation does.

He then echoed Chandhok with a clarification he clearly felt was needed:

The software side of it is going to make us do the hardware side of the business really well. And when I say hardware, I don't mean GPUs. I know it's an agentic AI conference, but we still have 4,000 branches. We still believe there's value in human connection — someone coming in to talk to a bank advisor in Spanish because they only speak Spanish, and building a plan for their financial education.

Those won't go away; how they're delivered and consumed will change dramatically. His model-layer prediction: today is dominated by LLMs and the conversation is token cost; eventually it will be small language models and fine-tuned models, because that will become as easy as a click of a button — and the center of gravity moves to vertical, specialized AI, from which a lot of new use cases will come.

Closing: what will be automatable in five years that you can't imagine today (~02:56–02:59)

Shafiq named underwriting:

Underwriting is the core for any bank — income verification, home loan verification — and it's a very archaic process. People bring in all sorts of documentation; you may send a utility bill that you photographed at a wrong angle with light hitting it, so someone has to send it back. A very complex multimodal challenge.

He expects it to become table stakes over the next couple of years; what holds it back today is compute and economics. He restated the model-layer trajectory (LLMs → small language models and fine-tuned models) and added "and then quantum, once that compute is available."

Chandhok took a different turn:

I'm AGI-pilled, so I believe we will be looking at AGI through our bedroom windows. And at that point, who am I to say what is not solvable?

But his real answer was the panel's best closing:

It may be a data center full of geniuses, but humans are Byzantine. They are idiosyncratic, they are very hard to coordinate. So it may be very lonely for those data centers full of geniuses while the rest of us try to coordinate and figure this out. We have really good models, but I am surprised by how much effort it takes just to convince people to do things even when those things are objectively good for them. Does anybody have a parent you've tried to get to take their medicine? Or children, for that matter. It's objectively good for them. They will refuse.

Human society is not ready to just take it from these data centers full of geniuses. That is my conclusion. I want those data centers around and I'm very glad they are here — but we have a lot of problems to solve between now and this future that we're imagining.

Quotes

"Tasks that are easy to verify are going to be ripe for agentic processes. ... Same thing in banking: the decision to give them credit was today; the verification is five years down the road." (~02:35, Faraz Shafiq)

"We don't want to get hauled in by regulators just because our agent made a mistake. They're going to hold us responsible, not the agent." (~02:34, Nikhil Chandhok)

"I would say within organizations, each team is idiosyncratic about evals." (~02:40, Nikhil Chandhok)

"Can you use AI and make it simpler, faster, better, more automated? And that is typically the wrong approach." (~02:44, Faraz Shafiq)

"There are not going to be any individual contributors. ... The ICs now will be managers of agents." (~02:49, Faraz Shafiq)

"It may be a data center full of geniuses, but humans are Byzantine. ... It may be very lonely for those data centers full of geniuses while the rest of us try to coordinate." (~02:58, Nikhil Chandhok)

提到的專案與資源 / Projects & Resources

名稱 Name 說明 Description 備註 Notes
Verifier's Law 「容易驗證的任務適合 agentic 流程」的原則,Shafiq 用它排自動化順序 The principle that easily verified tasks are ripe for agentic processes; Shafiq uses it to order automation 講者未指名出處 / no source cited by the speaker
A2A (Agent2Agent) 講者稱為「很棒的協定」;他認為協定不是瓶頸 Called "a great one" by Shafiq; protocols aren't the bottleneck in his view
Circle Payments Network 建在 USDC 穩定幣網路之上的支付網路 Payments network layered on the USDC stablecoin network
Arc Circle 正在建的區塊鏈,需 validator 與參與者對齊誘因 The blockchain Circle is building; requires validators and aligned participants Chandhok 稱其含「硬運算」問題
Agent gateway (Circle) 讓員工自行發布 agent、在 Slack 中查找與呼叫 Lets employees self-publish agents and find/invoke them in Slack 導入中 / being rolled out
Shadowing agent 與人同時處理同一筆案件,比對後跑 RL 迴圈 Agent and human work the same case; the comparison feeds an RL loop Circle 的 eval 做法
房貸流程(~1,100 步) Shafiq 全場的主要例子 Shafiq's running example of a ~1,100-step process faraz-shafiq--reimagining-banking-in-the-ai-era.md
OCC 美國貨幣監理署;發行穩定幣須受其特許與檢查 Office of the Comptroller of the Currency; stablecoin issuance requires its charter and exams

逐字稿勘誤 / Transcript Corrections

字幕原文 Heard as 應為 Should be
Nquille / Nikil / Nichol / Nikl Nikhil (Chandhok)
far / Faras Faraz (Shafiq)
verifiers law Verifier's Law
sedukco / sudukco Sudoku
socks compliance SOX compliance
Mckenzie McKinsey
the OC the OCC
Service Now ServiceNow
generic agents(主持人提問) agentic agents
AGI build AGI-pilled

待確認 / To Verify

  • Verifier's Law 講者未指明出處;若要引用需回查該詞的原始提出者與定義。/ Shafiq cited "Verifier's Law" without attribution; trace the original formulation before citing.
  • Chandhok 引用「早上一場關於 eval 的演講」,未指名講者或場次。/ Chandhok referenced a morning talk on evals without naming the speaker or session.
  • 「房貸約 1,100 步」「Wells Fargo 20 萬名員工」「4,000 家分行」「Mayfield 700+ 投資 / 125 IPO / 250 併購」皆為口述數字,未附出處。/ The ~1,100 steps, 200,000 employees, 4,000 branches, and Mayfield's 700+/125/250 figures are all as spoken, with no sources given.
  • 「開發者與 PM 個別聲稱效率提升約 30%」為 Shafiq 的觀察,非引用研究。/ The "~30% more efficient" figure is Shafiq's observation, not a cited study.
  • Chandhok 說 Wells Fargo 的工程組織「至少大兩個數量級」是現場口語估計。/ Chandhok's "two orders of magnitude" comparison was an offhand estimate.

Markdown source on GitHub ↗