# Trusting Agents in Policy-Driven Workflows — Evan Kormos — session 2026-10-14T13:36:00.000Z → 2026-10-14T13:54:00.000Z _33 transcript lines · 54 slides · source: full recording_ ## Transcript **[00:00:01 · 0]** We expect work to flow in a specific and gated direction. So I believe it makes... Agents make it worth revisiting what we can do in parallel. Previously, some work used to cost too much or be too complex to coordinate in this way. But now we can run independent reviews alongside each other, bring your results together, but keep the required checks in place. **[00:00:33 · 0]** So this is a Directed Acyclic Graph, or a DAG. It's a way to represent this workflow or process, the steps, the dependencies, for a flow that moves forward without looping back on itself. Apache Airflow, if you're familiar, is an example of open source software that represents workflows, their dependencies as DAGs in Python code. So this Python code, these DAGs can be used to define and manage a number of policy driven processes, like, for example, commercial lending. We could also use a DAG to represent the workflow to list a token on the exchange in a specific region, if you're into that. **[00:01:31 · 0]** Or we could use a DAG to represent a regulated flow of delivering software, which is a hot topic. And one we'll spend a little bit of time on, I think, that we've seen a lot of adoption within agents within software delivery. And ultimately, we're looking to leverage that same efficiency and scale in other areas of the business and close that... The the adoption gap. So let's stick with the software delivery example for a little bit. **[00:02:05 · 0]** What happens inside one of these nodes of the process? And I'll give you a hint. It's a loop. Oversimplified, but we have a basic version of what's happening within the... Let's say this is the code review process, right? **[00:02:28 · 0]** So we're gonna essentially do a number of steps and essentially once We realize the work we recognize that the work is good enough we're gonna allow it to pass on to the next step. And that's essentially the function of the code review node. The work doesn't always, end up okay. So sometimes we have to take the feedback from the code review and iterate on it until the work is good enough to pass. So this is a representation of a directed cyclic graph, or DCG. **[00:03:10 · 0]** So as far as open source software, something like lang chain, lang graph would be what I would say is helpful to manage the state of DCGs. And this is an oversimplification. These graphs can be very complex. So zooming back out, the inner flow of the node, we have people and agents working together. On the outer flow, we have a policy boundary. **[00:03:44 · 0]** But not everything goes to plan. So we have to handle exception flows. We don't want the work to get stuck, and we don't want to design for every edge case either. The exception flows will monitor and see what happens. If you're shipping code that gets canceled or doesn't meet security standards, that's something you should want to know about. **[00:04:11 · 0]** Volume shifts across the flow once we start to add agents into the mix. And we've seen this with software delivery, and we'll see it in other processes as we bring agents into those processes as well, where now all of a sudden, if you're reviewing code faster, you need to design it quicker or you need to do the security scan that's faster. So we see the volume shift across the flow. And this is where it's really important that we have visibility into the process overall from a a metric standpoint. Because as we start to supercharge and and parallelize and add more efficiency to the process, we start to develop more and more bottlenecks. **[00:04:51 · 0]** And so the operational visibility of the process is extremely important, much more important than the authoring and the building of your workflow tool. So we want to visualize the process. So we want to add parallel capacity by still keeping the controls. And so this is where we'll add more additional capacity. Okay. **[00:05:20 · 0]** So we're doing some work. We're checking it. We're using the feedback again to refine it until the work is good enough to move on. But why is that hard? That seems like a pretty easy thing to do. **[00:05:31 · 0]** But as I mentioned before, these graphs get actually pretty complex. And we'll dive a little bit more into why this is difficult. And if you're familiar, one challenge with AI engineering is the variability of inputs and outputs. And I believe that higher quality inputs will result in better outputs at a lower compute cost. But what are quality inputs? **[00:06:06 · 0]** So we'll generally speak to it as context model, maybe. And then we can nitpick that. But this isn't our area of focus today. We're going to focus more on outputs. But we can't really talk about quality of outputs without talking about the quality of inputs. **[00:06:29 · 0]** So ideally, we've established a trusted context for our agent. And there's some references on that. But one thing we can do in this model is inject the DAG state into our agent and let it know kind of where it fits into the bigger picture. Okay. So now we've added even long time horizon goals, and that emphasizes the need to optimize the cost and efficiency of this loop. **[00:07:07 · 0]** So the check is where we decide whether the work is good enough to move forward. We need to define what good looks like. That's the hard part. And we need to have a reliable way to evaluate it. Otherwise, more passes don't necessarily, mean better results. **[00:07:24 · 0]** The loop is really only as trustworthy as the check. So if we wanna talk about quality, let's talk about the check, and let's talk about quality. Okay. I think building with AI is an opportunity to improve product quality overall, like some of the conversation about durable software. So I'm a believer in quality. **[00:07:49 · 0]** And in traditional software, we've we've built confidence mechanisms in place, to give us confidence that the software is of high quality. And that's done with a variety of mechanisms, but primarily systematically with test cases, unit tests, checking these as a part of our delivery flow to ensure that when we make code changes, mistakes aren't made that break other things. So this is a confidence mechanism that we've put in place with traditional software. The agents are probabilistic. And so the same request can produce different answers. **[00:08:30 · 0]** More than one answer may be acceptable. And we still need evidence, but exact output, comparisons alone really aren't good enough. We need to build a representative data sets and evaluate them and define what good looks like, we need to run these evaluations in repeated series. And this is a statistical analysis, right, where we actually look at the outputs in volume and not just as a direct comparison. So in combining with evals is sort of your runtime logs of what happened or... **[00:09:11 · 0]** Sorry. Traces, which is sort of your runtime logs of what happens. We've built this confidence mechanism to complement traditional software. And ultimately, this is what we're gonna be talking about a little bit more in terms of driving confidence in the output, not only putting this mechanism in place, but how do we begin to turn it on? So where does the agent belong? **[00:09:43 · 0]** Back to the lending example, we can do KYC financials in parallel in sequence like credit memo, risk review, documentation, decision, all these things in our our DAG. Looking at each node, we wanna ask some certain questions like how valuable would it be to have an agent drive this node versus a human drive this node? And we can sort of look at some of these basic questions, like can we check it against the policy easily? Can it run-in a bounded loop? Can we trace it? **[00:10:14 · 0]** Can we fall back to a human? If we can answer yes to these type of questions, we we can kinda have a good idea going in that this particular node may be better suited for automation. But throughout the DAG, we should look to drive agent assistance. So what we're really talking about is not whether or not AI is involved, but whether or not AI we expect to take over at some point. On the decision, you would probably agree that we probably need that to be human driven. **[00:10:47 · 0]** This is essentially V check against the policy. So this is gonna be a little bit more difficult, I think, to hill climb. But what do we mean by hill climb? Alright, how do we turn this on? So Day one, we start supervised and as we have agents and humans working together as a part of the process, we can, manually, verify the output to ensure that it is of high quality. **[00:11:20 · 0]** This is where we refine our datasets and ensure that we have the right confidence mechanisms in place. We've defined what good looks like with the domain subject matter experts and that they're beginning to verify it. When measured confidence reaches a policy threshold, we can move towards sampling. And what that means is humans are looking at a slice of the output and not necessarily all of it. We begin systematic, more systematic evaluation through traces, in order to ensure that what the humans aren't seeing is still meeting the quality bar. **[00:11:59 · 0]** And then finally, once we clear the confidence threshold, humans handle more of the exceptions of the process but still act as participants in refining the data sets and ensuring the quality outputs. Okay, so a few takeaways from this. DAG and DCG, basic graph theory, but ultimately, how do we build these processes that exist today and where people are working them and bring agents into the mix? And the recipe really is to keep it deterministic on the outside and make it adaptive on the inside. The next is quality through evaluation. **[00:12:48 · 0]** And this is really establishing a complimentary confidence mechanism. So it's not a feeling about a model. We can actually provide research and statistics about the quality of our agents. So this builds confidence and inherently trusts output. Quality is a team sport. **[00:13:17 · 0]** AI engineers own the pipeline to taking product signals from all directions and deliver applications that are well built and utilize ML operations behind the scenes. Finally, agents accelerate across the operating model. I've included some references on the final slide of things that I've spoken about today this concludes my presentation. Thank you very much **[00:14:05 · 1]** What does it take to turn advances in AI into meaningful progress for financial services? To share the thinking behind this question and to discuss where it's headed, please welcome the head of ChatGPT for financial services at OpenAI, Joseph **[00:14:25 · 0]** Kim. **[00:14:40 · 2]** Hi, everyone. I'm Joseph Kim, and I lead ChatGPT for Financial Services, a new product we launched just one month ago. Many of you have already experienced how tools like codecs have changed the way you build in software engineering. AI has become a much bigger part of the work you do every day. Model intelligence is continuing to improve at an incredible pace. **[00:15:02 · 2]** But many people working in industries like finance haven't yet experienced that same change in their day to day work. I expect that to start changing rapidly over the next few months. And builders like all of you in this room have a big role in making that happen quickly, taking the intelligence in these models and turning it into products that people can use in their daily work. Today, I will share a little bit about what we learned building ChatTBT for financial services and how we're thinking about what comes next. I'll start by showing you what we've built, including a quick demo. **[00:15:35 · 2]** Then I'll explain why we built it and why we think now is the right time to build. From there, I'll walk you through how we built it with some technical lessons that I hope you can apply to your own products. Finally, we'll take a look at where models are headed and products are going and what that can mean for financial work over the next year. Let's start with what we've built. ChatTkt for Financial Services is a tailored version of ChatTkt work built specifically for financial professionals, starting with investment banking and equity research. **[00:16:07 · 2]** It's designed to help people at the large financial institutions get more out of their day to day work, similar to how codec speeds you up in software development. As we built the product with our design partners, Morgan Stanley and Evercore, we focused on three core areas. First, financial data. Financial data is the foundation of financial work, and the work you can do is limited by the quality of your sources. We We wanted people to have access to the data they need directly within ChatTibT. **[00:16:35 · 2]** Second, an interface built for finance. We wanted the product to feel familiar to financial professionals with ways to inspect source material, explore financial charts, and control the sources behind an analysis. Third, your firm's format. Financial work happens within the context of an organization, and the models and presentations people produce need to follow their form's format and standards. We made it easier to create those artifacts using firm specific templates. **[00:17:04 · 2]** But they say a picture is worth a thousand words, so I'll stop talking for a bit and show you the product. ## Slides ### 00:00:00–00:00:20 # A process aka your “workflow” [Diagram showing three circles connected by lines with arrows, forming a V-shape, representing a flow or process.] ### 00:00:20–00:00:40 # A process maximize parallelism ## Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Directed graph showing a process flow with one start node, two parallel intermediate nodes (one highlighted yellow), and one end node.] ### 00:00:40–00:01:00 # A process Directed Acyclic Graph (DAG) [Diagram showing a Directed Acyclic Graph (DAG) with four nodes and four directed edges forming a diamond shape] ### 00:01:00–00:01:20 # Trusting Agents in Policy-Driven Workflows ## A process Directed Acyclic Graph (DAG) **Evan Kormos**, Engineering Manager, Coinbase [Diagram showing a Directed Acyclic Graph (DAG) with four nodes and directed edges] ### 00:01:20–00:01:40 # Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager coinbase ## A process - Submission - Legal review - Technical review - Listing decision ### 00:01:40–00:02:00 # A process - Change request - Code review - Security scan - Release approval SDLC governance ### Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Flowchart illustrating a process: "Change request" branches into two parallel paths, "Code review" and "Security scan", which then converge into "Release approval".] ### 00:02:00–00:02:20 # Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager coinbase ## A process ### SDLC governance [Flow diagram showing a process: Change request branches to Code review and Security scan, both of which lead to Release approval.] ### 00:02:20–00:02:40 # A process ## Trusting Agents in Policy-Driven Workflows do, then check Evan Kormos / Engineering Manager **coinbase** [Flowchart diagram showing a process: a 'draft' step (circle) leads to a 'check' step (diamond), which then leads to 'pass'. This sequence is enclosed within a larger circle, with arrows indicating input and output.] ### 00:02:40–00:03:00 # A process do, then check ## Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Flowchart showing a process: 'draft' (circle) leads to 'check' (diamond), which leads to 'pass'.] ### 00:03:00–00:03:20 # A process Directed Cyclic Graph (DCG) [Flow diagram showing a process with three main steps: "draft" leads to "check", "check" can either "pass ### 00:03:20–00:03:40 ## A process ### Directed Cyclic Graph (DCG) ## Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Diagram showing a cyclic workflow with steps: draft, check (with pass/fail outcomes), and refine. Draft leads to check. Check can pass (exiting the cycle) or fail, leading to refine. Refine leads back to draft.] ### 00:03:40–00:04:00 # A process Change request Code review Security scan Release approval inner flow: people + agents outer flow: policy boundary ## Trusting Agents in Policy-Driven Workflows ### 00:04:00–00:04:20 # A process not everything goes to plan ## Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Flowchart diagram showing a process: Change request leads to Code review and Security scan. Both Code review and Security scan lead to Release approval. An Exception node is highlighted in yellow, with dashed arrows indicating it can be reached from Code review and Security scan.] ### 00:04:20–00:04:40 # A process [Flowchart showing a process with five nodes: Change request, Code review, Exception, Security scan, and Release approval. Code review has a circular refresh icon. Exception is highlighted in yellow. Arrows indicate flow: Change request leads to Code review and Security scan. Code review leads to Exception and Release approval. Exception leads to Security scan. Security scan leads to Release approval.] volume shifts across the flow ## Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** ### 00:04:40–00:05:00 # A process Code review Change request Release approval Security scan visibility reveals the hotspot [Flowchart diagram illustrating a software development process with steps: Change request, Code review, Security scan, and Release approval. Security scan is highlighted as a hotspot.] ### 00:05:00–00:05:20 # Trusting Agents in Policy-Driven Workflows ## A process visibility reveals the hotspot Evan Kormos / Engineering Manager **coinbase** [Flowchart diagramming a process: "Change request" leads to "Code review" and "Security scan". "Code review" (with a circular arrow indicating iteration) and "Security scan" (a larger node) both lead to "Release approval".] ### 00:05:20–00:05:40 # What's hard? [Flowchart showing a loop: "draft" (circle) leads to "check" (diamond). "check" has two paths: "pass" (arrow right) or "fail" (arrow down) to "refine" (circle). "refine" loops back to "draft".] ### 00:05:40–00:06:00 # What's hard? [Flowchart showing a process with steps: draft (start), check (decision point with pass/fail), and refine. From draft, an arrow goes to check. From check, a 'pass' arrow goes right, and a 'fail' arrow goes to refine. From refine, an arrow goes back to draft.] ### 00:06:00–00:06:20 # What's hard? ## Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager Coinbase [Flowchart illustrating a process: 'draft' leads to 'check'. From 'check', a 'pass' ### 00:06:20–00:06:40 # What's hard? ## Context* - prompt - model - MCP / tools - memory *Making Your Data Ready for Agentic AI - Sadalage & Chandrase ### 00:06:40–00:07:00 # What's hard? **Context*** - prompt - model - MCP / tools - memory * Making Your Data Ready for Agentic AI - Sadalage & Chandrasekaran · martinfowler.com [Flowchart showing a process: Inputs (prompt, model, MCP/tools, memory) feed into 'draft'. 'Draft' leads to 'check'. 'Check' has two paths: 'pass' (exiting) or 'fail' (leading to 'refine'). 'Refine' loops back to 'draft'.] ### 00:07:00–00:07:20 # What's hard? ## Context* - prompt - model - MCP / tools - memory ## Deep - file system - code - tasks * Making Your Data Ready for Agentic AI - Sadalage & Chandrasekaran - martinfowler.com [Flowchart illustrating a process: inputs (prompt, model, MCP/tools, memory, file system, code, tasks) feed into a "draft" stage. From "draft", it proceeds to "check". "Check" has two outcomes: "pass" or "fail". If "fail", it goes to "refine", which loops back to "draft".] ### 00:07:20–00:07:40 # Trusting Agents in Policy-Driven Workflows ## What's hard? [Flowchart showing a process with states: draft, check (a decision point), refine, pass, ### 00:07:40–00:08:00 # Quality traditional software **test cases** inputs + expected outputs **unit tests** check expected behavior we check behavior against expectations ## Trusting Agents in Policy-Driven ### 00:08:00–00:08:20 # Quality ### traditional software - **test cases** (inputs + expected outputs) -> **unit tests** (check expected behavior) we check behavior against expectations [Flowchart showing "test cases" leading to "unit tests"] ### 00:08:20–00:08:40 # Quality traditional software test cases inputs + expected outputs unit tests check expected behavior confidence unit tests build confidence ## Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Flow diagram showing "test cases" leading to "unit tests" which lead to "confidence"] ### 00:08:40–00:09:00 # Quality ## traditional software - **test cases** (inputs + expected outputs) - → **unit tests** (check expected behavior) - → confidence ## probabilistic agents - **datasets** (representative cases) - → **evals** (repeat runs + statistical checks) outputs can vary; new techniques to check --- ### Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Flow diagram comparing quality assurance processes for traditional software and probabilistic agents] ### 00:09:00–00:09:20 # Quality traditional software - **test cases** - inputs + expected outputs - **unit tests** - check expected behavior - confidence probabilistic agents - **datasets** - representative cases - **evals** - repeat runs + statistical checks outputs can vary; new techniques to check [Flow diagram comparing quality assurance for traditional software and probabilistic agents] ### 00:09:20–00:09:40 # Quality ## traditional software - **test cases** (inputs + expected outputs) - -> **unit tests** (check expected behavior) - -> confidence ## probabilistic agents ### 00:09:40–00:10:00 # Trusting Agents in Policy-Driven Workflows ## Where does the agent belong? - policy check - bounded loop - traced - human fallback agent driven Evan Kormos ### 00:10:00–00:10:20 # Where does the agent belong? - policy check - bounded loop - traced - human fallback agent driven ### Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Flowchart diagram showing a process: "intake" branches to "KYC" and "financials", which both lead to "credit memo" (highlighted). "credit memo" then leads to "risk review" and finally "decision".] ### 00:10:20–00:10:40 # Where does the agent belong? - policy check - bounded loop - traced - human fallback agent driven ## Trusting Agents in Policy-Driven Workflows Evan ### 00:10:40–00:11:00 # Where does the agent belong? - policy check - bounded loop - traced - human fallback agent driven ### Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Flow diagram illustrating a process with nodes: intake, KYC, financials, credit memo, risk review, and decision. The "credit memo" node is highlighted.] ### 00:11:00–00:11:20 # Turning it on ## Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Line graph showing a value increasing over time, with points labeled "every output" (value 0.70), "sampled", and "exceptions only" (value ≥ 0.9). The x-axis is labeled "time" and a segment is labeled "start supervised".] ### 00:11:20–00:11:40 # Turning it on every output sampled exceptions only start supervised AI Engineer NEW YORK PRESENTED BY arize ## Trusting Agents in Policy-Driven Workflows Evan K ### 00:11:40–00:12:00 # Turning it on sample as confidence climbs [Line graph showing a metric increasing over time, with x-axis points "every output", "sampled", and "exceptions only". A horizontal ### 00:12:00–00:12:20 ## Turning it on humans handle the exceptions ### Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** [Line graph showing a metric increasing over time, with stages "every output", "sampled", and "exceptions only". The line reaches 0.96, with a threshold of ≥ 0.9 marked.] ### 00:12:20–00:12:40 # Takeaways - Deterministic outside. **Adaptive inside.** ### Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager coinbase ### 00:12:40–00:13:00 # Takeaways - Deterministic outside. **Adaptive** inside. ### 00:13:00–00:13:20 # Takeaways - Deterministic outside. **Adaptive** inside. - Quality through **evaluation**. ## Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering ### 00:13:20–00:13:40 # Takeaways - Deterministic outside. **Adaptive inside.** - Quality through **evaluation.** - People, Process, Technology. ### Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager **coinbase** ### 00:13:40–00:14:00 # Takeaways - Deterministic outside. **Adaptive inside.** - Quality through **evaluation.** - **People, Process, Technology.** Agents accelerate ### Trusting Agents in Policy-Driven Workflows Evan Kormos / Engineering Manager coinbase ### 00:14:00–00:14:20 # AI Engineer ## NEW YORK PRESENTED BY **arize** [Stylized graphic of city skyscrapers and abstract geometric lines] ### 00:14:20–00:14:40 # AI Engineer ## NEW YORK PRESENTED BY arize [Stylized outline of a city skyline] [Arize logo] ### 00:14:40–00:15:00 # Building the Next Chapter of AI in Finance ## OpenAI Joseph Kim Head of ChatGPT for Financial Services AI Engineer NEW YORK Presented by arize [Green icon of a bank building inside ### 00:15:00–00:15:20 # Building the Next Chapter of AI in Finance Joseph Kim Head of ChatGPT for Financial Services [Icon of a green building with columns, resembling a bank, on a blurry green background] ### 00:15:20–00:15:40 # OpenAI ## Building the Next Chapter of AI in Finance Joseph Kim Head of ChatGPT for Financial Services [Icon of a green building (bank/financial institution) inside a cloud shape on a gradient background] ### 00:15:40–00:16:00 # Building the Next Chapter of AI in Finance ## Joseph Kim / Head of ChatGPT for Financial Services OpenAI 1. What we've built 2. Why we built it 3. How we built it 4 ### 00:16:00–00:16:20 # ChatGPT for Financial Services A tailored version of ChatGPT Work built for investment banking, equity research, and more. ## Financial data Built-in premium data, automatic data entitlements, and improved MCP connectors. ## UI Built for finance Inspect source passages and tables, explore interactive charts, and control the sources behind your analysis. ## Your firm's format Centrally managed firm-specific templates, better artifact generation, and improved template following. OpenAI Built on ChatGPT Enterprise security and controls. # Building the Next Chapter of AI in Finance Joseph Kim / Head of ChatGPT for Financial Services OpenAI [Icon of a cloud with a currency symbol] [Icon of a building, possibly a bank] [Icon of a document with a grid] ### 00:16:20–00:16:40 # ChatGPT for Financial Services A tailored version of ChatGPT Work built for investment banking, equity research, and more. ### Financial data - Built-in premium data, automatic data entitlements, ### 00:16:40–00:17:00 # ChatGPT for Financial Services A tailored version of ChatGPT Work built for investment banking, equity research, and more. ## Financial data Built-in premium data, automatic data entitlements, and improved MCP connectors. ## UI Built for finance Inspect source passages and tables, explore interactive charts, and control the sources behind your analysis. ## Your firm's format Centrally managed firm-specific templates, better artifact generation, and improved template following. OpenAI Built on ChatGPT Enterprise security and controls. ### Building the Next Chapter of AI in Finance Joseph Kim / Head of ChatGPT for Financial Services OpenAI [Icon of a wavy line inside a square] [Icon of a building with a dollar sign] [Icon of a document with lines] ### 00:17:00–00:17:20 # ChatGPT for Financial Services A tailored version of ChatGPT Work built for investment banking, equity research, and more. ## Financial data Built-in premium data, automatic data entitlements, and improved MCP connectors. ## UI Built for finance Inspect source passages and tables, explore interactive charts, and control the sources behind your analysis. ## Your firm's format Centrally managed firm-specific templates, better artifact generation, and improved template following. OpenAI Built on ChatGPT Enterprise security and controls. ### Building the Next Chapter of AI in Finance Joseph Kim / Head of ChatGPT for Financial Services OpenAI [Icon of a document with a line graph] [Icon of a building with a gear inside] [Icon of a document with a checklist] ### 00:17:20–00:17:40 # Financial work your team can use ## Building the Next Chapter of AI in Finance Joseph Kim / Head of ChatGPT for Financial Services OpenAI ### 00:17:40–00:18:00 # Understand what change