AI Agents, Meet Test Driven Development

Hi everybody. My name is Anita, and I'm currently leading Gen AI growth and education here at Vellum. And over the last few years, we've worked with hundreds of companies who have successfully deployed reliable AI solutions in production. From simple to more advanced agentic workflows, one thing became very clear: those companies who have adopted a test-driven development approach were able to build reliable and stronger systems for production.

Today I'm excited to share how you can apply that same approach to build your own effective agentic workflow that actually works. But before we jump in, let's take a step back and truly understand how we got here in the first place.

I'm so excited to get started. Let's do it. So let's go back to 2023. Everyone was building AI wrappers, and most people argued that there is no defensibility strategy around them. And if I ask forward to today, we have Cursor AI, which is the most popular and widely used AI-powered IDE that just hit 100 million ARR in just 12 months.

This is the fastest growing SaaS in the history of SaaS. So why and how did this happen? Because models got better at coding, sure. Because AI adoption skyrocketed, that's absolutely correct. Because coding was an obvious first target that was supposed to be disrupted by these AI models, there is no doubt about that.

But more importantly, we built new techniques and patterns on how we can orchestrate these models to work better, sync better with our data, and then work effectively in production. We rely on these techniques because there are clear limits to model performance.

Hallucinations is still a thing, overfitting is still a problem, and developers needed more structured outputs. And while model providers started to ship better tooling to solve for all of this, we didn't see another leap similar to the leap between GPT-3.5 and GPT-4.

These big jumps started to slow down. And for years, making models bigger and feeding them more data kept making them smarter. But then we hit a wall. No matter how much more data we added, these improvements started to slow down, and models started to reach their limits on existing tasks.

But is this true? Did we really hit that wall? It seems like there were some other avenues and new training methods that we still haven't explored. And so let's see what happened next. So I don't really think that there is an issue here.

Because since then, and this happened in the last 2 to 3 months, we've seen some new training methods that push the field forward. For example, we got the DeepSeek-R1 model, which is the first model that was trained without using any labeled data.

We call this method real reinforcement learning, and this means that this model was able to learn on its own. Reportedly, this is what OpenAI used to train their reasoning models like O1 and O3. And all these reasoning models today, they use chain-of-thought thinking at inference time or at response time to generate their answers, in turn allowing these models to think before they give an answer to our questions.

It enables them to really solve more complex reasoning problems. On top of this, we're seeing all of these model providers to provide more capabilities to their models, like use of tools, more capabilities for research, near-perfect OCR accuracy when it comes to the Gemini 2.0 Flash, and really expand the field forward.

However, traditional benchmarks are so saturated. So people are starting to introduce new ones that will really capture the performance of these new reasoning models. For example, the benchmark that you're currently seeing on the slide here, the Humanities Last Exam, it measures performance on truly difficult tasks.

So if you check the table on the slide, you can clearly see that even the latest very smart models struggle with these challenges. So yeah, models are getting better. The field is moving forward. But for an AI product that actually works in production, success isn't just about the models anymore.

It's about how you build around it. And that's exactly what's been evolving in parallel to model training. So we were learning how to prompt all of these models better. And we developed more advanced techniques like chain-of-thought. Then we thought that we should be able to ground all of these models' responses using our own data.

So RAG became an important part of our workflows. Then we learned that for multi-threaded conversations, memory is going to be the most important thing that we've had. Long context from the latest models enabled new use cases. Then we started to think about hierarchy of our responses.

So we started to experiment with GraphRAG. And then just lately, we're thinking about using all these reasoning models that, in fact, will take a lot more time to think in real time. However, it also develops new areas and use cases that we can develop.

And lately, we're thinking about agentic RAG, making our workflows even more powerful so that all this can work on its own. And the field is still evolving. But even using these techniques isn't enough. You need to understand your problem deeply and take a test-driven development approach to find theright mix of techniques, models, and logic that will actually work for your use case.

