WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=_4Ph2dhmUFI NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/_4Ph2dhmUFI.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:12.560 --> 00:00:13.840 Hi everyone. s2 00:00:13.840 --> 00:00:15.120 My name is Evan Cormos. s3 00:00:15.120 --> 00:00:19.120 I've been delivering, designing, building software for 20 years. s4 00:00:19.120 --> 00:00:23.680 The last 15 in enterprise financial services. s5 00:00:23.760 --> 00:00:27.440 I am a player coach at Coinbase. s6 00:00:27.440 --> 00:00:32.640 And we're here today to talk about trusting agents in policy-driven workflows. s7 00:00:38.760 --> 00:00:42.120 So, let's start with the policy and it's pretty boring. s8 00:00:42.120 --> 00:00:46.160 Um, I'm going to go over here for my notes. s9 00:00:46.160 --> 00:00:59.880 So, our starting point center centers around the policy and this sets the rules for how work gets done within the organization and including especially risk and compliance. s10 00:01:00.680 --> 00:01:07.200 Think of policy as the original institutional intent or the original system prompt. s11 00:01:07.200 --> 00:01:09.960 So, ideally we have this written down. s12 00:01:09.960 --> 00:01:13.520 Um, it's a little bit boring, so stick with me. s13 00:01:13.640 --> 00:01:17.320 Um, using language like must, may, and should. s14 00:01:17.320 --> 00:01:25.120 And the again, these help define the rules and decisions about how the system operates in the organization. s15 00:01:25.120 --> 00:01:30.280 Separate from policy, we have the actual running system. s16 00:01:32.120 --> 00:01:41.600 So, the first thing we're going to do is separate these two uh these two both the build state and the run state in two different moments in time. s17 00:01:41.600 --> 00:01:51.920 So, typically we're either defining or chaining changing our policy but this the system is constantly running and it's constantly moving and changing. s18 00:01:53.560 --> 00:01:59.040 So, we could then sort of imagine a compilation event that Oops, sorry. s19 00:01:59.040 --> 00:02:01.000 I'm skipping ahead there. s20 00:02:01.000 --> 00:02:03.200 It's constantly changing. s21 00:02:03.200 --> 00:02:08.479 So, it's evolving quickly with these product-driven changes. s22 00:02:08.479 --> 00:02:17.959 So, everything is expected to still be roughly bound by the policy, but ultimately um we separate this from the run state and the build state. s23 00:02:20.080 --> 00:02:23.480 So, inside the system, what does it look like? s24 00:02:23.480 --> 00:02:29.360 We have a familiar model if we have any enterprise uh folks in the in the room here. s25 00:02:29.360 --> 00:02:32.120 Um people, process, and technology. s26 00:02:32.120 --> 00:02:36.760 But, where really do agents fit into this model? s27 00:02:37.520 --> 00:02:42.800 Um so, I see them as an operational model cutting across all three. s28 00:02:42.800 --> 00:02:51.520 They work with people, execute parts of the process themselves, and they use and are made up of technology. s29 00:02:52.800 --> 00:02:58.920 So, for our talk today, we're going to be focusing here where agents meet process. s30 00:02:59.640 --> 00:03:06.560 What work we give them, what boundaries we set, and how we build trust in their outputs. s31 00:03:11.760 --> 00:03:15.160 So, let's dive into your workflow. s32 00:03:15.400 --> 00:03:23.560 And it's high-level and seems basic, but if you haven't, there are good reasons to map this out. s33 00:03:23.560 --> 00:03:32.760 So, maybe a change has to be approved before it goes live, or a customer goes through has to go through verification before their account is opened. s34 00:03:33.000 --> 00:03:37.760 We expect work to flow in a specific and gated direction. s35 00:03:39.800 --> 00:03:47.680 So, I believe it makes it agents make it worth revisiting what we can do in parallel. s36 00:03:48.760 --> 00:03:54.920 So, previously some work used to cost too much or be too complex to coordinate in this way. s37 00:03:54.920 --> 00:04:03.280 But now we can run independent reviews alongside each other, bring the results together, but keep the required checks in place. s38 00:04:05.680 --> 00:04:09.720 So this is a directed acyclic graph or a DAG. s39 00:04:09.920 --> 00:04:19.760 It is a way to represent this workflow or process, the steps, the dependencies for a flow that moves forward without looping back on itself. s40 00:04:20.480 --> 00:04:31.480 Apache Airflow, if you're familiar, is an example of open source software that represents workflows, their dependencies as DAGs in Python code. s41 00:04:39.960 --> 00:04:50.760 So this Python code, this these DAGs can be used to define and manage a number of policy driven processes like, for example, commercial lending. s42 00:04:53.480 --> 00:05:02.360 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. s43 00:05:03.600 --> 00:05:10.200 Or we could use a DAG to represent a regulated flow of delivering software, which is a hot topic. s44 00:05:10.200 --> 00:05:21.760 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 s45 00:05:21.760 --> 00:05:29.520 efficiency and scale in other areas of the business and close that the the adoption gap. s46 00:05:31.120 --> 00:05:36.320 So let's stick with the software delivery example for a little bit. s47 00:05:37.000 --> 00:05:40.240 What happens inside one of these nodes of the process? s48 00:05:40.240 --> 00:05:44.240 And I'll give you a hint, it's a loop. s49 00:05:51.760 --> 00:06:00.560 I'm oversimplified, but we have a basic version of what's happening within the Let's Let's say this is a code review process, right? s50 00:06:00.560 --> 00:06:13.280 So, we're going to essentially do a number of steps and essentially once we realize the work we recognize that the work is good enough, we're going to allow it to pass on to the next step. s51 00:06:13.280 --> 00:06:17.840 And that's essentially the function of the code review node. s52 00:06:19.800 --> 00:06:22.240 The work doesn't always uh end up okay. s53 00:06:22.240 --> 00:06:32.160 So, sometimes we have to take the feedback from the code review and iterate on it um until the work is a good enough to pass. s54 00:06:36.320 --> 00:06:41.640 So, this is a representation of a directed cyclic graph or DCG. s55 00:06:42.680 --> 00:06:54.880 So, as far as open source software, uh something like LangChain LangGraph would be what I would um say is helpful to manage the state of DCGs. s56 00:06:56.000 --> 00:06:59.320 Um and this is an oversimpli- an oversimplification. s57 00:06:59.320 --> 00:07:02.280 These graphs can be very complex. s58 00:07:04.360 --> 00:07:11.360 So, zooming back out, the inner flow um of the node, we have people and agents working together. s59 00:07:11.360 --> 00:07:14.919 On the outer flow, we have a policy boundary. s60 00:07:16.720 --> 00:07:19.400 But not everything goes to plan. s61 00:07:19.400 --> 00:07:21.280 Um so, we have to handle exception flows. s62 00:07:21.280 --> 00:07:27.320 We don't want the work to get stuff stuck, and we don't want to design for every edge case, either. s63 00:07:27.360 --> 00:07:40.640 Um the exception flows will monitor and see kind of what happens if you're shipping code that gets canceled or doesn't meet security standards, that's something you would should want to know about. s64 00:07:42.840 --> 00:07:56.680 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 s65 00:07:56.680 --> 00:08:03.600 reviewing code faster you need to design it quicker or you need to do the security scan that's faster. s66 00:08:03.600 --> 00:08:07.520 So we see the volume shift across the flow. s67 00:08:08.600 --> 00:08:23.080 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 s68 00:08:23.080 --> 00:08:33.120 and so the operational visibility of the process is extremely important much more important than the authoring and the building of your workflow tool. s69 00:08:33.120 --> 00:08:37.039 Um so we want to visualize the process. s70 00:08:38.560 --> 00:08:45.560 So we want to add parallel capacity by still keeping the controls and so this is where we'll add more additional capacity. s71 00:08:51.520 --> 00:08:52.480 Okay. s72 00:08:52.480 --> 00:08:59.880 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. s73 00:08:59.880 --> 00:09:01.200 But why is that hard? s74 00:09:01.200 --> 00:09:03.760 Oh it seems like a pretty easy thing to do. s75 00:09:03.760 --> 00:09:13.560 But as I mentioned before these graphs get actually pretty complex and we'll dive a little bit more into why this is difficult. s76 00:09:14.400 --> 00:09:31.280 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. s77 00:09:31.560 --> 00:09:34.839 But what are quality inputs? s78 00:09:41.320 --> 00:09:46.280 So, we would generally speak to it as context model maybe. s79 00:09:46.280 --> 00:09:50.520 We can nitpick that, but this isn't our area of focus today. s80 00:09:50.520 --> 00:09:52.680 We're going to focus more on outputs. s81 00:09:52.680 --> 00:10:00.440 But, we can't really talk about quality of outputs without the quality of without talking about the quality of inputs. s82 00:10:01.200 --> 00:10:05.520 So, ideally we've established a trusted context for our agent. s83 00:10:05.520 --> 00:10:17.840 Um 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. s84 00:10:20.880 --> 00:10:32.880 Okay, so now we've added even long time horizon goals and that's emphasizes the need to optimize the cost and efficiency of this loop. s85 00:10:38.880 --> 00:10:43.200 So, the check is where we decide whether the work is good enough to move forward. s86 00:10:43.200 --> 00:10:45.080 We need to define what good looks like. s87 00:10:45.080 --> 00:10:47.520 That's the hard part. s88 00:10:47.880 --> 00:10:50.920 And we need to have a reliable way to evaluate it. s89 00:10:50.920 --> 00:10:55.880 Otherwise, more passes don't necessarily uh mean better results. s90 00:10:55.880 --> 00:10:59.320 The loop is really only as trustworthy as the check. s91 00:10:59.320 --> 00:11:04.720 So, if we want to talk about quality, let's talk about the check and let's talk about quality. s92 00:11:06.520 --> 00:11:13.440 Okay, um I think building with AI is an opportunity to improve product quality overall. s93 00:11:13.440 --> 00:11:16.240 I like some of the conversation about durable software. s94 00:11:16.240 --> 00:11:32.640 Um So, I'm a believer in quality and in traditional software um we we built confidence mechanisms in place uh to give us confidence that the software is of high quality. s95 00:11:32.640 --> 00:11:47.680 And that's done with a variety of uh mechanisms, but primarily systematically with test cases, unit tests, um 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, right? s96 00:11:47.680 --> 00:11:53.520 So, this is a confidence mechanism that we've put in place with traditional software. s97 00:11:55.080 --> 00:12:02.040 The agents are probabilistic, and so the same request can produce different answers. s98 00:12:02.040 --> 00:12:05.840 More than one answer may be acceptable. s99 00:12:06.560 --> 00:12:13.280 And we still need evidence, but exact output uh comparisons alone really aren't good enough. s100 00:12:13.280 --> 00:12:21.520 Uh we need to build a representative data sets and evaluate them um and define what good looks like. s101 00:12:21.520 --> 00:12:29.880 We need to run uh ev- these evaluations in repeated uh series, and this is a statistical analysis, right? s102 00:12:29.880 --> 00:12:37.839 Um where we actually look at the outputs uh and in volume and not just as a direct comparison. s103 00:12:38.720 --> 00:12:48.120 So, in combining with evals is sort of your run time logs of what happened, or sorry, traces, uh wh- which are sort of your run time logs of what happens. s104 00:12:48.120 --> 00:12:55.200 Um we've built this confidence mechanism to complement um traditional software. s105 00:12:57.360 --> 00:13:08.080 And ultimately, this is what we're going to be talking about a little bit more in in terms of driving confidence in the output, not only putting this mechanism in place, but how do we begin to turn it on? s106 00:13:12.480 --> 00:13:15.200 So, where does the agent belong? s107 00:13:15.200 --> 00:13:27.280 Um back to the lending example, like we can do KYC, financials in parallel and sequence like credit memo, risk review, documentation, decision, all these things in our our DAG. s108 00:13:27.280 --> 00:13:37.400 Um looking at each node, we want to ask some certain questions like how valuable would it be to have an agent drive this node versus a human drive this node? s109 00:13:37.400 --> 00:13:43.280 Um and we can sort of look at some of these basic questions like can we check it against the policy easily? s110 00:13:43.280 --> 00:13:45.120 Can it run in a bounded loop? s111 00:13:45.120 --> 00:13:46.280 Can we trace it? s112 00:13:46.280 --> 00:13:48.240 Can we fall back to a human? s113 00:13:48.240 --> 00:13:57.520 Um if we can answer yes to these type of questions, and we we can kind of have a good idea going in that this particular node may be better suited for automation. s114 00:13:57.520 --> 00:14:02.040 Um but throughout the DAG, we should look to drive agent assistance. s115 00:14:02.040 --> 00:14:11.840 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. s116 00:14:14.520 --> 00:14:18.880 On the decision, you would probably agree that we probably need that to be human-driven. s117 00:14:18.880 --> 00:14:21.960 This is essentially the check against the policy. s118 00:14:21.960 --> 00:14:27.760 Um so, this is going to be a little bit more difficult, I think, to hill climb. s119 00:14:29.400 --> 00:14:31.360 But what do we mean by hill climb? s120 00:14:31.360 --> 00:14:34.320 All right, how do we turn this on? s121 00:14:34.360 --> 00:14:51.640 So, day one, um we start supervised and as we have agents and humans working together as a part of the process, we can um manually um verify the output to ensure that it is high high quality. s122 00:14:51.640 --> 00:14:58.280 Um this is where we refine our data sets and ensure that we have the right confidence mechanisms in place. s123 00:14:58.280 --> 00:15:05.839 We've defined what good looks like with the domain subject matter experts and that they're beginning to verify it. s124 00:15:07.480 --> 00:15:12.440 When measured confidence reaches a policy threshold, we can move towards sampling. s125 00:15:12.440 --> 00:15:18.000 And what that means is humans are looking at a slice of the output and not necessarily all of it. s126 00:15:18.000 --> 00:15:29.960 Um we begin systematic more systematic evaluation through traces Um in order to ensure that what we're what the humans aren't seeing is still meeting the quality bar. s127 00:15:31.280 --> 00:15:43.760 And then finally, once we clear the confidence threshold, humans handle more of the exceptions of the process, but still acting as participants in refining the data sets and ensuring the quality outputs. s128 00:15:48.800 --> 00:15:52.240 Okay, so a few takeaways from this. s129 00:15:52.240 --> 00:16:04.920 Um 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. s130 00:16:04.920 --> 00:16:12.520 And the recipe really is to keep it deterministic on the outside and make it adaptive on the inside. s131 00:16:17.760 --> 00:16:20.280 The next is quality through evaluation. s132 00:16:20.280 --> 00:16:26.680 And this is really establishing a complementary confidence mechanism. s133 00:16:26.680 --> 00:16:29.040 So, it's not a feeling about a model. s134 00:16:29.040 --> 00:16:37.600 We can actually provide research and statistics about the quality of our agents. s135 00:16:39.320 --> 00:16:44.400 So, this builds confidence and inherently trusts output. s136 00:16:46.160 --> 00:16:49.200 Quality is a team sport. s137 00:16:49.200 --> 00:17:03.960 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. s138 00:17:06.680 --> 00:17:12.240 Finally, agents accelerate across the operating model. s139 00:17:15.319 --> 00:17:21.560 I've included some references on the final slide of things that I've spoken about today. s140 00:17:21.839 --> 00:17:23.760 This concludes my presentation. s141 00:17:23.760 --> 00:17:25.391 Thank you very much. s142 00:17:25.391 --> 00:17:27.391 [applause]