When an AI agent shows up at your checkout, most systems still see a bot and block it. Alexander Guensche is a Senior Solutions Architect at AWS and the lead of TSAI, the Trust Signals for Agentic Interactions protocol that AWS is building with Trusted Shops. Moji Sarooghi is a Distinguished Product Architect at Queue-it, where millions of bots hit a single product drop. In this episode of the Smooth Scaling Podcast, the two of them walk host Jose Quaresma through what replaces the old human-versus-bot binary. They get into why trust and identity are not the same thing, why you can have one without the other, and how a merchant can respond to an agent with something more useful than yes or no. Alex is candid about the line the protocol would not cross: identifying human users, which he describes as a slide toward totalitarian systems that rate people. The conversation closes on where this lands in practice, from reputation feedback loops to the traffic-orchestration layer Queue-it is building on top. A grounded look at what trust means when your visitor is software acting for someone else.
Alex is a Senior Solutions Architect at AWS with 20 years of IT experience in expert and leadership roles. He is a strong advocate of agile and DevOps practices, and he enjoys seeing serverless, cloud-native and event-driven architectures deployed at scale. He has delivered large transformation projects and successfully developed own and customers’ businesses. As an international speaker, he has held advanced technology sessions at a wide range of events.
Moji Sarooghi is a Distinguished Product Architect at Queue-it. Moji was one of the company’s first employees, starting his journey as a software developer over 10 years ago. He is highly experienced with AWS services, product and architectural design, managing developer teams, and defining and executing on product vision.
Â
Episode Transcript
Jose:
Hello and welcome to the Smooth Scaling Podcast, where we speak with industry experts to uncover how to design, build and run scalable and resilient systems. I'm your host, José Quaresma, and today we have the pleasure of being joined not by one, but by two guests. We have Alexander Guensche, who is a Senior Solutions Architect at Amazon Web Services, with more than 20 years of experience in engineering and architecture, and very importantly for today, the lead of the TSAI protocol. Welcome, Alex.
Alex:
Thank you very much, happy to be here.
Jose:
And we also have Moji Sarooghi, who's a Distinguished Product Architect here at Queue-it, joining us for the third time. So you're in the lead, Moji, and welcome.
Moji:
Thank you, happy to be here.
Jose:
And today we are talking about trust in the age of agentic AI, and how can we ensure fairness and that we're maintaining trust online. This has been an effort, and we have been working at Queue-it on it for a long time. So adding the agentic component to the online world, it's making things harder. And I'm very happy to have Alex and Moji here to talk about that. And that's because I think both, from each perspective, bring a lot of experience here and work in this area: you, Alex, with AWS and with the TSAI protocol, and you, Moji, in Queue-it with the work that we do in online traffic orchestration.
So I would like to get started and go straight in. And maybe I'll start with you, Alex. Was there a specific event or specific moment where you saw that, well, agentic AI is not a someday problem, but it's actually a here and now problem?
Alex:
I think so. For me, this was mid last year, I think, when agents started doing shopping rather autonomously. But they were perceived by vendors or merchants as bots, as they have always been, right? So they have thought, okay, this is automatic traffic and it's getting between me and my customer. And so the response was not to welcome that as a revenue stream, but to block that. So there was this story about Amazon and Perplexity, but many others as well. And the response was always, look, I have built up this relationship. I've created experience for my user. I don't know who that agent is. And theoretically, it could have stolen credentials and impersonate the users. So that is not verified. And we don't trust that actor. It has an own agenda, maybe.
And at the same time, we are wondering, can't this be a good thing? Can we not have users use agents to do things on their behalf? So we should create an infrastructure, an environment where that is actually converging rather than kind of creating friction.
Jose:
That's a very good example. Thank you, Alex. And Moji, from the Queue-it side, from the front door, what are some of the traffic patterns that we are seeing?
Moji:
Yeah, at Queue-it we daily have these challenges. There is a product drop in different industries, and then there is a lot of traffic going to do a purchase or find a place in the waiting room. And then, to be fair for these visitors, we need to see who is good, who is bad. Previously, we were just focusing on that: okay, there is automated traffic, it's bad, let's block them, challenge them. We need to do that. But now there is an add-on to that challenge. Maybe that automatic traffic is not bad traffic.
That is how we kind of went in this direction, that if we're going to orchestrate these traffics we need to have three different actors at least, you know: the human, the good bot, and the bad. So we are seeing quite a lot of traffic now going on. Also there is a lot of study on the internet that this kind of good bot, or automated traffic that's coming from agentic traffic on behalf of a user, will increase rapidly in coming days, and we can see that one. Now we are focusing on understanding what is our strategy in this part, and then at Queue-it we are really focusing on being able to orchestrate this kind of traffic, separate them, giving all customers the capability to say that if the traffic is coming from this kind of actor, what should happen.
From the numbers, I don't want to give a 100% accurate one, but we are talking about millions of bots accessing a drop product. We see it in different industries — again, a sneakers shop, I don't know, there is a limited resource that people have interest to access. And that is our daily life. So we are interested to find a solution, and that was also how we got to this topic with Alex as well.
Jose:
Alex, how do you see this agentic traffic affecting trust? Which players do you see starting to lose trust, and how do you see that working?
Alex:
To my previous point, and maybe elaborating on that: there's a new actor, and actually it's two layers of one actor. It's the agent itself, driven by AI, that has agency, autonomy. That's the whole point of it. And as a user and as a merchant, you don't really know upfront what it does. And it's part of the value proposition. At the same time, there is an organization operating that agent, or having built it, and maybe even operating it on behalf of you, depending on the model.
Now, the question is, what are the intentions of that actor? And what is the inherent agency of that system? And that makes it hard for merchants as well as for shoppers to build a relationship that needs those signals that would allow you to intuitively make decisions far beyond the point of where you make a payment. So even if you start visiting your shop as a user or as a merchant, you decide: do I want to let that actor in? You need things that go beyond identity.
Jose:
Let me just go back and maybe bounce it back to you, Moji, on the trust part. Have you felt that at Queue-it? Is that something that we're starting to feel and discuss?
Moji:
Yeah, actually in the product, in our roadmap, at least in the product, we are trying to figure it out. In the first stage we need to be able to show to our customer who are the people that are accessing their endpoints. Yeah, I discussed the different actors, but also, back to what Alex is saying, what company is behind that agent, for example.
I will add something also to what Alex mentioned. There is this agent, an agent provider, also the user behind that one. Can we get information about that user behind that agent as well? So this is the first step that we have in our plan, to provide this visibility. We are thinking of having an MCP that helps the agent to do this stuff.
But at the same time, imagine you have this visibility, you have this MCP that makes it easier. Then what capability can you, as a service owner, as a website provider, what kind of decision can you make? Can you say that a specific agent should be able to buy something and the other agent provider should not? We will get to that one in more advance of this topic.
But there is another interesting point here: the whole thing that we need to know gives us value. You know, actually, we see it as an opportunity at Queue-it. This identity, either the agent or the user, is kind of an advantage for us. It helps us to understand who is good.
Alex:
Yeah, to that point, by the way, you said something interesting earlier: the agent, the agent operator, but also the user. The interesting point here is the who that you need to see, Queue-it representing merchants, and the merchants themselves. But then there's also the question of privacy. So maybe it is not in the interest of the user to be this close at this point. And that could be an interesting point to discuss.
What can we know about the user without identifying them and then creating some surveillance system at scale, which would be legally and ethically highly questionable? Of course, at some point the merchant needs to know who that is, because at the end you need at least a delivery address and, of course, need to know it's legitimate. But there's this tension between having a lot of information about the actors on the other side, but then also ethical questions about identity, and also behavioral traits that may not be in their interest to be disclosed at this point.
Moji:
That is 100%. Yeah, you know, they say that the information, the power, brings the responsibility.
Alex:
Yeah. And then that is also a challenge. That's a topic that we are discussing.
Moji:
I think there is something maybe in between, that we don't need to know 100% if that is a user, but is it a trusted user? Yeah, you cannot track that, but you can understand this was somebody somewhere. This could be the agent, could be the trust authority, could be, I don't know, some kind of Mastercard or Visa card. Somebody has given that user an identification. I don't need to know who that one is, but if I know that this user is trusted, as much as the agent can be trusted, I think this is good.
But again, there are different levels. Who is the agent? Who is the operator? How much can we trust that one? And in the lower layer, who is the user behind that? And even in a lower layer — that was interesting, we were discussing also with Alex before — there is this protocol about this Mastercard Verifiable Intent. Not only knowing who is the user behind that, but also whether the user has authorized the agent to be able to do a purchase. So this intent. So in these different levels of trust, I think it's all kind of potential and advantages that we get also at Queue-it and provide for our customers.
Jose:
What I hear you say, and I think we all agree, is that we can't continue treating automated traffic as a bad thing, right? I hear we're talking about that before it was humans versus bots. Now it's good intent, bad intent, or human or good bots versus bad. So it's getting more complex, right? And there's a huge cost in not handling that properly, right? And just saying, oh, it's a bot, it's a bad thing. So I think we all agree here that that has a negative impact if not addressed properly.
And we see the industry now starting to respond to it. Moji, can you share with us some of what you've experienced with how the industry is reacting? What are some of the protocols and initiatives that are...
Moji:
100%. Yeah, just adding one thing before I get to this one. The fact that the good user is also automating this traffic, that is one thing. But also there is the fact that bad users or bad actors, with bad intent, can automate traffic easier than before. Yeah, you know, you can just easily create an agent and do stuff. Previously, you needed to be a really good tech person. Now you can just use some kind of automation easily with this. That was one part.
Back to this topic, we are really monitoring this on the internet. At least, I was talking again with Alex about this one. I can see, at least with a kind of limited research, there was something related to Mastercard Verifiable Intent. There is the Trusted Agent Protocol with Visa. There is Web Bot Auth from Cloudflare. And an important one that we are discussing here, the TSAI protocol from Alex's team. All of them, they are trying to address the same issue.
So first, when we see there is a lot of interest in this topic, showing that the problem is there and we all agree. And then we see that the market is going toward authenticating the agents, authenticating the user, and also authorizing. You can see also even in the UCP protocol, with more focus on the merchant part, what an agent can do. If you read that protocol, there is a place that, okay, can you trust this agent or not? So this topic — even the AP2 protocol is also talking about this kind of trust of the agent as well. So there is broad interest in the market and heavily going forward to find a solution for that one. That is also what we see and also what we are monitoring on that perspective as well.
Jose:
And I would take your lead and ask you, Alex, can you give us, maybe start with an introduction to TSAI, kind of what's the origin story and how did we get to have AWS and partners backing it up? And maybe for people listening, TSAI, it stands for?
Alex:
It's for Trust Signals for Agentic Interactions.
Jose:
There we go. Just to make sure that people listening can follow.
Alex:
So to your point about different protocols that exist, different initiatives, there is no shortage of large organizations who have the power to technically implement a solid protocol, but also give it adoption. The gap that we saw, and some of the points you mentioned, is conflating trust to some extent with identity. I think identity is a very important aspect of that, but you can have trust without identity, and you have situations where identity is not enough to establish trust.
So let me give an example, a real-life example. So imagine you are a pizza shop and you get a phone call at 10 p.m. Someone says, bring 15 pizzas to that part of town. So ideally, it's a good business opportunity and you would catch that. But at the same time, you say, ah, it's late and it's far away. So do I send my driver there? And what if there's three guys, you know, just beating him up and getting his money? So how do you assess that without knowing who's on the other line? You have maybe a phone number, but you don't know, is that real?
And so if you translate it to the online world, you may have in your, let's say, sales funnel, situations where you don't even have established identity. For instance, every shop allows visitors to put things into the cart, but that can deplete your inventory. It might be that your competitor is setting up a bot to deplete your inventory and take you out of business so they can raise prices. I'm not saying that happens, but it would be a potential attack that would work without having them identified. And so along the sales cycle, you would benefit from that.
But also after establishing identity, you might see I need even to know more, because there's high-value transactions and just knowing that someone is there doesn't suffice. And at the same time, what does identity even mean? So having an address is identity to some extent, having a physical ID is something, but you can fake a lot of those things. So it's typically a combination of things.
So I went a bit off the rails, because the original question was a bit more about how did we get there. The reason to come up with something like TSAI is to formalize these trust relationships between agents and merchants, and agents representing users behind them without disclosing the users. So keeping privacy up, putting that in the hand of the agent operator. Of course, they need to verify that. To an earlier point, as Queue-it: of course, you don't want one user to set up 50 agents and block the queue and deplete the inventory of those rare sneakers or concert tickets. And to have that beyond the pure identity, that was the intention of TSAI.
Jose:
And maybe a little bit on — I understand that the TSAI protocol, you do have different families of signals, and that is related with how much information and, I guess, in a way, building that trust, or at least that understanding of intent as well, and assurance. Can you take us through those four families?
Alex:
Yes, we refer to them as categories. When we started, we had them as tiers. So we had assumed — you know, protocol design is also a social activity where we discuss a few things, obviously the landscape. But we found that they are rather complementary than kind of layering up.
We have attributes, that would refer to things like: is there a valid company behind that? Is there maybe a phone number? Is there a credit card that can be verified? So these are just static attributes. And then there is reputation, which is a rather dynamic thing. You know that from online rating systems where you would rate a shop, but you can also have it vice versa. As long as we're talking about human beings, but about commercial agents, you can also rate the agent, its behavior, its reliability, things like that.
We have one dimension that would be assurances, where you could even go so far as to say there is — because in the end, it's all about risk mitigation. There's no guarantee of sorts, but in the end, you want to have the risk of your transaction covered. And you can have an online insurer that would say, okay, for a fixed amount, I will guarantee that this will be successful.
So I forgot one more thing. So there's another dimension that's called attestation. And this is where you would have an external third party verify that you comply with certain industry standards. Common examples are ISO 27000, where you have certain security attributes, and that is external attributes through a third party that would have guarantee. Sorry.
Moji:
Sure. No, I'm saying maybe the workflow. Yeah. What is the user flow, or kind of the data flow in this regard? And who are the parties that are involved in this? I was reading about the, you know, service provider, that's kind of like a merchant, and then trust authority. And, you know, imagine that we do an end to end. I think that would kind of make it really easier to understand for the audience as well as me.
Alex:
That's a fair question. So as with security and multi-actor activities, it has a certain degree of complexity. We have five main actors in that model.
So traditionally, if you come from the normal online commerce world, you have a user or a buyer and you have a merchant, which is the online shop. In this model, we call it service provider, because with the main focus on commercial transactions, there can be many, many more types of agentic interactions. So we want to keep it a bit more generic, so we say service provider as a merchant.
Then we introduce agents, and we have two actors representing agents. One is the agent itself. As established, it has autonomy. It has its own agency, where it makes decisions based on the signals that it receives. It acts on the user's intent and in their best interest, hopefully. But then it is driven by another entity, which is the agent operator, the company who built the agent and gave it basically its prompt, its harness. And it also is a commercial entity that has interest.
And then we introduce one actor that is ensuring accountability and actually is the root of trust, which is the so-called trust authority. And those five actors together — mainly the trust authority, the agent and the service provider — are interacting in this model. The others, the agent operator and the user, are basically a bit more on the sidelines, but they're, of course, influencing the entire behavior.
Moji:
Cool. I'll just give my understanding. You just correct me if it's correct. Yeah. If I'm an agent operator in this regard, I will go and register myself to trust authority. And then I acquire those levels that you mentioned. Then I will sign my traffic that is going to the service or merchant. And then somebody or some tool on the service will verify that and, you know, say that, oh, you are verified, now you are this specific agent with this level. And then what? Is that correct?
Alex:
Yes. In a nutshell, that's how it works. So as an agent operator, you first register with trust authority and provide your trust signals. So basically give your attributes, verify your phone number, credit card, and so on. So it's this trust authority's job to verify that. And the rigor they put in actually bestows the trust into the system. And once that process is complete, the agent operator as an entity is registered. And then it can basically instill that into an agent instance. That can then get short-lived credentials. We can go to the technology later on. But it's then able to present those credentials to a service provider, and the service provider will be able to decide upon those signals.
Moji:
Sorry, Jose, I need to say this one as well. So the interesting part for me when I look at this TSAI protocol, yeah, this kind of open environment, that whoever has trust can be a trust authority — for me that was interesting in your protocol. And also the concept of this level of trust, the whole detail of reputation. I think this is really interesting in your protocol, and it's kind of different with the other ones, how I could distinguish between TSAI and the other ones.
But also, Jose, that was really interesting. Whenever we talk at Queue-it on this service provider, which could be a merchant, could be any other website, there needs to be an entity that does this verification. And as a customer, I can say that, oh, if you are verified with this level of reputation as an agent, then you can do this specific purchase. Or you are not allowed to do this, or you cannot index this, you know. And that is exactly where Queue-it comes in place as a traffic orchestrator.
So we can have some kind of connector, we call it, or traffic orchestrator on the edge, kind of receive the request, get those signals, verify by trust authority — or I know that in your protocol, we can do the static without even the offline kind of verification as well. Is that correct? You can correct me if it's wrong. But then I can let the traffic go and access. As a customer, I can put some kind of rules that says, oh, if it's coming from this specific agent, then do this. If it's not, then do the other one.
Jose:
I think building on top of what you're saying, Moji, my understanding is also that as part of the protocol, the service provider is not just saying yes or no, right? I understand that there's a bit more nuanced degrees of response to an agent operator coming to you. Can you tell us a bit more about that?
Alex:
Yes, let's start with that. So the protocol itself does not decide. It's just giving signals. That's the whole point. That's why it's in the name. And there's a spectrum of how a merchant or a service provider can react upon those signals.
On the one side of the spectrum is a hard no. So what you're seeing there is not sufficient for any interaction. And then on the more other side of that spectrum, there is different ways to say yes: yes, but, or yes, absolutely. So we say, when we present this, okay, as an operator, sorry, as a service provider, you could say, I will approve that request, but with limitations, for example, lower API limits, because I see certain signals that are good enough for me, but I wouldn't let it to the same level. And to be clear, this is still better than being blocked. So there should not be an interest for an agent operator to conceal their identity, but they should play with open cards and say, okay, this is what I currently have to offer, and let the service provider decide.
But there may also be the plain yes, good enough for me, let's do this. There could be a situation where they say, we have on top of those trust signals even a higher tier, where we allow agents to do high stakes transactions, or they get preferred access beyond what a normal agent or even a normal user would get. So this is basically a broad spectrum of what you can do as a service provider to accept traffic.
Moji:
That's exactly also what we are, you know, trying to — what we are working on at Queue-it as well. Yeah, you have some rules that you can say, do something based on the trust level, for example. Yeah, you are allowed to access, or you need to pay some money to be able to access that one. While I like your traffic, but because you are using my resources and you are from this trust level, then you have to provide some money for the service itself. And that is opening up a lot of opportunities on this orchestration of the traffic.
Jose:
And how is that — still within the protocol itself — how is the verification or validation done? I think, Moji, you mentioned that some of it can be done offline. I think some of it, especially the higher categories, if I remember correctly, will require online verification. Can you take us a little bit through that as well?
Alex:
Yeah, so I don't want to get too technical right now. I mean, I can.
Jose:
Let's start with kind of high level, how that would work.
Alex:
So we work based on a standard that's called selective disclosure JWTs. And that would allow to convey several signals semantically. But the verification itself is a crucial part. And that happens on two layers.
First, there is what we call the edge layer. This would be perfect for Queue-it, because it's just the general check of the signatures and if the traffic is valid. And the big benefit for the merchant is you do the heavy lifting, actually also in bot management, which is too hard on a, let's say, live application instance.
But as you dive deeper into those signals, then it would be upon the merchant to decide which of the signals they want to process in which way. However, there could still be a service by a provider like Queue-it who would say, these are hard to parse. And actually, of course, you can then go back to trust authority, but we already have that relationship with trust authority. And maybe you want us to go deeper into them and give you a rating of those. This is something trust authority would not do, but we have a bit more opinion on that. We know your business better than a trust authority does. So there's a step of things you have to do on the edge or application. Edge is certainly a Queue-it thing, but in the application itself, you can do the heavy lifting for the merchant as well.
Moji:
Can you go a little bit deeper on that one? Because whatever I can do in the merchant, I can do also on the edge. Why can I not do that? What scenario do you see that it's not possible?
Alex:
It is not so much about possible or not possible, but the degree of the business decision that you need to make at this point. If the merchant fully trusts you to make a business decision, let's say about the stake of the transaction and the assurance you would need for that, then of course, go ahead.
Moji:
And this one, I can add something. What we have at Queue-it is that you, as a merchant or as a service, you create some rules yourself and we will apply it. So all that heavy lifting, it's just some kind of UI that says, oh, if traffic, this one, this one. So still you are doing your intent as a service provider.
Alex:
Amazing.
Moji:
That is what I wanted to say. You can put the rules. You as a merchant put the rules as a service, but we are the one that's applying it on the edge. So we don't make a decision ourselves. We just use whatever you configure on your end.
Alex:
Okay. Then maybe I should have phrased it a bit differently. So there are things that are more on a technical layer and things on a semantic layer. But if you provide those semantic services in the solution that you're building, you can have it as a one-stop.
Moji:
Yes, exactly. That is also how interesting this is for us, actually.
Jose:
Thank you, Moji. That was, I think, a really good add-on to it. And now that we've been talking about the protocol and some of the how do we do the verification and the validation, I think one of the things that has come up before when talking about this is the parallel to the Web Bot Auth protocol. And my understanding is that now TSAI is starting to use Web Bot Auth for the authentication. And please correct me if I'm saying something a bit off. But could you maybe start by saying, why didn't you start TSAI with Web Bot Auth from the get-go?
Alex:
Yeah, it's a fair question. So maybe just for those who don't know what Web Bot Auth is, it's a standard proposed by Cloudflare, mostly based — I think 90% of what Web Bot Auth is, is based on RFC 9421, which is message signatures for HTTP. And what Cloudflare have added is the identification at basically the — not just signature, but saying where does the signature come from. This is valuable. So there would have been good reasons to do it in the beginning, and we have considered that.
Now, the reason why we haven't adopted it from the beginning is more a practical one, and it's the consideration of adoption. So when you create a standard — and of course, it doesn't make sense if just a few people do it, then it's not a standard. So what you want to achieve is that you get broad adoption. And the decision was, do we use another standard to piggyback on, when the risk is that that standard doesn't get adopted, or another one basically competes with that?
And so Web Bot Auth solves identity, but there's also other solutions with other standards. And in the beginning, we decided to go with distributed identifiers, which is a standard by the W3C. Also has broad adoption and is more agnostic towards, and has different ways of being authenticated, and it's not centralized to the actual domain, so that it is more flexible in it.
Now, this has been half a year ago, and this also shows how fast this industry moves. In that half year, we saw real adoption by different large organizations. Cloudflare itself is large enough. But then you also have AWS with the WAF product. You have Google adopting this as well. And this is reason enough to say, look, there is now something that emerged as a foundation for identity, even if it's a different ecosystem than the W3C. It has merit. So let's see how we can make sure it works together.
That, however, forced us to redesign a protocol. And interestingly, there are two standards that call themselves verifiable credentials. And this is also something we just discovered on the road. There's, based on distributed identifiers, a W3C standard called verifiable credentials, but there's also one that is an IETF standard by the same name. And if you research a bit deeper, there's even a bit of competition and debate why this is not the same thing.
And so we decided with the new version that's coming up now to kind of switch lanes. So we say we take Web Bot Auth as the foundation for identity that will verify the agent itself, but then the trust authority would sign that as well and inject the trust signals through the IETF standard of verifiable credentials, and pass that on as something called a selective disclosure JWT token. And this so-called SD-JWT has another advantage, the SD part, which means that the agent operator itself can decide which signals it wants to disclose to the merchant. And again, to the point of privacy, there may be situations where the agent does not want to reveal certain signals because it's a low-stake transaction and you want to be frugal with data.
And this is another advantage of now making that switch. And of course, we didn't do it lightheaded, because it's a massive breaking change, massive protocol redesign. But in the end, we think we now have something that has a stronger foundation for identity with Web Bot Auth and at the same time has the advantage of selective disclosure with the new standard.
Jose:
I can only imagine that being there from the beginning of designing a protocol, there must be quite some difficult decisions. I think you took us through a path there. Were there any other features or things that you have been looking at in the product that you didn't chase and just left on the table? Do you have any examples that you can share?
Alex:
The hardest one, what we talked about earlier, is identification of human users. So there would be a lot of demand for that. I can absolutely understand why that would increase trust on the merchant side. But the more you explore that, the more it gets frightening, to be honest, because you're looking into totalitarian systems that allow you to rate users. Again, not just legally questionable — that alone would put it off the table — but as a human being, you say, is that what I want to build?
And so the way we solved this, there's a lot of tension between that. And we said, okay, we know that at some level the agent and the merchant will have to exchange the data, but it should not be inherent in the protocol. That is something outside of the protocol. We will ask the agent operator to verify their own customers, to not have that scenario where, for example, one user impersonates or launches 50 agents to deplete a queue. But this is not our responsibility in the end. If the merchant sees that behavior, or someone like Queue-it would see that at the larger scale — which is a large benefit, that you can see this across multiple merchants — then they can get in touch with trust authority and get that agent blocked, or lower their reputation and make it more expensive for the agent operator to do such things. So we take the user out of the equation, but we still want, of course, a real-life system.
Moji:
Yeah, also I can add to that one. It's not also just the queue part. Yeah, imagine that you have a limited product, and then one person comes and creates 50 agents, and then they go and each one of them buys that. So it's a really, really part that needs, I think, some kind of exploration at least.
But back to this, I think actually you touched on some important things: the feedback cycle. I think that also, when you ask the question, what part is the complicated one, I expected the user behind the agent as one of them, but also this feedback cycle: how can this service provider or merchant in this scenario report back? Have you seen any, or have you done any exploration of that one?
Alex:
Yes, you are right. This is one of the hardest parts. It is outside of the protocol itself. So the protocol holds properties to convey that reputation score, but the protocol does not mandate how that comes to life. This is in the hands of trust authority.
So I should mention we're working very closely with Trusted Shops, which is a European authority already for, I think, 25 years, building those rating systems for online shops. So they have a huge amount of experience with how those work, both from a technical side, from how the markets work, legal aspects, of course, as well.
And this reputation system is currently, in their implementation, designed as a, you know, callback mechanism. So they do not interact, kind of interfere, with the transaction between the agent and the service provider, but they then ask them to give feedback. Now, you could say there is a vector for bias or manipulation. But if you have a system where multiple agent operators or agents and multiple service providers report back along a standardized, let's say, survey, then you would spot patterns of, let's say, bias towards bad feedback. Like an agent might be, by a system prompt, biased to give bad feedback. It might even say, hey, why should I do that extra round? I'm not doing that. But if the merchant then gives that feedback and says, okay, here's a transaction that happened, but we didn't get that feedback, that would all influence the reliability and thereby reputation of the agent.
But of course, it would also help you to spot patterns where you see collaboration between the agent and the service provider to kind of bias in a positive way. So, you know, manipulate the standing of the agent to have it then maybe enter transactions later on that it should not enter. And even that could then be seen by the service provider, because we'd see, okay, that agent got very poor ratings from other service providers. Or what you also would see is that agent has like 500 successful transactions with that particular service provider, but no other ones. So what's going on here, right? So at the scale, you can then see patterns beyond a single feedback loop. And that is part of how this reputation system would work.
Jose:
And I would imagine that those patterns are potentially not that different from the patterns that have been out there with humans. It's potentially just with many more signals, because the speed will be increased potentially, right? But it will be interesting to follow.
And I wanted to shift gears a little bit, to go from talking about the TSAI protocol to the collaboration with Queue-it and how we are seeing this and working together. And I would like to ask you, Moji, with Queue-it sitting as a gatekeeper for online traffic, how do you see TSAI playing a role there? How do you see it fitting in what we're doing at Queue-it?
Moji:
Yeah, that's a good question. And I think actually we covered it until now in this topic quite a bit. Yeah, we introduce ourselves as a traffic orchestrator. That's what we call it, as a gatekeeper.
And in this specific topic that we are discussing, about a specific protocol, TSAI, there is this service provider that needs to do some stuff. But imagine that everybody wants to implement it themselves. Then why not have a platform where you can put rules, business rules, and then you don't need to be a technical person as well to do that one? We know that this specific endpoint needs to have this specific access, because you have your marketing team. So what we provide here is that those kinds of personas that are not really technical — we don't have any issue with the technical people, I should say, but I'm saying that, you know, the broad range of personas or decision makers can put those rules, and then those rules will be applied automatically for you.
And that is exactly when I was reading the TSAI protocol, it was interesting for me that it is talking about that one as a service provider. So that was how we got there. When I was reading it, it was interesting. I didn't get to know Alex by that. We were working quite a lot in AWS and Alex supported us pretty well on that one. He mentioned that, and then I said, oh, that is pretty cool, and this is exactly what we are looking at here.
We talked to the product team and then they said, yes, we have this one in our radar and that is the direction we are going. Then we mentioned that, oh, why not? We also try to see what is the feasibility of this one, how hard it is for us to implement this on the edge, on the cloud, from Lambda or, I don't know, all the other edge connectors that we have. And the team that I'm working with, my colleagues — they're not here, but they did the task. And then it was pretty straightforward to do that one. And thanks to Alex and the team.
So we did this feasibility check. We are in discussion with Alex and also with the product team, that's how we can provide this one. We are thinking that, okay, there are, as we talked about, different kinds of protocols. Why not giving this capability that you can choose and get that one out of the box in your service? When you are, for example, think of this scenario that you want to show a maintenance page if there is traffic from this level of signals. Yeah, just show them that, sorry, you need to go and access that endpoint, this endpoint is not for you. So a customer can go and put the rule there, we can apply that one on the edge, and then everything will work just in an hour integration. And that is the direction we are going. We have this plan to bring this one in as a first-class citizen of the product, and we are working toward that one.
Jose:
Anything to add there, Alex, on the collaboration side?
Alex:
No, I think you put it very well. So it's amazing for me to work with Queue-it, to see the scale of traffic you're seeing and the kind of challenges that you're working on. And it's the perfect opportunity to show that something like the TSAI protocol has practical merit, because those should not be point-to-point integrations, with all the protocol initiatives we see, with the different agent solutions, merchant solutions, and who else is in this ecosystem. It is great to have partners who can deliver this once for everybody, so you have more of a hub-and-spoke architecture and have a go-to to build on that. And it's amazing to have you as a collaboration partner for that.
Jose:
Thank you, Alex. And I think we're getting close to the end. But before we wrap up, I just wanted to hear especially you, Alex, your thoughts on TSAI and where you see TSAI being today. I think we talked a lot about it, but also what do you see happening in the near future? And I guess near future, maybe before the age of AI was maybe a few years, now it's maybe more of a few months. But can you tell us a bit, how do you see it evolving from here?
Alex:
Yes. So as I mentioned, we are working very closely with Trusted Shops to bring out the first trust authority. And I'll be honest, yes, you are right. Things are happening at an insane speed right now in the industry. Some of that is probably buzz where people announce things, but it's very hard to build a real trust authority, because again, you will see it is complex. You have multiple actors there. You have a lot of attack surface, so that will take some time actually. So it will not take years, but it may take until maybe after the summer break, into Q4, to then really launch the first trust authority, but with the actual offering as a product to onboard agent operators and in turn service providers who can use those signals, verification.
And then ideally — and we're now speaking with different agent operators, we're speaking to service providers and companies like Queue-it representing service providers and building solutions for them — so we expect to see this take off towards Q1 of the next year and hopefully see large adoption, hopefully being adopted by other actors, hopefully seeing more trust authorities. So this entire go-to-market is right now very much in focus, and implementation of trust authority and other actors' technologies.
Jose:
Exciting times. And before we go into some rapid-fire questions that we always do, so we will still do them today, maybe just asking: so if we are, the three of us, sitting here in five years and we do another episode — I know five years is a lot, especially in agentic AI years. But one question: we have been discussing that it was this human versus bot, and now we're starting to dilute that barrier because it's more about intent. Do you think in five years there will be any distinction between human and bot traffic?
Alex:
I think it's a good question. It's a question you should ask. But I think it's not so much about distinction, bot versus users. I liked your point earlier about good users or good intent and bad intent. It's users with agents. And the ratio will be 1 to 10 or 1 to 50. But in the end, it will always be a user that makes a decision, or an event that has been created by a user that sets off the bot. So the decision needs to be with humans.
What will happen in the next five years, in my opinion, is — I mean, right now it's all superficial. Everybody can launch some agents and build some fun stuff. And it's okay, we're currently exploring. I think we will see more fundamental changes of the surfaces that you can interact with, due to the capabilities we have. And I think this will be happening in two ways.
So first one is more the research and checkout part of commodities. You as a human will not want to browse 50 stores for, let me say, the next iPhone. You know you want that, if you happen to.
Jose:
It's up to you.
Alex:
But if you happen to want that new iPhone, you can buy it anywhere. Different vendors have it on stock. So what is the point to decide that? And how can you offload that? It can be through agents, and it will not just be price, maybe also best shipping, best after sales. But you don't have to do that, that can be commoditized. And it would have been possible before agents — so you could have set up APIs and, you know, some scripts. But now you have a semantic layer that can deal with more deeper challenges and can do more complex things.
I think the second surface change is with very complex flows. The example I would like to give is, let's say — and this is taken from my experience — so we're planning to do a sabbatical in two years with the family. So we're planning, I think, maybe three months or so, to do a longer trip. And maybe still today as a human, I would do this, I think, more in a sequential order. So I know I want to do a list of things, and I would plan a hotel, a flight, some activities and so on, until I have my three months full, out of pure efficiency. Otherwise, I wouldn't have the time for that.
And what you can do as agent, sorry, as user with agent, is you can set an agent with your preferences and basically iterate over that. And it can kind of compose that and fill the gaps. And then if it sees the gap is not really good, you can replace those elements. So that iterative cycle, and the function of efficiency is barely how many tokens you want to spend on that. And I think this is where we're heading, and giving these different surfaces to users with agents.
Moji:
I think actually Alex put it really nicely, and that was also my example as well. Yeah, but I like that buzzword as well. Yes, if you look out there now, it's more like talks. Yeah, there is some legal stuff involved in this one: how much an agent can spend on my card, is it allowed or not, you know, all this stuff that we are discussing is out there, people are discussing the intent, am I allowed to do this. And then if that stuff gets solved, then we have a digital assistant that is really an assistant. It's not just, okay, give me this and then it gives that and then you need to do. So it's kind of coming one abstraction layer higher: I want this, I want to go to a trip, and this is, you know, just go look at my calendar, look at my icon, look at my preferences, offer me the best. Even you are allowed to do a purchase.
Yeah, but this stuff, I'm saying, kind of goes back to this trust and I would say identity. You can put identity in any kind of concept, but these topics will come, you know, upper and upper in this level: that if it's allowed to do that, it needs to say that I'm allowed to. So there is a trust, there is identity, which will be the hot topic in this market, I think, actually. And exactly what you mentioned, I'm also envisioning something like this. That would be a nice place. Maybe actually in five years, our agents will talk to each other.
Alex:
Oh dear, hopefully not.
Jose:
And I think you mentioned, it's interesting that having a digital assistant, I guess it's one or ten or a hundred or a thousand. And back to your point, it actually depends on how many tokens you want to use, right? So I think that's the parallelization of work and research and all that. But probably I would think that in five years, a lot of the stuff we can't even think about yet, because it's so out there.
Okay, wrapping up. We have always some rapid-fire questions. The first one I would like to ask to both of you: do you have any recommendation for the audience in terms of — could be a book, a podcast, a thought leader, ideally within this area, but could also be outside. Is there anything that you would share with the audience?
Moji:
Yeah, it's a hard question. But what I do is that I usually follow these kinds of protocols and see the updates. And usually then I use, again, the agents, AI, to compare them for me. So then from there, I get the links to be able to get more details. Usually when I want to learn about this stuff, for me, the comparison is the place that I could learn how they fit together, how is the relation between, for example, TSAI to AP2, how can I play with these two together. And that is the way that I do it. So for me, it's the method of the search that is something interesting in this topic.
Jose:
Thank you. What about you, Alex? Anything?
Alex:
Yeah, there's a lot of good stuff out there. There's also a lot of, let me say, air-quote experts, and there's no shortage of content. There's one person I really like reading. His name is Luca Mezzalira. He combines those traditional architecture, mastery, excellence skills, and has contributed a lot, for example, to micro-frontend architecture and other areas of good architecture in a broad sense. But he also these days shows how you can kind of merge this with agentic properties of the development systems themselves, obviously, but also how they play out in real time. And I think his work now sets the scene for good agentic systems that are going to come in the next few years. So if you happen to read his Dear Architects newsletter, I think, and he has a few online formats as well, that's time well spent.
Jose:
I'll have to check it out. Thank you. Final question, one for each. Alex, to you, scalability is?
Alex:
Not just throwing infrastructure at problems as they grow, because there are emergent properties that need to be addressed as such. It's different challenges, but also new opportunities. So look at them in the scale that they created.
Jose:
And Moji, you already answered what scalability is in one of your previous appearances. So you'll get a slightly different question. To you, trust is?
Moji:
That's a good question. You do what you promise to do.
Jose:
Again, Alex, Moji, thank you so much for being here. It was wonderful to have you both on.
Moji:
Thank you. Thank you so much.
Jose:
Thank you. And that's it for this episode of the Smooth Scaling Podcast. Thank you so much for listening. If you enjoyed, consider subscribing and perhaps share it with a friend or colleague. If you want to share any thoughts or comments with us, send them to smoothscaling@queue-it.com. This podcast is researched by Joseph Thwaites, produced by Perseu Mandillo, and brought to you by Queue-it, your virtual waiting room partner. I'm your host, José Quaresma. Until next time, keep it smooth, keep it scaled.
[This transcript is auto-generated]
Â