And this actually brings me to the main first topic of this presentation: test-driven development for building reliable AI products. Because the best AI teams that I've seen follow this structured approach. They start to experiment, then they evaluate at scale, then finally when they deploy in production, they never stop working on their workflow.

They capture all of those responses to then continuously monitor, observe, and improve their product for their customers. Let's look at what you can do at every stage of this process. Before you build anything production-grade, you need to experiment a lot.

You need to prove what these AI models can actually solve for your use case. So you should try different prompting techniques. For example, few-shot or chain-of-thought. Some of these will work great for simple tasks, and others will help with a bit more complex reasoning.

You should test various techniques. Prompt chaining is usually very well received because it's going to work better if you split your instructions in multiple prompts. Or you can adopt more agentic workflows like React that will have a stage to plan and then reason and refine before it actually gives you an answer.

What is really an important part in this stage is that you need to involve your domain experts. Because engineers shouldn't be the ones who are tweaking prompts. And bringing all these experts will actually save a lot of your engineering time.

Because once you do this phaseright, then you will actually have proof that this works and that engineering time needs to be involved. At this stage, you should also stay model agnostic. You should incorporate and test different models. And especially when it comes to your use case, you need to think about which models can do the job better.

So in such case, you can maybe use some different models like Gemini 2.0 Flash, which is actually really well at OCR and something that we've seen work really well lately. So let's say that at this stage, you know that these AI models can actually work.

You have a few examples that these models have really good performance on. But how can you test whether this will actually work in production when you will potentially have hundreds, if not thousands, or millions of requests per minute?

And so this is where evolution comes in. In this stage, you actually create a data set of hundreds of examples that you're going to test your models and workflows against. And so at this stage, you need to try to balance quality and cost and latency and privacy.

And you're definitely going to make a lot of trade-offs. Because no AI system is going to get all of this perfectly. But for example, if you need high quality, maybe you can sacrifice speed. If cost is critical, you might need some lighter and cheaper model.

And this is the stage where you need to define your priorities. Because it's always better if you define your priorities earlier in the process. You should use ground-through data where possible. If you want to evaluate all these workflows, having your subject matter experts design these databases and test these models and workflows against is going to be very, very useful.

Synthetic benchmarks help. However, they will not really evaluate these models for your own use case. So it's usually very, very powerful if you can use your ground-through data. But don't worry. Even if you do not have ground-through data, you can use an LLM to evaluate another model's response.

This is actually a very standard and reliable way when it comes to evaluating your models. Very importantly at this stage, you should make sure that you're using a flexible testing framework. No matter if you're building this in-house or if you're using any external service, your AI isn't static.

So your workflow should also be dynamic. It should be able to capture all of these different non-deterministic responses. You need to be able to define custom metrics. You need to be able to write those metrics using Python or TypeScript.

So you shouldn't be looking at a very strict framework. Customizability is a very big thing here. And then finally, you should run evaluations at every stage. You should have guardrails that will check internal notes and whether these models are actually producing responses at every step in your workflow.

Actually producing responses that are correct at every step in your workflow. And then you should also test while you're prototyping. But then you should also utilize this evaluation phase to come back once you have some real data. But how are you going to get some real data?

So let's say that you evaluate your workflows extensively with your subject matter experts, with your data that they've created. And let's say that you're now satisfied with the product that you have. So you're ready to deploy it in production.

So once that happens, what do you need to do? Is your job done here? When it comes to AI development, you need to monitor more things than deterministic outputs. You need to log all LLM calls. You need to track all of those inputs and outputs and the latency.

Because AI models, they're really, really unpredictable. So you need to be able to debug issues and understand how your AI behaves at every step of the way. And this is becoming extremely more important with agentic workflows. Because agentic workflows are more complex workflows that can take different paths in your workflow and make decisions on their own.

You should also handle API reliability. You need to maintain stability in your API calls. You need to have retries. You need to have fallback logic to prevent outages. For example, two months ago, OpenAI had four hours of downtime.

So if you had a fallback logic in your productionized solution, then your AI will know to go back to another model and use another model instead. You should definitely have version control in staging. And you should always deploy in controlled environments before you roll out to the wider public.

