Full automation is the happy path, improving critical business-critical task outcomes and organizing the automation's output (exhaust) so that experts can focus on high-value problems rather than routine work.
Searchable transcript of Engineering Agency out of the Happy Path — Matthew Jewkes, Standard Cybernetics — AI Engineer (19:42). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by AI Engineer. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:01 [music] Uh afternoon everybody. Uh I'm going to talk today about engineering agency out of the happy path. Um this is going to be focused on AI leadership, engineering leadership at growth stage companies. Um, and I'd like to start by asking everybody to think about the strongest domain experts on your team. So these are people who uh, you know, if sales wants to build a new feature or deliver something new in order to close an account or an urgent customer ticket appears, uh, these are the people who get at paint.
00:44 Uh, they're the people maybe who are responsible for a small team or for a critical business process. And I want to think about how these people actually spend most of their work weeks. Uh my experience is that most experts I've worked with have their attention sort of smeared over multitasking, loading up on complicated situations, making decisions that could have been routine or obvious in retrospect and only a small fraction of their attention is left over to sort of move the business forward.
01:16 Um now like the cost of like raw white collar output is dropping. It's cratering. I've talked to a bunch of people over the conference and regardless of what you think about frontier models and where the future's going to go in terms of new capacity. Everybody I've talked to has agreed that existing capacity is going to get very very cheap. Cheap execution increases the load and the on on judgment on deciding what to do.
01:39 Uh organizational judgment was already in short supply. Uh and this is going to make it even worse. I think this is currently underpriced. So with that in mind, I'm going to talk today about using AI for full automations. By full automations, I mean taking humans out of the happy path completely. Using humans maybe for exceptions, but not not human in the loop um style automations.
01:58 I think that these types of processes can improve margins kind of obvious. They can reduce complexity of a business by encapsulating whole chunks of work. Uh and then you can recover judgment from your experts and hopefully route it towards more important um tasks or questions. I'm going to talk about that specifically a bit later. Um, now the key to full automations and my experience has been engineering agency out of the happy path out of these automations.
02:25 This is a bit of a reversal. You know, agents have permanently changed and expanded my idea of what I think is possible with software. But in enterprise, agents have problems. They're a pain to maintain. Uh, especially if skills and harnesses are changing. Uh, they fail in unusually shaped ways that enterprises find hard to work with. And then they increase the burden of decisions.
02:46 When I see an expert or a leader responding to agent notifications, you know, maybe on their phone or or on their laptop, maybe they have an app for it. I'm often suspicious. Is that actually the best use of their, you know, valuable time and attention? Full automations, on the other hand, they free up attention. They're legible. So this means that, you know, they take an input, they produce an output, they encapsulate the whole thing, and they hide the complexity.
03:09 And they're organizationally familiar. Like large human organizations have been building automations in software for decades. Think marketing, think DevOps. And they've been building uh automations in industry for centuries. Full automations are one of the key tools by which human organizations can do bigger and bigger things. And that is giving the whole system an escape hatch.
03:35 So, one of the problems with full automations is, and I'm sure people have seen this, when you get uh you sign up for something and maybe you accidentally get a whole marketing drip email when you were signing up as a vendor. Um, one of the interesting things you can do with AI and agency with automations is you can pre-filter inputs. You can check does this task actually match the happy path of the automation.
03:56 You can reject adversarial situations. If something looks like it's business critical, sort of not a normal course of business operation, you can escalate that to a human. I think this is kind of neat. This is the use of AI, AI agency to reduce the variance of an automation to make things more smooth, which thereby lets us expand the scope of what we can automate.
04:15 So I'm going to give a case study today. My background is working in bioarma data at scale. I had a company called deal enablement for bioharmaceutical mergers, licensing and acquisitions. In 23 we sold to clarvate. Clarvate is a really interesting company. They have an annotated history of the entire you know drug development industry. hundreds of millions of document or tens of millions of documents, hundreds of thousands of edits every year and a rich ontology for working of those sort of tens of thousands of ways
04:42 of indexing it. [snorts] Um the automation we built was automating the indexing and the relationships between those documents. So this is processing tens of thousands of new tasks a month when a document's edited or inserted or something changes. We were able to achieve three and a half n of accuracy on the tasks that the business most valued. And I'll talk about what that means in a few minutes.
05:03 Um, this was expensive to build. This was a capex cost. AI engineers aren't cheap. But once it was built, it was cheap to operate. It mostly stayed within its encapsulation. Um, and it was stable. So building this out, our initial approach, I think in 2024, we were excited by 40, we were excited by 03. We did something, maybe we were early for agents, but we built something that's sort of similar to what people would today think of as a research and assignment agent.
05:30 After a few sprints, we hit, you know, 80 83% performance. We were really excited. We had been working in NLP for a decade. We were used to spending months fine-tuning a BERT model to just do one sort of component of one of these pipelines. We compiled a thousand devalves. We went we sat down with the domain experts. Um, I will say one good thing that we did is that we brought the domain experts a whole bunch of examples.
05:52 And um I've worked on other projects where you go to a domain expert, you give them a spreadsheet and you say, "Hey, fill out a 100 evals." That doesn't go well. Uh bringing a blank spreadsheet to a busy expert uh doesn't create momentum. Uh by bringing them all these these these evals, these places we' experienced, we very quickly were able to get a the domain experts on board with what's possible and b get them fixated and interested in the places in which it failed.
06:20 Um I do think that most automations are going to require input with domain experts working on these cases. If you can help them get started with evaluation, but writing evals is an art and it can help get them started more quickly. But experts, we sat down with these eval. What did we find? Well, there was a large bucket of undecided or contentious cases.
06:46 These were tasks where actually two experts might confidently disagree about what the answer is or where the organization itself hadn't quite decided. and everybody was not sure. Mixed in with that sort of heterogeneously was a small bucket of critical errors. These were errors where everybody agreed a misstep would, you know, threaten material accounts.
07:04 We we just couldn't have them. And then mixed in with that was a whole sort of maybe 3 or 5% of exceptions or escalations, places that needed more attention. Uh do a quick example of these three. So the errors pretty straightforward. Even top models, if you have multi-step workflows fail 2 3% of the time. It's annoying when you see it at scale. Sometimes you can't even reproduce it, but it happens.
07:28 For undecided or ambiguous cases, quick example, um, in drug development, uh, drug developers care a lot about targets. These are the, you know, key pathway or molecule that your drug actually impacts. Gout is a disease that's caused by overprouction of interlucan one beta. Culticine is a drug that reduces interlucan one beta by preventing a chain reaction basically.
07:50 uh so colon itself binds to a protein called tubulin. Our system wanted to know does cultureine target interlucan one beta. And if you ask GPT55 sometimes it'll say no and if you ask you know opus 48 sometimes it'll say yes. They actually sort of both go back and forth on this. This is a toy case. It's actually the real situation is a little more complicated but it's representative.
08:11 It gives a sort of flavor of um what undecided cases look like. Uh in terms of unusual or exception, I've got another bio example that I really like. Uh, this is a really exciting new potential drug called Verve 102, possibly cure heart disease, which is like it's pretty cool. I hope to get this or something like it for my little boy when he turns 18.
08:28 Um, this does have a decidable output. We do want to index the sort of six mechanisms of this drug, but the four of them that I've circled here are all actually just new to science. So, like these didn't exist a few years ago. So, in order to properly solve this, we're going to require some human attention. The humans are going to have to think about how to index ontologies.
08:48 This is an escalation path forward. How are we going to handle these three buckets? We need to make sure that errors both get routed into a place where we can grind out high performance and then we need to grind out the performance for exceptions and for undecided cases. We want to route those into places to keep them out of the normal system because they're going to require different types of handling.
09:11 And I think probably in retrospect we spent at least as much time building case routing as we actually did on the final error climbing for the sort of critical set. Is the AI ever confused about what's going on? Is it unusual a case? Abort. Use the AI to describe what's going on. Categorize it away. Skip it from the pipeline. Is it plausibly business critical?
09:29 Okay, then send that to the extremely robustly tested, you know, thousands of evals pipeline. Hopefully you can ship an answer. If through that pipeline it's still not sure, fine. and ship it back to a human as an exception. But vast majority of the time you can ship an answer is it undecided pipeline that out as well. Um for the majority of cases though they didn't fall into any of these cases and we could just ship as usual.
09:58 um in terms of the critical path. So you know we had this this small set of tasks that were absolutely business critical once we took out the ambiguous cases and once we took out the sort of um unusual escalation cases we're able to get to about 95% accuracy with just sort of standard approaches going from 95 to 3 and a half 9s. This is a case of I've got a whole bag of tricks on it.
10:18 It's a case of hill climbing. It's a case of looking at a lot of evals using all of the normal tricks to juice performance out of LLMs. I basically do believe though that if your inputs are well structured and you're looking at a specific set of cases that you've articulated from your business, getting to three and a half nines is possible for most automations.
10:36 Um, [snorts] we deployed this only once a random sample showed that this performance was better than the historic work. This is cool. So, um, I do think specifically um, I'm going to claim that this system performed better than PhD humans at scale. And I'll make that qualifier because I know that a PhD human if they're sitting down on a singular case and they're looking at all the details, they will outperform this system, but not at scale.
10:58 Not when they have to look at hundreds of cases a week, not when they have fatigue, not when if you know one in a thousand times they misclick and not uh you know given time pressure of their other work. Um so full automation is the happy path. Saves you time. That's great. You get better critical business critical task outcomes. That's also great. You know, this is a if you can take the places that are most valuable to the business and grind them out until you're performing better than humans at scale, that's great.
11:24 There's a third benefit here, which is that it organizes the exhaust from the automation in a way that your experts can pay attention to. And I think this is pretty neat. So, back to that expert from the beginning. Hopefully, we've cleared their plate somewhat. We've taken some of the routine work out of their job. In addition, because we've invested so heavily in routing, we've now organized that we can organize their attention in a structured way among the around the remaining cases.
11:47 So they're going to get a pile organized undecided and ambiguous cases, exceptions and unusual cases, and then a small number of critical cases the automation wasn't sure about. For those last ones, the sort of ones that are critical, they can quickly review them, very very few in number, and ship them. [snorts] For the ones that are organizationally ambiguous, this is actually kind of interesting.
12:08 You know, the first thought is maybe this is a way to incentivize the organization to specify. You know, you've got 20% maybe of the total tasks that the organization wasn't sure with these are often one of the reasons that they're not yet fully specified is that they're only marginally valuable. So the alternative here is that you can actually if the expert has a big pile of them in front of them they can actually advocate that hey let's permanently freeze this work let's prioritize it let's not think about it again
12:38 until there's a business case too and let's get it off our plate that is a form of again reducing complexity in an organization having fewer things to think about so the focus and attention can go in the right place [snorts] I think this is even more interesting so groundbreaking work like that verve 102 drug for for heart disease it's only like 3% % of new drug development work.
12:59 The vast majority of drug development work sort of pattern matches. Everybody's familiar with the rough shape of what you're looking at. So an expert might see this once a week, once every other week, one of these cases, they're scattered throughout. Uh the the expert might think, hey, I could build something to handle these cases. But if you're only seeing it sporadically, it's hard to build an intuition for how important it is, how expensive it would be, who would pay for it.
13:20 You start to bucket those. And now the expert can think maybe when they sit down with two or three hours and look at them in aggregate, hey there's patterns here or hey maybe this is the specific investment I propose to start solving these for the organization and then if an an account you know a real customer comes and says hey I have a problem this expert now is ready to figure out how to how to deal with that how to move the business forward on it.
13:42 So we saw this happen organically on a 8 figure account um and the expert had basically by having the data structured had already pre-formed an opinion about where to invest and where to build forward. I think this is actually the case for most scaled business processes. If you're working with the with with the market with data in aggregate you're collecting leading indicators of market demand, right?
14:07 you know, the places that are slightly unusual or the places that um that the market's moving now that they weren't a few years ago, but they look like exceptions and if they're encountered infrequently, it's not enough signal to have somebody think about what to do with them. They're difficult to prioritize if they occur randomly. If you can organize this signal, this exhaust these exceptional cases that don't land in the happy path, your best talent can actually start to think about what to do with it.
14:28 So, quick, we built a full automation. We can save hours. We can improve task level outcomes. We can reduce organizational complexity by taking a big bucket of tasks, encapsulating them, and having nobody have to think about them anymore. And then we can route talent towards higher value problems. This is a form of organizational refactoring. I will say that full automations, especially if you're trying to very high quality output, something like doing a PhD level expert's job, are expensive.
15:01 AI engineers are expensive. Having an AI engineer spend hours reading a spreadsheet of eval is expensive. Once you get to that 95% going from 95 to 99.95, that's an expensive process, etc., etc., etc. Beyond that, you actually have to think if you're going to be refactoring a um a non-engineering process, you're going to have organizational change, trust building, ownership change.
15:22 If you're going to make an investment of this size, hopefully you're also working with your sales and marketing team to figure out how to juice that for revenue, how to increase customer satisfaction, how to expand into a neighboring market. So, this is a major project. Um, thinking about where to do them takes a little bit of of um of judgment. You want to pick a domain that is scaled and that already has material ROI.
15:42 I would actually not propose building full automations if you're a startup, if you're in discovery, if you're looking at new and new businesses. Keep the flexibility of humans. But if you have a bucket of tasks that's associated with seven figures of revenue and that maybe there's a customer ticket, hopefully there's 10 customer tickets, the organization knows that there's pain here, that can justify an investment and that is usually something that a CFO can understand.
16:05 You know, if we say, hey, this is associated with seven figures of revenue and there's five tickets. Customers don't like it or they want something else here. That's a pretty good leading signal. Sort of like in terms of the tasks themselves, look for business processes that are running. ideal if it has written specifications. I wouldn't worry too much about if the written specifications are any good.
16:26 Specifications are really hard and I think that even if there has been momentum to build specifications that reflects that on the inside we the team believes that this is specifiable the team believes that this is not just raw judgment complicated detail orient work now which is actually shockingly shockingly new and very very interesting. It's ideal if this is detail- oriented work because you can take this sort of expensive thought, memory, um, wrote work off of of humans who tend to fail at it at scale.
17:02 Subjective judgment work is not. So that's where you have to draw the line. Uh, AI for like if your business is built around a process, AI to automate that specific differentiated process is still in my opinion um, it's not where the action is. So a bag of tricks here. I'm not going to get into this, but if you are working on something where you're going from 95 to 99.95%, here's a bag of tricks.
17:23 This talk will be online. You can take a photo of this, contact me. I'd love to chat. I'm very interested in the ways that models fail. I feel like knowing where models fail is really interesting for what to build next. Um, but I'd be I'd love to chat about any places where you have clean input, uh, a sort of specified process, and you can't get to three and a half nights of accuracy.
17:41 I think the two that I'll flag out of this is the top one which is read and write evals and the bottom one which is build a thousand evals and expect to spend time reading them. Um that was really one of the big learnings from my team is is everybody had to invest in reading exactly why this time the AI did not do the thing we expected on the emails and it's exhausting work because you're reading psychopantic text and you're trying to figure out what specifically went wrong or against my expectations.
18:08 I'm close with this quote. This is one of my favorite quotes is Rockefeller uh paraphrase as soon as you can hire someone to do your job. Sit down, kick up your feet, think about how to make the company more money. What is he saying here? He's saying if your job is specifiable, get someone else to do it. What we want you to be doing is thinking, applying your judgment, looking for new opportunity.
18:28 I think that's perennial advice. It's great advice. My hope is that AI might be able to help us do this even better. If AI can help route our attention towards the most valuable places, the most valuable opportunities, then maybe we can sit down and actually think about the most valuable things first. Um, my bet is that orchestration layer and and um the right harnesses, the market's going to sort that out and there's not going to be a huge amount of differentiated advantage in terms of picking the right AI
18:58 orchestration software in 2026. My bet is that the companies that succeed the most with AI are going to be the ones who figure out how to best manage their collective attention and judgment because the premium on that is going to only go up at least for so long as human judgment holds a premium. Um that's it for my talk. It's exciting times everyone. Uh I hope everybody enjoys the conference and uh really excited about all the stuff that we're going to be building. >> [music]