WEX Unlocks AI's Full Potential with Secure Agentic Platform!

All right. Welcome everyone. I'm Terry Del Monte, vice president of infrastructure and reliability at WEX. And little we'll start with a little bit about WEX and then I'll talk about our agentic vision and then my colleague Ed will come up and talk about that what we've built on agent core bedrock and then Ron will come up and talk about solution architecture and then we'll do what's next and take some Q&A. So WEX, we're a we're a B2B fintech company. We're really built in three different spaces. So we have a mobility business for fleet managers and fleet fueling. We have a benefits business where we're doing consumer driven health care plans and and the like and then we have a payments vertical where we're doing corporate payments, virtual credit cards and and those sorts of things. So highly regulated industry. We also have an industrial bank. So we're you know, like many of you we're facing you know, regulatory requirements and compliance requirements sort of at all levels. 6,500 employees, about 2.6 billion a year and WEX has been in business over the past 40 years. So we started with our problem of really

how are we going to solve our internal productivity challenges within my org. So um um So So we my team's about 400 people covering all of infrastructure, all of reliability. That team handles over 40,000 different types of tickets a year. There's high rates of toil and that's really what we wanted to try to try to solve there. And so in 2024, I challenged the team with let's build a virtual engineer. I want a virtual cloud engineer that can help to take action and deliver these services for our consumers. And um so we started down that path and uh we built we had really three goals.

One was the virtual engineer. We wanted to build uh that that capability. I wanted that to go beyond just uh you know, more of a a rag process and knowledge access, but I really wanted to see that go to that engineer is doing things that, you know, our humans are doing, you know, with the right controls and guardrails. Uh and then second, I wanted to dock democratize the contributions to that so that anybody in our technical organization could contribute to those capabilities and and really just uh accelerate the use cases and the and the capabilities of that of that tool. And then lastly, recognizing that not everybody knew how to build agents, we were so early into the process uh that, you know, we thought an agent that can assist with building agents is something we would also want to do. So we started so so that's where we started. In 2024,

In 2024, uh we delivered at the end of 2024, we delivered what we call Chat GTS. My organization is Global Technology Services, so little play on words there. We, you know, we came up with uh Chat GTS. And uh and actually one of our architects who built this uh talked about the process to do that last year at re:Invent, uh which was a great session if you want to go back and and play that back. Um but we delivered this service and and it was starting to do those things. We were adding use cases to it. They can use it now for uh anybody can can ask about network reachability questions and they can see if the if the network path is open all the way. They can add things to an email blocklist or remove from an email blocklist. There's you know, we're we're adding more capabilities to that. But what we realized was to get to the next phase, to democratize access to building capabilities on this, we were going to have to build a lot ourselves. And so all of the identity pieces, I mean it was just it was it was a large undertaking and and and a lot to really kind of think about. We built this obviously in partnership with our Amazon team. And you know, Amazon then talked to us

about Agent Core and and the upcoming release of that. So we partnered with them early on to to really leverage that technology to help us overcome that hurdle. So, you know, we we done spent a little bit of time through 204 through 25 building that out and and then last year we finally got our chat GTS deployed onto Agent Core. And and that really has been the game-changer for us. And so with that, I will turn it over to my colleague Ed who will talk you through Agent Core and and what his team's built there. >> All right. Hi, I'm Ed Taggart. I'm the

senior director of cloud engineering at WEX. Um so Terry threw down the gauntlet and said we want to have everyone developing agents. And the challenge we had like Terry said is that how do we do this in a secure scalable manner that we can get people in to build those agents. So at that time this is last fall Agent Core had come out. So we knew right away it had the primitives, it had the security, had the controls, had the guardrails, everything we needed to allow folks to build their own agents. So we again we partnered with AWS. We we migrated our chat GTS agent to to Agent Core. We also built our agent builder as well and we moved another corporate uh chat application over to Agent Core, built on that same framework. So, um I think I've got this one. Okay. Uh sorry. So, Agent Core Bedrock gave us a secure solution. So, some of the things that we really looked to get was, you know, runtime, a safe and secure place that people could run their their agents. Um we also uh got um gateway, which provided a secure centralized infrastructure for those folks to get access to MCP servers, to and we provide that in a centralized service, so we don't have developers going out and building their own MCP service. We serve those all up through uh gateway. Identity and access management ensures that users are are not provided access to data that did they don't they shouldn't have access to, right? So, we control that access. And then, you probably have seen these from the AWS slides, but memory um is scoped per user and per session, is encrypted uh in flight and at at rest. Um and it's also masked before storage using um Bedrock Guardrails. So, other primitives of observat- observability and policy are things that we really um wanted as well, and again, that's built into Agent Core. So, some of our first use cases.

