Introduction

You have seen it too, absolutely everything seems to become agentic…
Marketing is certainly doing its part, but not only. With so many offerings out there, there might be some demand, right?

It’s no secret that an arms race is taking place between tech giants to develop and sell Agentic solutions. Likewise, consulting firms are competing to implement them while more and more companies of all sizes are seeing the benefits they can bring, at least in principle.

All these platitudes being said, it got me curious. What exactly makes an application “agentic”? What’s new, and what does it bring to the table? And for us developers, how to keep up with what seems to be the future of software development?
So I decided to give it a try and to document the process in the way. It’s a good opportunity for me to start writing (like many of us, I meant to do it for years I but never got started) and also a great learning adventure as it connects multiple disciplines together.

While I am somehow familiar with the topic as a Data & AI professional, I recently realised how shallow my understanding of LLM and AI in general is. The fact that this topic evolves so quickly, seemingly daily, and get such a high amount of hype makes it quite intimidating for someone curious but not directly involved in the field.

It was certainly my case and I’ll assume that it’s yours too. I’ll do my best to keep it simple and to share my findings with as little non-sense as possible. As I found out, there’s very little magic involved in building an AI Agent but nevertheless the results are extremely satisfying.
We’ll do a bit of everything here, infrastructure, code, data and testing, at a basic level. I pretty much started from zero so hopefully anyone can follow quite easily. If you have any question, please feel free to reach out.

Remember that it’s just my modest learning adventure about a very, very interesting topic. I may sound sceptical at times but I truly believe that language models are an extraordinary advancement and that there is plenty more to come.

What Makes an Application “Agentic”?

Let’s start with some definitions:

AI agents are designed to perform specific tasks, answer questions, and automate processes for users.
— Microsoft¹

This quote from Microsoft describes what we will be building in this series – It’s small in scope and down to earth. It’s a simple AI agent that can become the building block of an “agentic” application.

Agentic AI uses sophisticated reasoning and iterative planning to autonomously solve complex, multi-step problems.
— NVIDIA²

Then this quote from NVIDIA hints at something bigger. We are no longer limited to a small, precise task. Reason and autonomy are mentioned here, we could imagine multiple agents working together to solve a more complex problem, potentially evaluating their own work, and adapting their strategy.

Agentic AI systems—AI systems that can pursue complex goals with limited direct supervision—are likely to be broadly useful if we can integrate them responsibly into our society.
— OpenAI³

Finally, the OpenAI quote elevates it further, this time giving them a role in our society. It may sound grandiloquent or premature, but it’s undoubtedly the shape of things to come.

I like these definitions because they hint at what an agent is, but also at how it can be used as part of something bigger.
There are of course plenty of definitions around, but something to address is the difference between an AI Agent and Agentic AI:

It’s important to differentiate between agentic AI and AI agents. Essentially, agentic AI is the framework; AI agents are the building blocks within the framework.
— IBM⁴

This definition certainly makes sense and is worth keeping in mind. I will complete it with one of my own quotes (mostly as a joke):

Sell Agentic AI, implement AI agents.

Indeed, Agentic AI as a concept can generate exceptional emotions and therefore, sell. Most people I talk to about this come up with cool ideas, it really gets their imagination going and even the least technical people are suddenly designing brilliant systems that would solve a problem they have in mind.
Then there are economical considerations. Improving the quality of a service is good, reducing its running cost is great. There’s no way around the fact that an AI Agent can be seen as a 24/7, 365 days a year employee replacement in certain context.

Of course, the collective imagination was not always kind to AI systems… This is the reason for the unholy amount of AI ethics and safety discussions that we see around. This is certainly a legitimate concern, and it leads to the question of accountability. Who is responsible for an AI Agent action?

Anyway, that’s the selling part, the Agentic AI. The implementation part brings us back to earth fairly quickly, the usual issues around business domain understanding, data quality, business involvement etc. still apply, maybe even more since developers or data scientists may end-up teaching a model to do something that they don’t fully understand themselves.
That’s the AI Agent part. And while the discipline is fascinating and brings a lot of new depth to explore, it’s still subject to the usual project delivery challenges.
And since the only alternative is to have an AI somehow taking care of all of this, I feel like our jobs are pretty safe - for now.

Project Overview

Why another booking agent?