Because when it comes to AI, you need to be careful that once you update a prompt, you're not introducing a regression to another prompt or part of your workflow. So you need to ensure that all these new updates, they won't break whatever you have in production.

And the most important part here is that make sure to decouple your deployments from your scheduled app deployment schedule. Because the chances are that you will need to update your AI features more frequently than you will need to update your app as a whole.

So make sure to do that. And so let's say that now you have deployed. You're starting to capture all of your responses from your users and create a feedback loop to identify edge cases that you capture in production to then continuously improve and make your workflow better.

You can capture all of these, then run evaluations again and test whether new prompts that you develop will solve for these new cases. You should also think about building a caching layer. Because if your system is handling some repeat queries, caching can drastically reduce costs and improve latency.

So for example, instead of calling an expensive LLM for the same request multiple times, you can store and serve frequent responses instantly. And this is something that is a standard these days when it comes to building with AI.

And finally, let's say that your product has been running reliably in production for a longer period of time, a time that you feel comfortable to then go back to that data and use it to fine-tune a custom model that will basically create better responses for your specific use case, can reduce reliance on API calls, and in fact, can work with lower costs.

And so this process is becoming even more important than ever when it comes with agentic workflows. Because these workflows are going to use a wide range of tools. They will call different APIs. They will have multi-agent structures that will execute a lot of things in parallel.

So when it comes to evaluation with agentic workflows and with this test-driven approach, it's not just about measuring performance at every step in your workflow. Because you also need to assess the behavior of these agents so that you can make sure that they're making theright decisions and following the intended logic.

And this year, more than ever, everyone is talking about agentic workflows. But what does that actually mean? I would love to talk more about how you can build all these agentic workflows. But I'm not here to give you the perfect definition of what an AI agent is.

And instead, I'm going to try to define different agentic behaviors and some different levels on how they can be built. So if you think about it, every AI workflow has some level of an agentic behavior in it. It's just a question of how much control, reasoning, and autonomy it has.

So we've looked at the past, the present, and where we're headed. And from that, we put together this framework where we define four or five different levels of agentic behavior. I'll go into more details on each level. But keep in mind that this is not a final framework.

It's not set in stone. As models evolve, this can expand. Things can blur. And a lot of things can shift. But for now, this will give us a way to define where we are today and what we expect to see next.

At this stage, you have an LLM call. You retrieve some data from your vector database. And then you might have some inline evals. And finally, you're going to get some response from this workflow. So you can notice that in this workflow, there is no reasoning, planning, or decision-making beyond what's baked into the prompt and the model behavior.

So the model is doing all the reasoning here within the prompt itself. And so there is no external agentic organizing the decisions or planning some actions. However, there is some reasoning and some agentic behavior at the model's level.

And so if we move from L0 to L1, we can see that in this stage, our workflows can now use a lot of tools. And so this AI system is no longer just calling APIs. It now knows when to call them and when to make those actions.

And so this is where we start to see more agentic behavior. Because the model can decide whether it will call a specific tool or whether it will call our vector database to retrieve more data before it actually generates an output.

Memory here starts to play a key role. Because we're going to have multi-threaded conversations. And then all of this will potentially happen in parallel. So we need to capture all context throughout the whole workflow. Evaluation is also needed at every step of the way here.

Because we need to ensure that these models are making theright decisions, using theright tools, and returning accurate responses. But these workflows can be as simple as on the slideright here, or even more complicated, where you're going to have more different branching happens at every stage in this workflow, where you can have 10 different tools.

And the agent needs to reason whether it's going to call the first five or the last two. And so this is where, again, we see a lot more agentic behavior. But L2 is where we actually see that these workflows now move from simple tool use, which is not in many cases, it's not a simple tool use.

The previous workflows can be very complex. But now we see some structured reasoning. This workflow will notice triggers. It can plan actions. And it can execute tasks in a structured sequence. So this means that it can break down a task into multiple steps.

