One of the top questions on the lips of teams building AI agents is ‘when is it ready to go live?’ It’s no wonder this is a concern because most businesses are making go-live decisions based on vibes. They don’t have any evidence to point to that says ‘this is ready’. No structured testing. Nothing that describes what this thing should do and whether or not it’s consistently doing it.
To improve the reliability of our agents, we actually need to change the way we approach building them.
Test-driven development (TDD)
Test-driven development can be traced all the way back to 1957, where operators of the old punch card computers would write their expected input/output taps before running programs. It was popularised by Kent Beck as part of the Extreme Programming (XP) agile trend culminating in his book Test Driven Development: By Example in 2002.
What is Test Driven Development?
TDD is an engineering practice wherein you define your test cases, and the expected results of the software first, before you build it. You then build the software with the sole purpose of passing the test.
Traditionally, tests are written after the code is written in an effort to test the code. The problem is that this is built on the assumption that the sum of the code is a feature that’s needed and contains all of the necessary requirements. Writing your tests first is essentially an exercise in properly defining your requirements.
Why is Test Driven Development a good fit for AI agents?
TDD works well when designing AI agents because it solves one of the biggest gaps today: what should this thing do and how should it work? Rather than throwing data at a model, it forces you to think about the end-user interaction and the purpose of the agent. It forces you to consider what good looks like. What would a completed, successful interaction mean? And how would it be measured?
At the same time, it forces you to think about what you should do when things go wrong. What if a tool call fails? What if an API doesn’t work? What if the user is being difficult or is in a unique, long tail situation?
Thinking about all of this ahead of time before you worry about simply building it for the sake of building it gives you a few crucial ingredients:
- A definition of success. Measuring the impact of AI is a challenge, as is measuring whether users achieve their desired outcomes. This allows you to bottom this out and have target outcome. Also, if you’ve done the right thing, you can put a financial or other KPI on the successful resolution of the agent and draw a straight line back to business impact.
- The foundations of your prompt. Once you’ve thought deeply about what the agent would need to do to pass your test, you’ve pretty much nailed everything the agent should do. You have all of the foundation material to build your initial prompt. OpenAI actually take their evals (that they write first) and then use AI to build the prompt off the back of it (Voices of Voice AI podcast). (We’ve had mixed results with completely automated prompts, but that’s the way it’s going.)
How does TDD for AI agents work?
The process is fairly straightforwards.
- Write your test cases (evals).
- Build your prompt from that material (with AI assistance or without).
- Run automated testing to generate a baseline performance yardstick.
- Iterate the prompt based on the test results (what needs to change to pass the test?).
- Run step 3 and 4 until the test case successfully passes consistently (10+ consecutive passes).
Once you’ve reached step 5, you’re ready to progress either to proof of concept, beta or live, depending on where you are in your project.
This is how you to answer the question ‘when can we go live?’
And you don’t have to build your entire application. You can apply this methodology in increments, one agent, sub-agent or even one specific feature of an agent or sub-agent at a time.
And the great thing about that is that each time you build a new feature, and it consistently passes your eval, you can regression test the whole application to make sure this feature hasn’t impacted previously cleared features.
What problems does TDD solve?
Today, so many AI teams are caught up in the AI whirlwind and have the belief that all they need is data and a model. Pass an AI model your data and some simple instruction and you’ll be fine.
In practice, that makes quality assurance and reliability a nightmare. It leaves you with an application who’s scope is as wide as your data allows for. Where do you start with testing that?
And when you do start testing it, you realise that it’s all over the place. It does some things OK, others inconsistently and some not at all. You then end up in this constant prompt-test cycle. You fix one thing but you have no idea whether something else has regressed. You’re chasing your tail forever. I spoke with a telco recently that’s spending a week and a half regression testing after each new iteration.
The reason why you find it not doing what you want it to do is because you haven’t told it what you want it to do properly. You haven’t thought about your requirements enough to build your prompt. You’ve done just enough to build something and you’re learning new requirements as you test it.
In principle, you could call that agile. But working out what you should be testing once you’ve built the thing isn’t agile at all. It’s just a good way of wasting time and making sure you stay in this uncertain loop of anxiety.
In the end, you go live with a feeling. A feeling that it’s probably OK. As long as we review a sample of transcripts, we’ll be fine.
Maybe you will be. Maybe you won’t.
The reality is that you’ll never really know until something really bad happens. Otherwise, you trundle along with average results, never fully reaching the ceiling of what’s possible.
This happens across the CX landscape, which is one of the reasons that zero businesses have demonstrated enterprise-wide results from their AI programs.
This isn’t a technology problem, it’s a methodology problem.
What do I need to run TDD for AI agents in my company?
To adopt this process and start building reliable AI agents in your company today, it’s pretty simple. There are a few things you’ll need in place:
- An owner of the eval test set. Someone to define your test cases and own the process.
- An AI agent testing platform (the last thing you want to be doing is all of this testing manually). We use Hangar5.
- Your whole team bought-in and committed to the process (no cutting corners or circumnavigation).rel
If you can develop a culture of TDD, you’ll be bringing much needed rigour into the AI agent lifecycle, and making sure that your agents are built, from the beginning, to be reliable and consistent.
If you’re interested in learning more, check out the webinar we did recently where we dive into the methodology and the practicalities of automated AI agent testing.
