1 00:00:04,301 --> 00:00:05,181 Hi, everyone. 2 00:00:05,641 --> 00:00:07,221 My name is Evan Kormos. 3 00:00:07,421 --> 00:00:13,381 I've been delivering, designing, building software for 20 years, the last 15 enterprise 4 00:00:13,381 --> 00:00:14,341 financial services. 5 00:00:15,561 --> 00:00:18,461 I am a player coach at Coinbase. 6 00:00:19,341 --> 00:00:23,201 and we're here today to talk about trusting agents and policy-driven workflows. 7 00:00:30,641 --> 00:00:33,661 So let's start with the policy, and it's pretty boring. 8 00:00:34,921 --> 00:00:36,741 I'm going to go over here for my notes. 9 00:00:38,041 --> 00:00:41,261 So our starting point centers around the policy, 10 00:00:41,441 --> 00:00:47,221 and this sets the rules for how work gets done within the organization. 11 00:00:47,221 --> 00:00:50,641 and including especially risk and compliance. 12 00:00:52,381 --> 00:00:55,461 Think of policy as the original institutional intent 13 00:00:56,221 --> 00:00:58,261 or the original system prompt. 14 00:00:59,601 --> 00:01:01,381 ideally we have this written down. 15 00:01:01,901 --> 00:01:03,961 It's a little bit boring, so stick with me. 16 00:01:05,721 --> 00:01:08,501 Using language like must, may, and should. 17 00:01:09,201 --> 00:01:12,681 And again, these help define the rules and decisions 18 00:01:12,681 --> 00:01:15,961 about how the system operates in the organization. 19 00:01:17,221 --> 00:01:20,901 Separate from policy, we have the actual running system. 20 00:01:23,961 --> 00:01:33,121 So the first thing we're going to do is separate these two, both the build state and the run state, at two different moments in time. 21 00:01:33,401 --> 00:01:42,521 So typically we're either defining or changing our policy, but the system is constantly running and it's constantly moving and changing. 22 00:01:45,561 --> 00:01:51,801 So we could then sort of imagine a compilation event that, oops, sorry, I'm skipping ahead. 23 00:01:52,981 --> 00:01:54,381 It's constantly changing. 24 00:01:57,581 --> 00:02:00,561 So it's evolving quickly with these product-driven changes. 25 00:02:00,781 --> 00:02:06,841 Everything is expected to still be roughly bound by the policy, but ultimately we separate 26 00:02:06,841 --> 00:02:08,481 this from the run state and the build state. 27 00:02:12,001 --> 00:02:15,401 So inside the system, what does it look like? 28 00:02:15,641 --> 00:02:17,181 We have a familiar model, 29 00:02:17,341 --> 00:02:20,141 if we have any enterprise folks in the room here. 30 00:02:21,721 --> 00:02:23,581 People, process, and technology. 31 00:02:24,141 --> 00:02:27,281 But where really do agents fit into this mold? 32 00:02:29,561 --> 00:02:32,121 So I see them as an operational model 33 00:02:32,121 --> 00:02:33,381 cutting across all three. 34 00:02:34,701 --> 00:02:35,981 They work with people, 35 00:02:36,201 --> 00:02:37,861 execute parts of the process, 36 00:02:39,161 --> 00:02:42,301 themselves, and they use and are made up of technology. 37 00:02:44,761 --> 00:02:49,621 So for our talk today, we're going to be focusing here where agents meet process, 38 00:02:51,721 --> 00:02:57,221 what work we give them, what boundaries we set, and how we build trust in their outputs. 39 00:03:03,781 --> 00:03:05,801 So let's dive into your workflow. 40 00:03:07,341 --> 00:03:14,201 And it's high level and seems basic, but if you haven't, there are good reasons to map this out. 41 00:03:15,521 --> 00:03:23,361 So maybe a change has to be approved before it goes live, or a customer has to go through verification before their account is opened. 42 00:03:24,981 --> 00:03:28,441 We expect work to flow in a specific and gated direction. 43 00:03:31,681 --> 00:03:38,321 So I believe it makes, agents make it worth revisiting what we can do in parallel. 44 00:03:41,121 --> 00:03:45,481 Previously, some work used to cost too much or be too complex to coordinate in this way. 45 00:03:46,681 --> 00:03:52,261 But now we can run independent reviews alongside each other, bring the results together, but 46 00:03:52,261 --> 00:03:53,841 keep the required checks in place. 47 00:03:57,421 --> 00:04:00,461 So this is a directed acyclic graph, or a DAG. 48 00:04:01,641 --> 00:04:04,581 It is a way to represent this workflow or process, 49 00:04:04,881 --> 00:04:06,101 the steps, the dependencies, 50 00:04:07,321 --> 00:04:10,381 for a flow that moves forward without looping back on itself. 51 00:04:12,481 --> 00:04:14,201 Apache Airflow, if you're familiar, 52 00:04:14,381 --> 00:04:16,521 is an example of open-source software 53 00:04:16,521 --> 00:04:18,441 that represents workflows, 54 00:04:19,541 --> 00:04:21,981 dependencies as DAGs in Python code. 55 00:04:31,761 --> 00:04:38,861 So, this Python code, these DAGs can be used to define and manage a number of policy-driven 56 00:04:38,861 --> 00:04:48,741 processes like, for example, commercial lending. We could also use a DAG to represent the workflow 57 00:04:48,741 --> 00:04:56,341 flow to list a token on the exchange in a specific region, if you're into that. Or we 58 00:04:56,341 --> 00:05:01,101 could use a DAG to represent a regulated flow of delivering software, which is a hot topic. 59 00:05:02,421 --> 00:05:08,601 One we'll spend a little bit of time on, I think that we've seen a lot of adoption within 60 00:05:08,601 --> 00:05:14,521 agents, within software delivery, and ultimately we're looking to leverage that same efficiency 61 00:05:14,521 --> 00:05:16,821 and scale in other areas of the business 62 00:05:16,821 --> 00:05:20,061 and close the adoption gap. 63 00:05:22,901 --> 00:05:26,141 So let's stick with the software delivery example 64 00:05:26,141 --> 00:05:26,781 for a little bit. 65 00:05:28,841 --> 00:05:32,181 What happens inside one of these nodes of the process? 66 00:05:32,541 --> 00:05:34,261 And I'll give you a hint. 67 00:05:34,381 --> 00:05:34,841 It's a loop. 68 00:05:44,861 --> 00:05:46,981 oversimplified, but we have a basic version 69 00:05:46,981 --> 00:05:48,801 of what's happening within the, 70 00:05:48,941 --> 00:05:51,641 let's say this is the code review process, right? 71 00:05:53,321 --> 00:05:57,201 So we're going to essentially do a number of steps, 72 00:05:57,201 --> 00:06:00,741 and essentially once we realize the work, 73 00:06:00,841 --> 00:06:02,721 we recognize that the work is good enough, 74 00:06:02,721 --> 00:06:05,041 we're going to allow it to pass on to the next step. 75 00:06:05,221 --> 00:06:08,341 And that's essentially the function of the code review node. 76 00:06:11,701 --> 00:06:14,101 The work doesn't always end up okay. 77 00:06:14,381 --> 00:06:17,701 So sometimes we have to take the feedback from the code review 78 00:06:17,701 --> 00:06:22,761 and iterate on it until the work is good enough to pass. 79 00:06:28,221 --> 00:06:32,501 So this is a representation of a directed cyclic graph, or DCG. 80 00:06:34,541 --> 00:06:40,341 So, as far as open source software, something like LangChain, LangGraph would be what I would 81 00:06:42,621 --> 00:06:45,781 say is helpful to manage the state of DCGs. 82 00:06:48,141 --> 00:06:51,221 And this is an oversimplification. 83 00:06:51,521 --> 00:06:52,921 These graphs can be very complex. 84 00:06:56,261 --> 00:07:02,641 So zooming back out, the inner flow of the node, we have people and agents working together. 85 00:07:02,641 --> 00:07:05,481 together, on the outer flow, we have a policy boundary. 86 00:07:08,621 --> 00:07:10,121 But not everything goes to plan. 87 00:07:11,661 --> 00:07:13,441 So we have to handle exception flows. 88 00:07:13,581 --> 00:07:17,861 We don't want the work to get stuck and we don't want to design for every edge case either. 89 00:07:19,481 --> 00:07:25,281 The exception flows will monitor and see kind of what happens if you're shipping code that 90 00:07:25,281 --> 00:07:29,141 gets cancelled or doesn't meet security standards. 91 00:07:29,141 --> 00:07:31,201 that's something you should want to know about. 92 00:07:34,961 --> 00:07:38,781 Volume shifts across the flow once we start to add agents into the mix. 93 00:07:39,021 --> 00:07:41,861 And we've seen this with software delivery, 94 00:07:42,061 --> 00:07:46,581 and we'll see it in other processes as we bring agents into those processes as well, 95 00:07:46,761 --> 00:07:50,161 where now all of a sudden if you're reviewing code faster, 96 00:07:50,721 --> 00:07:55,521 you need to design it quicker, or you need to do the security scan faster. 97 00:07:55,521 --> 00:07:58,101 So we see the volume shift across the flow. 98 00:08:00,641 --> 00:08:06,701 And this is where it's really important that we have visibility into the process overall from a metric standpoint. 99 00:08:07,001 --> 00:08:14,921 Because as we start to supercharge and parallelize and add more efficiency to the process, we start to develop more and more bottlenecks. 100 00:08:15,081 --> 00:08:20,181 And so the operational visibility of the process is extremely important. 101 00:08:20,401 --> 00:08:24,161 Much more important than the authoring and the building of your workflow tool. 102 00:08:25,381 --> 00:08:27,681 so we want to visualize the process 103 00:08:30,461 --> 00:08:32,261 so we want to add parallel capacity 104 00:08:32,261 --> 00:08:33,861 by still keeping the controls 105 00:08:33,861 --> 00:08:36,321 and so this is where we'll add more additional capacity 106 00:08:43,521 --> 00:08:44,001 okay 107 00:08:44,001 --> 00:08:46,321 so we're doing some work 108 00:08:46,321 --> 00:08:47,121 we're checking it 109 00:08:47,121 --> 00:08:49,781 we're using the feedback again to refine it 110 00:08:49,781 --> 00:08:51,441 until the work is good enough to move on 111 00:08:51,441 --> 00:08:53,141 but why is that hard? 112 00:08:53,141 --> 00:08:55,341 That seems like a pretty easy thing to do. 113 00:08:55,661 --> 00:08:59,861 But as I mentioned before, these graphs get actually pretty complex, 114 00:09:01,021 --> 00:09:04,161 and we'll dive a little bit more into why this is difficult. 115 00:09:06,621 --> 00:09:09,521 And if you're familiar, one challenge with AI engineering 116 00:09:09,521 --> 00:09:12,161 is the variability of inputs and outputs. 117 00:09:12,481 --> 00:09:15,761 And I believe that higher quality inputs 118 00:09:17,961 --> 00:09:21,901 will result in better outputs at a lower compute cost. 119 00:09:23,461 --> 00:09:25,361 but what are quality inputs? 120 00:09:34,101 --> 00:09:38,161 So we'll generally speak to it as context model, maybe. 121 00:09:38,401 --> 00:09:39,301 We can nitpick that. 122 00:09:39,481 --> 00:09:42,201 But this isn't our area of focus today. 123 00:09:42,621 --> 00:09:44,141 We're going to focus more on outputs. 124 00:09:44,541 --> 00:09:47,841 But we can't really talk about quality of outputs 125 00:09:47,841 --> 00:09:51,101 without talking about the quality of inputs. 126 00:09:53,141 --> 00:09:56,861 So ideally, we've established a trusted context for our agent, 127 00:09:57,961 --> 00:09:59,901 and there's some references on that. 128 00:10:00,121 --> 00:10:06,101 But one thing we can do in this model is inject the DAG state into our agent 129 00:10:06,101 --> 00:10:08,421 and let it know kind of where it fits into the bigger picture. 130 00:10:12,781 --> 00:10:18,161 Okay, so now we've added even long time horizon goals, 131 00:10:18,161 --> 00:10:23,421 and that emphasizes the need to optimize the cost and efficiency of this loop. 132 00:10:30,761 --> 00:10:34,421 So the check is where we decide whether the work is good enough to move forward. 133 00:10:35,061 --> 00:10:37,281 We need to define what good looks like. 134 00:10:37,401 --> 00:10:38,081 That's the hard part. 135 00:10:39,961 --> 00:10:42,981 And we need to have a reliable way to evaluate it. 136 00:10:43,061 --> 00:10:47,841 Otherwise, more passes don't necessarily mean better results. 137 00:10:48,161 --> 00:10:50,741 the loop is really only as trustworthy as the check. 138 00:10:51,441 --> 00:10:53,381 So if we want to talk about quality, 139 00:10:53,521 --> 00:10:55,401 let's talk about the check and let's talk about quality. 140 00:10:58,961 --> 00:11:03,041 Okay, I think building with AI is an opportunity 141 00:11:03,041 --> 00:11:05,281 to improve product quality overall. 142 00:11:05,521 --> 00:11:08,081 I like some of the conversation about durable software. 143 00:11:10,341 --> 00:11:12,181 So I'm a believer in quality. 144 00:11:12,801 --> 00:11:14,281 And in traditional software, 145 00:11:16,121 --> 00:11:18,721 we've built confidence mechanisms in place 146 00:11:19,681 --> 00:11:23,821 to give us confidence that the software is of high quality. 147 00:11:24,521 --> 00:11:26,981 And that's done with a variety of mechanisms, 148 00:11:27,261 --> 00:11:31,741 but primarily systematically with test cases, unit tests, 149 00:11:32,601 --> 00:11:34,801 checking these as a part of our delivery flow 150 00:11:34,801 --> 00:11:37,121 to ensure that when we make code changes, 151 00:11:37,121 --> 00:11:38,961 mistakes aren't made that break other things. 152 00:11:39,441 --> 00:11:42,681 So this is a confidence mechanism that we've put in place 153 00:11:42,681 --> 00:11:44,181 with traditional software. 154 00:11:46,741 --> 00:11:53,421 The agents are probabilistic, and so the same request can produce different answers. 155 00:11:54,621 --> 00:11:56,581 than one answer may be acceptable. 156 00:11:58,321 --> 00:12:04,441 And we still need evidence, but exact output comparisons alone really aren't good enough. 157 00:12:05,881 --> 00:12:12,601 need to build representative data sets and evaluate them and define what good looks 158 00:12:12,601 --> 00:12:12,961 like. 159 00:12:12,961 --> 00:12:18,901 we need to run these evaluations in repeated series, 160 00:12:19,201 --> 00:12:21,541 and this is a statistical analysis, right, 161 00:12:22,341 --> 00:12:26,901 where we actually look at the outputs in volume 162 00:12:26,901 --> 00:12:28,561 and not just as a direct comparison. 163 00:12:31,301 --> 00:12:34,941 So combining with evals as sort of your runtime logs 164 00:12:34,941 --> 00:12:36,461 of what happened, or sorry, traces, 165 00:12:36,921 --> 00:12:39,661 which are sort of your runtime logs of what happens, 166 00:12:40,621 --> 00:12:42,701 we've built this confidence mechanism 167 00:12:42,701 --> 00:12:45,901 to complement traditional software. 168 00:12:49,581 --> 00:12:52,121 And ultimately, this is what we're going to be talking about 169 00:12:52,121 --> 00:12:55,161 a little bit more in terms of driving confidence in the output, 170 00:12:55,441 --> 00:12:57,161 not only putting this mechanism in place, 171 00:12:57,181 --> 00:12:58,521 but how do we begin to turn it on. 172 00:13:05,241 --> 00:13:06,881 So where does the agent belong? 173 00:13:07,581 --> 00:13:09,041 Back to the lending example. 174 00:13:09,041 --> 00:13:11,241 we can do KYC 175 00:13:11,241 --> 00:13:13,561 financials in parallel and sequence 176 00:13:13,561 --> 00:13:15,161 like credit memo, risk review 177 00:13:15,161 --> 00:13:17,501 documentation, decision, all these things 178 00:13:17,501 --> 00:13:19,101 in our DAG 179 00:13:19,101 --> 00:13:21,541 looking at each node we want to ask 180 00:13:21,541 --> 00:13:23,781 some certain questions like how valuable 181 00:13:23,781 --> 00:13:25,621 would it be to have an agent 182 00:13:26,181 --> 00:13:27,361 drive this node 183 00:13:27,361 --> 00:13:29,041 versus a human drive this node 184 00:13:29,901 --> 00:13:31,481 and we can sort of look 185 00:13:31,481 --> 00:13:33,061 at some of these basic questions like 186 00:13:33,061 --> 00:13:35,261 can we check it against the policy easily 187 00:13:35,261 --> 00:13:36,921 can it run in a bounded loop 188 00:13:36,921 --> 00:13:38,241 Can we trace it? 189 00:13:38,581 --> 00:13:39,821 Can we fall back to a human? 190 00:13:40,241 --> 00:13:42,561 If we can answer yes to these type of questions, 191 00:13:43,281 --> 00:13:46,021 we can kind of have a good idea going in 192 00:13:46,021 --> 00:13:49,081 that this particular node may be better suited for automation. 193 00:13:49,721 --> 00:13:54,081 But throughout the DAG, we should look to drive agent assistance. 194 00:13:54,381 --> 00:13:57,781 So what we're really talking about is not whether or not AI is involved, 195 00:13:57,961 --> 00:14:02,381 but whether or not AI we expect to take over at some point. 196 00:14:06,641 --> 00:14:11,481 on the decision you would probably agree that we probably need that to be human driven this is 197 00:14:11,481 --> 00:14:17,261 essentially the check against the policy um so this is going to be a little bit more difficult 198 00:14:17,261 --> 00:14:24,901 i think to hill climb but what do we mean by hill climb all right how do we turn this on 199 00:14:28,341 --> 00:14:31,601 So day one, we start supervised. 200 00:14:31,961 --> 00:14:43,041 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. 201 00:14:44,121 --> 00:14:49,981 This is where we refine our data sets and ensure that we have the right confidence mechanisms in place. 202 00:14:50,241 --> 00:14:53,841 We've defined what good looks like with the domain subject matter experts. 203 00:14:53,841 --> 00:14:56,301 and that they're beginning to verify it. 204 00:14:59,281 --> 00:15:02,601 When measured confidence reaches a policy threshold, 205 00:15:02,941 --> 00:15:04,541 we can move towards sampling. 206 00:15:04,821 --> 00:15:08,241 And what that means is humans are looking at a slice of the output 207 00:15:08,241 --> 00:15:09,641 and not necessarily all of it. 208 00:15:10,201 --> 00:15:14,341 We begin more systematic evaluation through traces 209 00:15:15,301 --> 00:15:18,961 in order to ensure that what the humans aren't seeing 210 00:15:18,961 --> 00:15:20,481 is still meeting the quality bar. 211 00:15:23,121 --> 00:15:34,401 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. 212 00:15:40,721 --> 00:15:43,121 Okay, so a few takeaways from this. 213 00:15:45,541 --> 00:15:46,801 DAG and DCG. 214 00:15:47,881 --> 00:15:49,001 Basic graph theory. 215 00:15:49,001 --> 00:15:52,781 but ultimately how do we build these processes that exist today 216 00:15:52,781 --> 00:15:56,581 and where people are working them and bring agents into the mix? 217 00:15:56,921 --> 00:16:00,561 And the recipe really is to keep it deterministic on the outside 218 00:16:00,561 --> 00:16:03,181 and make it adaptive on the inside. 219 00:16:09,521 --> 00:16:11,881 The next is quality through evaluation. 220 00:16:12,261 --> 00:16:17,701 And this is really establishing a complementary confidence mechanism. 221 00:16:19,001 --> 00:16:25,241 So it's not a feeling about a model. We can actually provide research and statistics 222 00:16:25,841 --> 00:16:28,221 about the quality of our agents. 223 00:16:31,421 --> 00:16:35,021 So this builds confidence and inherently trusts output. 224 00:16:38,041 --> 00:16:45,621 Quality is a team sport. AI engineers own the pipeline to taking product signals 225 00:16:45,621 --> 00:16:47,461 from all directions 226 00:16:48,441 --> 00:16:51,061 and deliver applications that are well-built 227 00:16:51,061 --> 00:16:54,521 and utilize ML operations behind the scenes. 228 00:16:58,661 --> 00:17:02,741 Finally, agents accelerate across the operating model. 229 00:17:07,181 --> 00:17:10,041 I've included some references on the final slide, 230 00:17:10,301 --> 00:17:12,041 things that I've spoken about today. 231 00:17:13,581 --> 00:17:15,161 This concludes my presentation. 232 00:17:15,621 --> 00:17:16,741 Thank you very much.