It can retrieve some information. It can decide to call another tool. It can evaluate its usefulness if it thinks that it needs to be refined at that stage. And once it does this in a continuous loop, it can generate the final output.

But you can notice that agentic behavior here starts to look more intentional. Because the system isn't just calling the tools that are listed for their use. It's also actively deciding what needs to be done and spending more time to think what needs to be done instead of just deciding whether a tool should be called.

And so at this stage, one part is that the process is still finite. So once this workflow completes the steps as it plans to complete them, it will terminate rather than it will run continuously. But it's a leap forward from just calling tools.

And so L3, however, is where we see more autonomy, where we see more decision-making that are not

defined by us as the creators of these workflows. So the L4 system can proactively take actions without waiting for direct input. So instead of responding to a single request and then terminating, this one will stay alive and will continuously monitor its environment.

And it will react as needed. So for example, this means that it can look at your email, Slack, Google Drive, or any other tool, external services actually, that you can give access to. And it can plan its next moves, whether it will execute actions in real time or ask the human for more input.

And so this is where our AI workflows become less of a tool and more of an independent system that we can use to truly make our work easier. So for example, this one can be like a marketer that will prepare this video or a presentation that you can just take and use whenever you want.

However, the final stage is where we're going to have a fully creative workflow. And so at L4, the AI moves beyond automation and reasoning. And it becomes an inventor. So instead of just executing predefined tasks or just reasoning within some bounds, it can create its own new workflows.

So it can create its own utilities, whether it's agents, prompts, function calls, tools that it needs to be designed. It will solve problems in novel ways. So while true L4right now is definitely out of reach, because there are some constraints with models like overfitting, because models, they really love their training data.

And there are some issues with inductive bias where models will make assumptions, again, based on their training data. This makes to be like a very hard task today. But that's the goal. AI that doesn't just follow instructions, but will invent, it will improve, and it will solve problems in ways we didn't even think of before.

So I would say that L1 is where we're seeing a lot of production-grade solutions. So at Vellum, we've worked with companies like Redfin, Drata, and Headspace, all of which have deployed production-grade AI solutions that fall within the L1 segment.

And again, just using tools, it can be very simple or it can be a very complex workflow. The focus is, though, on orchestrations. How do we turn our models to interact with our system better? How do we make our models to work with our data better?

How do we make sure that whatever we retrieve from our vector databases is theright and correct context for the question that the user is asking? And so we're experimenting with different modalities and all of those techniques that we mentioned before.

And test-driven development truly makes its case here. Because you need to hack different tools and models. And you need to be able to continuously improve on them to build not only a more efficient system, but a system that will work continuously better and better.

However, L2 is where I think we're going to see most innovation happen this year. And this is where we're going to have a lot of AI agents that are being developed to plan and reason using models like O1 or O3 or DeepSeek.

We might see a bunch of different use cases. We might see a lot of innovations when it comes to the UI and the UX part of the system, where we will definitely create some new experiences for our users.

And essentially, this will be a way for us to make true reasoners that will handle complex tasks. So you're going to have a bunch of these agents just working for you, doing different things. However, L3 and L4, they're still both limited by the models today, as well as the surrounding logic.

However, that doesn't mean that there's a lot of innovation happening within those two as well. So if you want to learn more about how to build your own AI agent, I've included everything that I've shared in this presentation and more.

For example, architectures that you can build, what are the stages that you can test, and similar things like that. We also feature top researchers and professionals who have shared all of their learnings on how to build this for production.

So feel free to scan this QR code on the screen to download this resource. So now I think it's time to get more practical. I want to show you how I built my own SEO agent. This specific agent automates my whole SEO process, from keyword research to content analysis, and finally for content creation.

It decides whether to use tools and has an embedded evaluator that works in an editor to tell the agent if it's doing a good job. Let's see a quick sketch of how this agent works. So in a minute, I'm going to show you a real demo on how this agent actually works.

