Feedback Loops for Agentic Workflows

Key Takeaways

Uh it is now my pleasure to announce our second speaker Tudor who is a CTO at Enverai uh where he works on finding better ways to build software by blending the lines between research infrastructure data and business logic. Please join me in welcoming Tutor. [applause] All right, everyone. So, uh, we have to match the Hard Rock Cafe vibes, right? Feels like we need to start actually with a strong guitar riff, but >> Freeird. >> Freeird. There we go. Oh, man. I would love that. So, um, getting a bit to the topic at hand. Um, just want to double check, uh, everyone can hear me well, right? All right, perfect. Uh, so let's rock. First, let's get to know each other a bit. Uh raise your hand if you have manually within uh with your favorite keyboard written more than a 100 lines of code in the last two months. Raise your hand. All right. Uh more than 100 lines more or less by hand, you know, click clack keyboard. All right. Oh, where were the hands? Keep them up. Keep them up. Keep them up. All right. Uh and finally, no judgment one way or the other. Keep your hand up if you enjoyed the process. And if you didn't, put your hand down. All right. Interesting. Of course, numbers of words per minute is a silly metric. Deciding how to spend your time is not. So, I'm confident we all we all know this to to a certain degree. Cool. So, I get a sense of your experience. Uh, a bit about myself. Um, I like interesting and cross-disciplinary problem spaces. Most times this labels me as an engineer. I've sort of accepted this label for almost 20 years now. Uh, co-founded five companies, had one exit. Um, it is a humbling experience. Um, when uh when I'm not starting a company, I contracted for companies within renewable energy, insure tech, and media. Some of the locals might recognize these logos. and my focus is on optimizing for learning. So let's do a bit of learning together. So the topic at hand, I was the CTO at boto.io uh a no code automation platform for blockchains. We had a bit over 20,000 users uh a seed round of 3.7 million and most importantly more than 10 million workflow runs per month. My team and I have moved away from BTO a bit over a year ago, but we carried a lot of the lessons uh through. At BTO, we had all sorts of creative uh workflows what we currently have agentic workflows implemented by various people. Some were simple, some were complex, others were borderline insane. Some of you might be familiar with this type of visual programming from tools like uh Nathan. So, similar to Nathan, people have dragged and dropped various types of nodes with uh various data sources and behavior. Some were short and sweet like this one here. Others were mad, a true test of patience. And one small subset had some galaxy brain type of ideas. We called this one the brain, although it was not the worst. Uh some had more than 200 nodes and broke the entire rendering canvas. So we couldn't even see them. Uh the brain baffled me. Um hundreds of nodes manually added. How do you keep track of them all? Each was dragged and dropped. Uh each can fail. And um at this point, the maintainer was closer to a plumber than a software engineer. When seeing it, I had all sorts of questions. Um how do you know if the word nodes are working individually? How do you know if the nodes are working together? How do you close the feedback loop? There must be a better way, right? Let's settle on a few definitions before moving forward. So, feedback loops, a cycle where the output of a system is used to improve the inputs and most importantly improve the system itself. I'm using system in a broad sense here. could be an application or service but also could be as generic as your whole business. U and you have the liberty to define what improve means. Some of you might know the high level and generic terminology from complex adaptive systems. Uh, one of my favorite examples of uh, feedback loops uh, relevant to the current uh, scene uh, are reinforcement learning techniques uh, mostly because they have clear inputs uh, clear execution and with uh, a reward in sight self-improvement is possible through iterative uh, exploration. And finally inputs. Inputs are all factors and data sources pertinent to the system. For example, thirdparty APIs, any data sets we can collect, MCPS, LLMs, quant satellite tracking of Elon's airplane travel to predict Tesla stock price stuff [snorts] in the right format. Everything is is an input. Now, without complete context, we have the opposite of intelligence. Uh and I think this is relevant to what Reddis Simba was around here talking about uh gathering all that context. Um one beautiful aspect of the way we operate as as humans uh we actually often deal with incomplete context. We more often play poker than chess. How did we not only survive but thrive for millions of years? We are a living example of a system that is constantly improving itself. The tighter the feedback loop, the better the system. Brilliant. So I'll explain uh and maybe ground a bit feedback loops in the context of agentic workflows. A sort of to Nathan or not to Nathan. Um a good feedback loop is uh or has three essential properties. First, it's actually closed. The output goes back in the input creating a continuous improvement. Second, it has complete context. Um all the relevant data sources your system needs are there. Uh and third, and this is critical, you can actually see what is happening. You can debug it. You know if node A is broken, you know if node A and B work together but fail when node uh C joins the party. >> [snorts] >> So what makes a bad feedback loop? Some characteristics are simple opposites of the previous ones. Others are not. For example, if the loop is enclosed, you aren't learning from the outputs. If it's a black box, you can't see what's broken. Um, so it's potentially fragile. Uh, and you're operating on incomplete context. And remember the brain I mentioned a bit earlier? That's what happens when all of these three go wrong at once. We end up as a plumber looking for leaks uh instead of an engineer reasoning and uh building a system. To be honest, everyone dreaded touching the brain. Now, good feedback loops lead to better agents because they're observable. You can debug their behavior. You can catch mistakes early. you can uh or and good feedback loops also have a closed loop. Um agents learn from their outputs and the com context is as complete as possible. U better decisions uh be it to calling out to tools like NCPs or making requests to APIs. So why does this matter for AI agents? Because agents need the same three properties. If you can't observe what your agent is doing, you can't fix when it hallucinates or makes unexpected decisions. If the loop uh isn't closed, your agent repeats the same mistakes continuously and it's not learning. And if you don't give it complete context, so again the right MCPs, APIs and data sources, decisions are made blind and feedback loops can be nodes in par feedback loops. Nesting sort of evolves naturally. Nathan allows subworkflow execution uh which is quite neat. Um and as you might predict this can get complicated fast. When are the limits of maintainability reached? When does uh our understanding of the inner workings uh stop? So feedback loops are in place. They chug along. How do we know they are healthy? You can't really improve what you're not measuring, right? Let's talk about some of the vital signs of these feedback loops. So, speed metrics first. Uh loop completion time tells you if your system is responsive enough. Uh if it takes 5 minutes for a cycle uh to to feedback, it's not iterating fast enough. Um then time to detection. How quickly do you know something uh breaks or goes astray? Is it minutes? Is it hours? Is it days? [snorts] Uh the faster you detect it, the the less damage done. Another category is quality metrics. Uh these tell you if your agent is actually getting better. Uh error rate per component helps you find uh weak links. At BTO, we tracked which nodes in workflows failed most often. Um, and uh, human override rates. These are these are important and quite fascinating because if humans are constantly rejecting your agent what your agent suggests, your agent again isn't learning the right thing. Uh, and finally, um, accuracy drift. This is important. Watch it carefully. Uh, agents can degrade over time. even if you haven't changed anything as the world around them changes. And finally, system health. Uh context completeness asks, are you feeding your agents uh everything it need? Uh and observability. Uh this is non-negotiable for any decision your agent makes. You should be able to pull up the full reasoning chain. If you can't explain it, you can't fix it when it breaks. And you know what's beautiful here? All these metrics form their own feedback loop. You measure, you improve, you measure. Again, the difference is that uh you as the designer of the loop uh are the moderator. Let's talk about mistakes. Let's get into war stories. Mistakes I've seen and made myself. So antiattern one, set it and forget it. You deploy an agent. It works great for two weeks, then performance quietly degrades and you don't notice it until a customer complaints. I've seen this kill products and the fix. Treat your agents like you treat any production system. Daily metric reviews, automated alerts when things go a drift, and you wouldn't deploy a web service and never never check if it uh actually is up, right? Same principle. Antiattern two, the everything agent. Someone builds one agent that handles customer inquiries, writes code, schedules meetings, and orders lunch. It's mediocre at everything. And the fix, decomposition. Build specialized agents. One handles customer support, another handlesing. And they're good at one thing. Then you can orchestrate them all. And Three, the feedback soup. This is one of my favorites. Everything the agent outputs gets fed back in. And I mean everything. Every log line, every intermediate results, every uh debug message, the agent drowns in its own output. And the fix is to be explicit about the feedback schema. Uh for example, we feedback customer satisfaction scores and error logs. And that's it. Less is more here. And the big one, blackbox optimization. We'll just uh use reinforcement learning and the model will figure it out. No, no, we won't. You need explicit reward functions, clear success criteria, good and bad, uh need definitions. Otherwise, you get agents optimizing for the wrong thing, and you won't know until it's too late. So the common ground, these agents all violate the principles uh I talked about earlier. They're either not observable, not closed properly, or missing context. Avoid these and you're ahead of uh 80% of the agent implementations out there. [snorts] Now most of the workflows I've talked about, including Nathan, have a codified representation. For for Nathan, these are JSON files. Uh this example might not be readable, but it's it's a JSON representation of a workflow built in the in the web GUI. Uh there are a ton of such examples on on GitHub. Most LLMs are fairly decent at parsing JSON. So why not chuck it all in? Uh put a big long prompt and let the LLMs do the heavy lifting. Uh applying the good, the bad, and the ugly. That's one idea. What if there's another alternative? Uh past a certain point, the visual language becomes too verbose. Sometimes we got uh we get too stuck in the metaphor of graphs with nodes and edges. Beyond this tipping point, we must swap the type system, schema and grammar of nodes and edges to a formal language. Maybe a programming language or a scripting language. I loved the example from Simba from uh with Python. Uh a succinct and formal way to express the workflow potentially using frameworks like Airflow, Prefect, Lang Chain if a narrower scope is is needed and I feel like I should add the Reddis logo with what they're doing recently. Where is the tipping point though? When would you choose a visual language over a formal language? Right. So warning, we're entering the experimental zone. I've been working on a way to measure this tipping point. It's called clad, not the catch's name, I know, hence the work in progress. It's the big logo there. But C for complexity, so represents the number of nodes in a workflow. Logic or flow control represents the number of conditional statements in the workflow. If this then that, forks in logic, fan in, fan out. API integrations represent the number of external um providers used in the workflow. Requests to LLM or other model providers fall within this category. And data requirements refers to the amount of data flowing through the uh through the flow as well as the amount of manipulation on the data required changing schema merging extracting and so forth. There we have it cloud. Let's look at a m matrix breaking down some of these dimensions uh along with some examples. An easy start. Complexity is low maybe less than 10 nodes. logic is relatively linear uh with a handful of forks in it at most. U API integrations are minimal maybe third-party data sources maybe or maybe one third party data source and maybe a model provider data doesn't need much adjustment uh or or reshaping. An example scenario would be maybe a simple data sync between uh two services and a solution fairly appropriate would be uh um Nathan workflow and let's shift gears a bit more nodes maybe in the low tens introduce a few more conditional branches more if then then if this then that scenarios maybe a system model provider with another one acting as a judge By this point, the data flowing through the system requires more reshaping, merging, or extracting. An example scenario is an e-commerce order processing system. What do you think? Would the no code solution be enough? Any guesses? Any nods? No. Maybe. I see some hesitation. Um, we're getting to the limit, but your team might get away with it. And one more gear. We're in red territory where whether by design or by accident nodes in the high tens or low hundreds logic branches and cases to handle um the control flow require some serious understanding. Um third party providers become uh the main source of truth. LLMs validate other LLMs or complement each other um in various specialties and data changes are a lot more often. transformation algorithms uh require optimization. One example scenario is an advanced pricing engine. Back to the question, are we still in no code territory? What do you think? Experience should tell us no. Would be brilliant to take a step back at this moment and reflect upon upon our decisions. All right. This uh this covers the whole spectrum on of dimensions in the clad framework and hopefully this answers the question to Nathan or not to Nathan obviously as a metaphor for the decision point and if uh Shakespeare's piercing gaze doesn't make you ponder nothing it nothing does he's looking in your soul. So to recap uh what have I covered tonight? Good feedback loops have a closed loop. So outcomes feed back in the into inputs resulting in continuous improvements. Complete context or as complete as possible. For my math nerds, this is like an asmtote that doesn't really touch the line. Uh and it is observable. You can debug individual components as well as the whole system. And I've given uh a taste of the clad framework, a method to decide how to implement agentic flows. If you take a photo of any slide, this is the one. Uh use it as a checklist to guide your your design process. And in closing, what I didn't tell you, these slides were implemented in a plain plain Python file u using the Marimo notebook format. All the material can become a feedback loop on its own which improves itself uh as I collect feedback from various uh various people. And this QR code should link to the repo uh clone it and play around. And by the way, this is a notebook and it also has an MCP uh or NCP endpoints by default without any extra coding. And [snorts] just to wrap it up, all these workflows and models must run in an environment on some sort of compute platform. Either you have an on-prem cluster or in someone else's cloud. With this in mind, what are your current challenges? Is access to compute actually blocking you or is it something else? I'd love to hear your thoughts about uh this last topic uh later on or via LinkedIn. Cheers. >> [applause]