So, I mentioned earlier we have a corporate chatbot. That chatbot we called Finn. That was actually built on a third-party solution. Sometime, I think it was the end of January or February, uh that team came to us and said, "Hey, we've got a contract renewal coming up. Can we put this on on Agent Core?" We worked uh closely with AWS, and we migrated that in 6 weeks. Um so, we avoided having to renew that contract. Now, this agent is is provided to all of our um uh corporate associates. This provides us policy doc information, provides us access to work data get your vacation hours. Um it access uh knowledge bases. It accesses Jira. So, folks are using this on a regular daily basis and we're using uh Agent Core, Gateway, and and the primitives that secure it. Missed the animation. Okay. Uh so, Agent Builder. So, this is something that we built. Um it's it's agents building agents. We needed to find a way to help engineers understand how to build these agents. And some of these folks were all technology services. They knew they knew Python, they knew Terraform, but they weren't necessarily coders. So, we uh decided to develop this Agent Builder skill, which allows folks to build their own agents. So, first it starts with a chat. Someone goes into chat GTS and says, "Hey, I want an agent." And they describe uh lightly what they would like to see out of that agent. That goes into um a supervisor agent. The chat first is passed to the the um the Agent Builder agent. That goes into a supervisor workflow, which then controls where that goes next. So, it goes to a spec builder. The spec builder then interprets the request and then builds a spec sheet. That spec sheet is stored in S3. Once that's done, the supervisor hands that off to a code builder. The code builder then takes that uh and then oops. That code builder takes that and codifies that. And uh puts it into a GitHub repo for the user. So, they get the the spec doc, they get a GitHub repo with their code in it that they can then um they can review, they can revise it, and then they can deploy it. Uh to be fair, this is not meant to be enterprise class building it applications, but what it is is a way for engineers to sort of get the taste of how do you build an agent. They get the code examples, and they can do it and they can they can deploy it.

So, let's talk about how the how this how the traffic comes in. So, we're a Google Chat company. Um it starts with a Google Chat, um which then comes in through our our web application firewall. That then hits a Amazon API Gateway, and then a Lambda function. Lambda Lambda function normalizes the data, and then quickly acknowledges back to the user that that the agent is on the job. There is that that's then handed off to a step function. The step function takes the identity from chat, which uh and then matches it up with an Active Directory uh identity for authorization, and then passes that on to the agents. Now, the agent knows context about who the person is and what they're allowed to access. Then, it's handed off to Amazon Bedrock. And with that, I'm going to hand this over to Ram, cuz that's where all the magic happens. So, there you go. >> Thanks, Ed. Good afternoon, everyone. Uh Ram Guntada, senior solutions architect at uh AWS, and I've been working with Vex for the last uh uh close to 3 years now. Uh what you have heard so far is uh what Vex has been building, and Ed walked you through like how the requests are flowing through the platform, and uh landing on the uh agent core. Uh but the question that we get from every

security and the compliance stakeholder is like how do we govern this at scale, right? How do we let hundreds of engineers build and deploy agents without losing control on what those agents can do, what tools can they access, and what are they doing right now? That is what I'm going to walk you through uh for the next few slides. And uh there are three layers that together give us the governance uh foundation. A good governed catalog on what agents have access to. And the second is a good governed access layer that gives that gives right access and the right tools for the right agents and an end-to-end visibility with open telemetry giving us insights on what the agents have done.

With those three, I'll start with the first one. Um so, this is our control plane agent core registry. Agent core registry is the disc governed discovery layer. Uh teams can't just go build, develop agents, and deploy the the tools for the agents, excuse me, and make it available for the agents right away. Uh there's an approval workflow. Every MCP server, the tool schema, or the um or the skill that they develop goes through this review process before it enters the catalog. It's through the semantic search and the keyword search that the agents and the IDs and the developers get access to the right tool and executes it without even knowing that the tool such a tool exists. And that tool goes to the catalog only after going through the approval process that I mentioned earlier. So, that's the governance at the catalog layer. Once the tool is discovered, everything flows through the gateway. So, this is the data plane.