The idea of building a booking agent came quite naturally… I am involved in a voluntary position that consists of managing the booking of a multi-function room. It’s a straight forward and well understood process that works well as a first project. It also gives me the opportunity to trial it and to get real world feedback.

Application

We’ll start in the context of an existing web application, with a typical user journey:

We won’t be creating anything new in term of business logic, we’ve already defined what a booking and its lifecycle looks like. The existing workflow is simple and well understood. We could summarize it as:

Optionally, the user can cancel a booking. Policies apply and some fees may be deducted.

But instead of exposing this workflow via a web application, we want to give our model a means to orchestrate and perform the whole process on behalf of the user.
Does that sound familiar? It’s exactly what a customer representative would do over the phone or in a chat. Note that these are not mutually exclusive, we can offer both ways to the user and let them decide what works best for them.

It’s a low-risk and low-cost first step into the agentic world, and a logical evolution of the infamous chat bots. By now, LLM are more than capable to handle such basic and well-defined tasks. There are of course edge cases and it certainly needs guardrails, but that is already the case with human customer representatives:

• They operate within a defined scope (they can provide information to the user and create or edit a booking). They are not supposed to discuss any other topics, in particular anything that could be brand damaging or harmful in any ways.
• They can escalate a case to a manager if it’s unusually complex. Policies are in place to make sure that anything remotely unusual is flagged accordingly (for example, someone wants to book the room for 2 consecutive months).
• They only have access to what’s needed for the job. For example, they are not likely to have direct access to the user’s bank details or to the company’s HR records. So even if things go wrong, the damages are mitigated.

This is exactly the scope that our agent will operate under. In the next parts, we will see how to enable our agent to act (for example creating a booking), to retrieve knowledge that is not part of its base model (what are the opening hours of our imaginary meeting rooms?) and to assess whether to escalate the case to a human (or even to another agent).

Architecture

We assume that this backend is supporting an existing web application and that our goal is to leverage the existing architecture with as few changes as possible.

We have a single and voluntarily simple model, Booking. It stores a booking, made of dates and customer information.

The SqlRepository reads and writes the bookings to the database. Once again, the data model is kept extremely simple for the sake of this demo.

The Services is where the action will take place. In order to act, the agent needs tools. These tools are usually a function or a method. In our case, we will teach the LLM how to use the functions contained in this module to achieve its purpose – checking available dates in the database and creating a booking on behalf of the user.

Dependencies

This project uses python 3.12 with the following libraries:

Testing will be done using pytest.

For learning purpose, I made the choice to use a few libraries as possible and to implement each feature directly.
There are many abstractions available, for example to manage prompts, to implement RAG or even to create and orchestrate agents. That may be the right choice for a commercial project but it would make very little sense here.

Infrastructure

Azure is the cloud provider I have the most experience with, and also my favourite. Its AI offerings are neat and are improving constantly. I will use it for this project. All the products below have equivalents in other cloud providers.

Azure Container Apps

A serverless platform that will host our containerized application. It makes deployments quick and easy with minimal infrastructure management. It could be replaced by any service capable of hosting a Docker container.

Azure SQL Database

A fully managed PaaS database in T-SQL flavour. A great product that I’ve enjoyed using for years. We will use it to store bookings. It could be replaced by any other database engine.

Azure Blob Storage

The Azure cloud storage offering. Reliable and straight forward. We will use it to store the documents containing the meeting rooms information. It could be replaced by any other cloud storage service.

Azure AI Search

A feature packed knowledge retrieval sys tem. We will use it to index, chunk and vectorise the meeting rooms information documents. We’ll go into more details when implementing our retrieval augmented generation, or RAG, feature.
We will leverage its built-in skillset concept to do the operations mentioned before, and while competing products (e.g. Google Vertex AI Search) may offer something similar, I’m not sure how well it would translate.

Azure OpenAI Service

This service allows us to use the OpenAI API while getting all the benefits of a first-party Azure product – Private networking, managed identities etc.
It also comes with a somehow special version of the Azure AI Foundry portal, focusing only on OpenAI models. This portal aims to be one one-stop show for building, testing, and monitoring AI based applications. It’s a fast-moving product and I really enjoy using it, we’ll go through some of its features later.

These services will be deployed using bicep and the Azure CLI.

What’s next

Thank you for reading. In the next part, we will setup a local dev environment and deploy the infrastructure to Azure.