However, I wanted to give you a high-level overview on what are the steps that this workflow will take. And so when you look at the sketch on the screenright now, you're going to notice that this workflow lies between L1 and L2 type of agentic workflow.

You have the SEO analyst and the researcher who will take a keyword, and it will call Google Search. And it will analyze the top-performing articles for that keyword. One, it will identify some of the good parts within these articles that we also need to amplify in our own article.

But it will also identify some missing segments or areas of improvement that we should definitely write about to make sure that our article is actually performing better than the ones that we're competing against. And then after the research and planning is done, the writer has everything it needs to start writing the first draft.

Then the first draft is passed to the editor, which is an LLM-based judge that will evaluate whether the first draft is good enough based on predefined rules that we've set in its prompt. Then that feedback is passed back to the writer.

And this will loop continuously until some criteria is met. Within this loop, we also have a memory component that will capture all previous conversations between the writer and the editor. And finally, we're going to get a final article that's actually a very useful piece of content, that it's not AI-generated and not useful, but truly using all of this context in a smart way, enabling me to have a pretty impressive first draft to work with.

So now let's see the demo. For the sake of time, I'm going to start running this workflow as I explain what this agent does at every step in the workflow. So we ran this workflow with the keyword chain-of-thought prompting.

And so the SEO analyst currently is taking that keyword, is taking some other parameters like my writing style, like the audience that we're trying to cater to. And it analyzes the top articles that Google is ranking for that specific keywords.

It tries to identify some good components from those articles that we need to reinforce in our article. But it also identifies some missing opportunities where the researcher is going to utilize those to then make another search and capture more data to make our article be better than the articles that we just analyzed.

So now that the SEO analyst is done with its job, the researcher tries to capture more information about the things that were previously identified as missing pieces to the puzzle. And then the writer will take a lot of this information in its input.

And it will try to create a great first draft using that data as context. So the content here that will be generated by the writer, it's not going to be like a slop type of article. It's not going to be something that is really not useful.

It's going to actually use all the context that we're sending from different articles that we just analyzed. You can also connect your RAG here that it will look into your database of articles and learnings. And it can really create something that's extremely useful.

Now the editor says, "OK, this is a good enough article. But here's some feedback." And so it passes the feedback through the memory component here, which is a chat history between these two, and then this node that basically structures that input.

For the sake of this demo, the conditional here for the loop is that this loop will break if the evaluator actually tells us that this is an excellent post, which actually rarely happens. So we also said that if the loop runs for at least one time, this loop will break.

And so it already ran for one time. We got still more feedback from the editor. But in this case, for this demo, let's look at the output that we got. So mastering chain-of-thought prompting in AI, a comprehensive guide for developers.

I think it's pretty OK, pretty nice. I might change the title. But I know that the components in this article are the actual components that other articles are writing about. And so this was great. The latency was around 118.

This usually takes around 300 seconds to run when we have more evaluation loops. But it's pretty great. It gives me some foundations on how I can continue to build on this content. And it saves me a lot of my time.

So the product that I just used is called Vellum Workflows. And it was designed to bridge the gap between the product and engineering teams so they can speed up AI development while still following this test-driven approach that we talked so much about in this presentation.

However, one thing became clear. Developers want more code. Developers want more control and flexibility. And they want to own their definitions in their codebase. So today, I'm excited to introduce our workflows SDK. It provides all the building blocks you need.

It's infinitely customizable. And it has a self-documenting syntax where you can actually spot how this agent is workingright in your code. It's also expressive enough so that you can understand what's happening at every stage in your code. The best part is that the UI and the code stay in sync.

So whether you're defining debugging or improving your workflows, everyone on your team can stay aligned. I hope that you like it. It's open source and free. And you can check it out on GitHub. Feel free to scan this QR code to check out the repo.

And that's a wrap. Thank you so much for listening. And I hope that today you learned something new. If you want to talk more about AI, feel free to scan this QR code on the screen to connect on LinkedIn.

Or if you have any questions, feel free to send me a text message on my email or on Twitter. I'm going to follow up for sure.