This is the governed access layer. So, it's how the agents access the tools, enterprise tools, and services. So, every tool that agent calls goes through here, which gives a natural choke point for any enforcement. So, it's this agent core gateway that exposes the tools via MCP endpoints. So, that is how any MCP compatible agent or an IDE can discover the agent and call the agent consistently every time. And it's this agent called gateway that helps wrap your existing tools and services, all your legacy tools and services uh through MCP endpoints that are exposed through MCP protocol. So, there is some very minimal code change that you have to do to make your back-end services available as tools for these agents. The next primitive I want to talk about is the uh agent core identity, and one of the feature is OBO, on behalf of. When an agent calls a tool, it doesn't act as itself. It acts as the one of the authenticated users who's calling the agent. For example, uh you as a human, if you don't have access to a Jira project, the agent would not have access to that Jira project, either. So, uh so it's really confined to the permissions that the end user is calling the agent. And And this agent core identity it integrates with the majority of the enterprise IDPs such as uh Amazon Cognito, Azure Entra Entra ID, Auth0, Okta, etc. And this identity is applied at the request time every time. The next uh The next uh the next primitive I want to talk about is the agent core policy. Uh agent core policy determines what tools and services are available and allowed for an agent. These policies intercept every tool that the agent calls before the execution, and all this happens deterministically and not probabilistically. That's really key. And every enforcement decision that the agent core policy makes, it gets logged into your CloudWatch, and that becomes your audit trail. So, agent core policies really control what agents can and cannot do, while Amazon Bedrock Guardrails, it controls what a model can say. So, it is these two independent enforcement layers gives an organization a good defense in depth.

And then the observability, this is where your end-to-end open telemetry tracing across traces that across cross every agent action that that takes place in agent core. It the open telemetry traces span every layer, right from your web application firewall to your lambda functions, to your step functions, and then the agent core. Every agent action is traceable end-to-end. And this is especially useful for a regulatory environment where this becomes not just your operational visibility, but it becomes your audit trail. You can reconstruct exactly what an agent did, what tools it called, what data it accessed, and every decision it made during the process. And this is how a lot of compliance use cases gets easier, especially like the any of the regulatory reviews, incident forensics, or uh somebody wants to uh profile a behavior of an agent, this is how uh these traces become useful. And all traces flow into Amazon CloudWatch, which is your centralized immutable audit log. So, that's the platform at a very high level, and uh the runtime, the gateway, the policies, and the uh and the registry make up all the layers that gives us a very good uh governance foundation. Um Um That But, the architecture only tells you half the story. The real question is uh did it really work? And did it really move the needle for WAX? I'll hand it over to Terry to walk us through what they have seen in production, and uh where WAX is taking this next. Thank you.

>> So, our our business outcomes. So, we have uh we have now we have over our full workforce, 6,500 people are now using agents that run on Agent Core. We are seeing over 2,000 over 2,500, as you can see here, uh users that are interacting with it on a weekly basis. So, so so we're there. We're using this platform in many different ways, and our value is growing. We We have saved uh hundreds of thousands of dollars already on uh on some software. Uh as we said, we were able to avoid a renewal there. That There was some savings there. We have 60 builders, and growing every day, uh that are now building agents on this platform using our Agent Builder capability. And at the end of uh by the end of Q2, we will have rolled this out to our entire 1,500 person developer group as well. So, by the end of by the end of Q2, we will have all of our developers able to use this service to build their agentic capabilities. And and then the what's next, right? So, Ram talked a little bit about the OBO, the on behalf of capability. That's a big one for us to implement next. So, what we've had to do today is provide some There are some limits into what we can provide because an MCP service today has to run under the service account and it can't it is not fully running on behalf of the user. This allows us to do that because we can take the user's authentication token, pass it all the way through the stream, and now we can we can add MCP services with with more capabilities that just make it much easier for everybody to use and do what they need to do. So, that's a big one for us in addition to onboarding the the whole group. And then and then really we're focusing on moving beyond So, the agentic engineering capabilities into the AI SDLC process. So, we are building from product management all the way through to deployment and observability and runtime and agentics and agentic process that starts initially, you know, with with human in the loop all along the way, but but agentic capabilities that will take product specs, turn them into technical specs, do the spec-driven development, deploy deploy the runtime with all of the observability, security, logging, and and other capabilities. Humans watching that all along the way, but really start to enable our ability to to develop and improve developer velocity. So,