So to get a little more technical, let's dive into what it means to develop a Dialogflow application from a developer's perspective. This is taking it beyond what it means to chat and think about how you want to do user interaction and just talk with them, and rather than the absolute technical steps needed to deliver a solution.

Now as previously mentioned, Dialogflow is primarily based on its graphical user interface aka GUI that runs in your web browser. The key here is that you don't need to download anything to get started. This is not primarily developed through an IDE for the most part. Applications are primarily developed through the web. There are some programming that can be used but based on the web GUI and the API, you can get a lot done with just those two components.

Now we're going to be talking about APIs at times and it's important to make a distinction. Dialogflow can make outgoing API calls for fulfillment to a backend service, but that's very differentiated from the Dialogflow rest and GRPC APIs. These are for handling development. And if you're not familiar with GRPC, don't worry about it for now. Just know that dialog flow has the nuance that you can control the bot itself with development centric REST API calls but Dialogflow makes outgoing API calls to a fulfillment service to get answers and tabulate results.

And then in addition to these API controls from a developer perspective, you can also work with it in a chosen language. There are a ton of different client libraries that are allowed to integrate and expand Dialogflow, everything from Java to Go, like you might expect from a Google service, but there's also C# and Python and you're really able to start expanding your agent with custom functionalities.

However I wanna highlight that, you don't really need any of this to get started. This course is actually going to primarily focus on using the web-based GUI, because that is where you can get started quite quickly. You can get a lot of your bots out from the standard web interface and it shows much better for an online learning opportunity than using one of the APIs or programming languages. However, I don't wanna completely dismiss the underlying API and programming languages from this course because there's a lot of important stuff there.

If you're working on a system that can do automated builds, automated delivery and build out things with continuous integration and continuous delivery, aka CI/CD, the API, control API, is able to help you achieve this. So just know that there's that option there. And to touch base on some of the concepts you're going to see when you dive into the API and programming languages, you're going to see concepts beyond just intents and entities.

You're gonna see concepts such as sessions and contexts. We're not gonna discuss these as much in this class. We're mostly going to focus on agents, intents and entities, and fulfillment as they relate to building an agent, but just know you might see a few different types of variables and concepts inside of the programming language and API layer.

So now put yourself in the shoes of somebody that's been tasked with building a Dialogflow chatbot experience. What do you really need to have what we could dub a minimum viable agent? At its core, Dialogflow is a set of intents that are underneath an agent that all relates to a general purpose.

So this means that we need to go out and start to understand what do people, the end users and customers, expect from this bot. This goes a little bit beyond what the developer has and starts to discuss around the work of the project manager and a business analyst.

The developer needs to understand how program it but the customer facing field team and project leaders need to discuss what functionalities they need out of this particular group of functions. And not just the intents, you also need to understand the entities related for the fulfillment of those intents.

So what are the parameters? In the previous example, we discussed how there's a checking account balance. So there's an account number and account type sort of entity, but there's also maybe additional ones particularly if you have a broad set of intents. And then were the hardest ones to do and one that requires quite a bit of pre-work is understanding training phrases.

So remember, Dialogflow uses natural language understanding to assign and detect intents. And in order to achieve this, you need training phrases. Training phrases are how a person is actually going to ask for the intent. We don't just need one or two, we need way more than a handful. And these are what an agent will build out it's understanding and machine learning models on of how to recognize when someone is asking for the intent.

Now, we don't need every permutation. Dialogflow does have the ability to handle the nuances in training which we'll cover a bit later. Just know that you actually need to understand how people are going to interact with your bot. And finally, you need a delivery framework for sending and receiving messages.

This is now a REST API or maybe a webhook fulfillment to a Google cloud function or the inline cloud function editor or Dialogflow can send it's outbound requests set of fully parsed JSONs and then have a message come back to it that they can then serve to the user.

My recommendation is frankly any delivery framework that has at least basic JSON libraries, which is most modern languages. So as long as you have the ability to parse some JSON's and handle REST API, this is a good option.

Now there's one very important thing you need to do before you move on to actually architecting this out. And that's clearly differentiated intent. Entities can be shared between intents but training phrases need to clearly capture what a user is trying to say and what they're trying to do. If two intents are hard to differentiate, full stop do not pass go, this is going to lead to a lot of confusion and your chatbot will not be well received.

One of the quickest ways a chatbot can get unmanageable is if you have confusing intents, the users don't understand what they're asking for and they definitely don't understand what's going to come back to the response and everybody including our backend engineers are going to be confused. So when designing a minimum viable bot at the high level, you need to have highly differentiated intents and let's discuss how we can implement these intent.

Now, the single element is actually part of a larger diagram that we'll show in a moment, but it's important to understand the four stages a Dialogflow agent goes through on its own. You first need to receive a message. This is gonna come from some external integration. Maybe it's one of the native integrations such as web messenger, or maybe it's an external integration such as Twilio providing you a text message. 

Dialogflow is then going to ensure that the intent and parameters are all existing and match an existing pattern and it's then going to invoke the fulfillment service that Dialogflow needs to be able to answer the question. 

Dialogflow then needs to receive the response and as a note, it's typically the same post request function or call and it receives this response and then forwards the human readable response back along the same channel. These are the four steps that you need to understand that your Dialogflow agent will go through regardless of what else you build around it.