The principal use case for Amazon Bedrock that we are working on is regarding a logistic company that has a flow where they receive emails to look for incoming invoices. We have an architecture that sends these invoices to the queue and identifies the partners involved on the invoice, and we have specific queues; for each queue, we have a specific agent that will treat this information and analyze what they are looking for in the invoice they are sending.
For example, if we have to send it to the invoice team, we read this email, and based on the request in the email, we get the information from the email body and then the information regarding the invoice. We understand the behavior we have to deliver to the specific system or how we can create a new ticket for the invoice team to get this invoice and register it on the legacy system. It involves this integration and using specific agents to read, understand, and process the incoming invoices.
One of the best features of Amazon Bedrock is that it is easy to use, and users do not have to worry about the infrastructure. For example, if we have to create a similar solution, we have to think about what kind of LLMs we need to create for it to execute. Using the Amazon Bedrock architecture, we choose some of the available LLMs and then can focus on the business solution.
The AI solution, this specific intelligent agent that we are creating, is not something that you can just execute; you have to create some logic around the agents to create this process, and then they will execute what you have created for them. Amazon Bedrock accelerates the process of creating your architecture. It is not specific to modernize your legacy, but you can accelerate it.
They provide all the infrastructure that you need; you just have to follow the specifications, and then we are able to create our agents to solve the kinds of problems mentioned earlier. For content creation capabilities, they help us streamline our content generation processes across different departments. This solution we are talking about is just to process one specific process that we are looking for, which is totally inside the same area. We are not creating it for or interacting with other areas inside the company. However, once you have your infrastructure, even if it is hybrid and not only on AWS, you can integrate it.
Today, the solution we are specifying is a kind of LEGO that you can just get some pieces and connect in our solution. For example, we are using SNS to send these queues. You just need to connect an outside AWS solution and send it through API to this queue; you put the message there, and you can get it inside our process. Even if this email is not the specific trigger that will call our solution, we can get it from SAP. If I have this same invoice and want to use this process, you just have to send it through an API; we have just connected it to our solution, and you can create it to be available for the other areas or other systems involved in the company legacy systems.