OnDemand: When Your Users Are AI Agents: What Breaks in the Data Layer transcript

Hi everyone. We'll just give everyone a few minutes to join in. >> Hi everyone, thanks for joining in. Welcome to today's session. When your users are AI agents, what breaks in the data layer? I'm Nvana and I'm a content marketing manager here at TidyB. I'll be your moderator today. Agent traffic doesn't behave like human traffic. It bursts unpredictably and creates and destroys resources constantly and that's already changing what platforms need from their data layer.

To dig into it, I'm joined by Lucia Chen, GM of Apac at Diffy, who works directly with the teams building AI applications across the region and sees these agent patterns firsthand. And Terry Purcell, field CTO and chief optimizer architect at IDB, who spent decades in database and distributed systems work and now spends his time on where the traditional data infrastructure breaks down. Thanks for joining us today. This is a fireside, so no slides, about 40 minutes of conversation, and then a live Q&A.

Feel free to drop your questions in the chat any time, and we'll answer those at the very end. Let's get started. So, Luca, let's start with you. For anyone who hasn't come across Tiffy yet, give us the quick two-minute version. >> Sure. Um, thanks, Naan. Um, thanks everyone for having me here as well. Um, so my name is Lucia Chan. I'm the general manager for the ape region for defy. Uh many of you probably um like hear about defy from the community um you know especially from GitHub or discord about us and we are right now I would say the top uh workflow and especially for the orchestra layers um for AI um right now on GitHub and we have actually more than 150,000 likes on GitHub and which is actually a really big blessing from the community and we are actually the workflow which connects the uh large language model and then for the rags and etc for the data layers and then to help build the um internal applications for the enterprises.

Um and then many of our clients actually ranging from um you know like China, the US and Japan and Europe etc. We have more than um 200 clients right now globally and then mostly are like multinational companies uh which want to use the AI especially for internal uses and for their external uses for the clients. So thank you for having me again. Thank you, Alicia. So, not long ago, the you users of an AI app were people.

Increasingly, the user is now an agent, still set in motion by a person, but acting on its own once it's running. Was there a specific moment when that shift became obvious to you? Um, thanks for bringing that up. Um, actually starting from October last year, we started to feel like the trend of Agentics uh becomes very very popular. So like when people are talking about the agentic and talk about a sandbox for a workflow and would realize that okay um there will there will be a shifting time for the agents to come to exist and it didn't until it wasn't until um late February this year that um like with the existence of open claw and then also with a lot of the desktop agents come to exist starting from May um like we realized that oh wow this is like really big trend um so we we uh also we noticed that from um like the triggers.

So before it was the human triggers. So it was like one way and single clicks you know on that but however it becomes more like schedules web hooks and then later on the other agents since um I think since February this year especially and then we realize wow it comes to an era that the workflow and and agents are kind of a combined working models or many of the times that the um especially the desktop agents will become the main ones to initiate the whole workflows.

So um that's where we see the time to come to exist and also um a lot of the clients come to us and be like um Lucia we use the workflows especially for our I would say the internal employees but usually will be the product managers or um like the middle layers for the IT uh development departments etc. But with the agents come to exist more and more end users also come to the table saying you know HRs, finance, legos or you know anyone like every every single users in one company everyone is involved and then um the agents start they start to ask questions what can I do with this you know desktop agents how can the workflows be combined to it how can the SOP that I already built up um you know by workflows to be combined with the uh the desktop agents.

So we like keep coming across this questions and so that's why the agents issues become really really important to us right now. >> Mhm. >> Got it. And Terry picking up on that if you put a week of human traffic and a week of agent traffic on the same graph what does the difference actually look like? Describe the shape for us and where does Asian traffic go that human traffic never did? >> Yeah. So if if you pick apart what what Lucia was saying there, there's this influx of new users that we weren't previously able to or that we may not be able to predict today.

So in a word really the the difference is predictability. Humans had predictability in when they were in control of the application and the design of the application. So a weak in the usage with agents is very different in the week of the usage of humans because it's unpredictable um what the users will now do. So where does the agent traffic go that the human traffic never did? Um again it's outside the bounds of where humans had a defined lane of their usage and humans had again um you know humans behave like humans and humans were designing the applications.

So humans knew on the application design side in the infrastructure management side they knew if they we had any latency gap between say the OLTP system and the OLAP system and then we designed the application to tolerate that there's an ETL process. So you know the design was there because the humans uh created the applications and the infrastructure. We also knew the humans what what scalability um limits we were going to hit.

We could predict you know next year we we hope to have 20 to 30% year-on-year growth and so we need to provision our systems uh for that increase in activity. So that has completely shifted from predictability to unpredictability. you you know there's that it it was predictable and deterministic and now it's unpredictable or even non-deterministic and the designs and usage. So that's the the significant difference that you see in a week um that predictability and now the challenge is that human application teams are trying to identify how to predict the unpredictable user experience >> right so Lucia this unpredictable user experience you're watching this play across a million plus applications what is a read on agent behavior that almost nobody else gets.

What's the one thing agents are doing on Diffy that nobody on your team designed for? Um, sure. So, basically I think because agents are, you know, unpredictable as uh as what Terry just mentioned about it and then um because it you know like imagine uh we always like compare the like the behaviors of agents and human beings. So the agents will actually work like 24 hours a day and it's long you know context and then they can actually work long time you know um and then it would just like fenced out and everything would just comes out you know like in one just once like the QPS you know all the queries will actually go up very quickly before I think the performance of DV DV was also you know coming across like a lot of issues sometimes because when we are actually in the production level um like the queries already go up very easily like you know several hundreds you know like times queries very very common.

However, if it comes to like the agents it could be more than 100 or you know 600 can be like easily go up to 6,000 queries sometimes like that and um especially in this area like a lot of the companies would design the OP chart of the of the agents to be a special system to one employee. So saying if the company has like 10,000 employees for example like Walmart is kind of like very big companies the multinational companies they want the like the AI applications to be used by more than 10,000 people at the same time.

Now could be 20,000 uh like you know 20,000 people plus agents at the same time. So originally it was it was a very kind of I call it a chaotic time that agents just become like very popular and then it was just there. It's like my special assistant. It's my own agent. U however, so that's why like the quer is you know comes across from human beings and agents all got combined. Um oh already someone asked like does DV replace the need to build your own agent work compliment.

Oh okay I'll mention that later. Thank you so much for bringing that up so early. Um so that's why like um uh the queries now becomes very very serious issues and especially when it goes to the production level. um you know the SA would combine with the SAP datas you know all of this different data layers comes to the same time and then the the queries or you know just the pressures or kind of the infrastructure um the things that we are facing are getting more and more serious so that's why starting from uh March this year we are um we're seriously thinking about you know adding more runtimes and then to actually place the agents in different containers and so that to actually meet the querious issues uh but also we are um you know uh trying to this is actually very interesting innovation and also the compliance are always like you know two parts of one coins uh of one coin and then uh we are actually adding the the RBAC the role based access control um to not only the agents to APIs and also to applications to every single users because inside one company what the what the like decision makers want the most is first of all visible um visible workflows visible behaviors of everyone like including the agents.

The second thing is to actually to monitor it um and then to control it. So the role based access control become very very crucial to us and we are you know we are what we're doing is to row base the rag uh what role base the applications however the layers are not enough. So the the clients keep asking can we row based also the agents can we row based you know even one sentence in one documents so that you know people will be controlled or you know can be monitored you know like the behaviors can be monitored so the audi log is definitely not enough um because the audi log can be it's just a traceable documents it's it cannot stop you know things to happen from the beginning so that's why I think um especially in the era of all the AI improvements the control thing you know the the other part of the the other side of the coin become very crucial is how can you know how can I you know to face this queries and then second thing is how can I actually be more compliant and more secure yeah so these are the two parts that we never foresee before like because we always want the innovation part but however we becomes the other side so this is something very interesting yeah >> right um so similar to what you said about the audio audit trail.

Lucia, what are the builders coming to you and asking for now that they weren't asking for a year ago? Um, I think I because like Selva also asked about it and and I'm going to comment on that as well. So like because I feel like the questions are being related. Uh people always ask like you know um the they ask like for now it's what's the difference of agents and workflow? When is the time for me to use workflow? when is the time for me to use agents and if I use workflow or I use agents um how can I tell this is not a PC but it's actually this is not a prototype how can I put that into production and how can I you know um all the data and also um the compliance issues can be secured something like that so um we when we talk and when we practice more we realize that if the SOP can be fixed and if you know like things can repeat itself and then need to and need no change you know especially in one company all you need is like to find out what's changed and what's not changed so something that's not changed best for workflow best for SOPs like tokens consume less uh like human you know more visible and controllable and that could be you know reiterate by itself 24 hours non-stop and but however if the things needs you know creation um needs and you know um I cut it like um it's kind of like the continuous uh prediction or continuous imagination um that needs to be done by the agents because the AI would actually be able to give you all kinds of result you want for example like sales or marketing um what else um uh you know or you know like um what's the negative effects of you know one medicine you know the AI will actually give you all the outcomes all the results that you want and that will be the best things to be done by the agents um and Then um so the what we see is the combination of the workflow and agents would be the best.

Now it comes to the time is like the clients always ask new questions. They would be like, "Okay, Lucia, then what what is the entry point for me?" Like um should I go for desktop agent first or should I go to the uh workflow first and then initiate my agents because the new function that we designed uh we not only just designed the the multiple runtimes. It's called a reprunner. We also designed the one that is called the um the agent notes.

Um so we we can actually initiate the agents in the workflow different agents in the workflow so that agents can also be like human beings to be in the human in the loop. Now it's the agent in the loop. Um so you know like and it's it's very interesting people are still um like I would say the products are still trying to fight for the entry for the clients. what we see more is definitely the desktop agent because all like HRs, finance or you know everyone is easy to understand the desktop agents.

Uh but the most important thing is to have the workflow as the backup as the skills or the harness for the agents to work things um in a certain path. Um and then I think it's a very important thing especially for the enterprises to again visible um be able to monitor and controlled so or managed. Yeah. So um that's why I think the combination of workflow and then agents are very important and also that's like it's not replaced but also um I would say it's always a ongoing kind of revolution thing or you know improvement thing.

Yeah. >> Got it. Okay. So Terry, let's go one layer down. Most data layers running today were designed around assumptions about how users behave, how many, how fast, and how long they hold on to things. When the user becomes an agent, which of those assumptions breaks first? And when it breaks, what does the team running it actually see? Is it latency, lock contention, or is it just the bill at the end of the month? >> Well, the scary part is always the bill at the end of the month, but it could be all three.

And and if we even take a step further back to that question, um as the data layer, often we're not involved in the design of the database or the design of the application. So I if we think about something like lock contention if you let's take a multi-tenency application if you cram all of your tenants into a single database then as you add more users the agent being a user you start getting into data scalability problems and you're more likely to run into potential lock contention because they're all competing for the same database table.

Um if you designed your multi-tenant application like giving your agents uh their own database every time now you get into an object scale problem. You know now I if I grow to millions I've got millions of objects in the same same database. You're not you know now you might have lock contention in your uh system tables as you're you know adding more and more um or or competing to to add more and more objects. Um in other implementations you're giving uh each agent or each tenant their own uh virtual instance and then you avoid those contentions of agents competing against each other within so not getting things like lock contention but you still have the concept of um system level noisy neighbor uh and so forth.

So it still comes down to you know this theme we keep keep going through which is predictability versus unpredictability. Um but also at the data layer we are somewhat constrained by what the database design is or what the application design is. Um so again you know Lucia and I have sort of littered through our answers this topic of humans versus agents and with humans we based upon the application design implementation we we could predict uh which would break um often as I'm saying that of course um humans might be creating the framework for the application like for diffy and then it's agents that are using it.

So again, the challenges or what breaks um can be dependent on your design. Um but again, predictability versus unpredictability. What breaks in hum with humans in the loop we could predict. And I mentioned earlier, you you might predict your forecast sales growth. And so you provisioned your systems um you know and and set variables and so forth to account for that growth. Now you don't have that predictability. So again agent traffic breaks all of this.

Then it depends okay what are your resource and concurrency control mechanisms. For example, if you scale very rapidly, then often you can deploy more uh more clusters, more resources, more CPU, uh more nodes, but that often takes seconds to minutes for that to occur. So then you're looking at what are your resource control and concurrency control mechanisms in the data layer to slow down traffic while you provision capacity.

But again, even if you have these mechanisms to resolve these types of uh bursts of workload, um can you accept the bill at the end of the month? Right? Cuz if you keep growing based upon millions and millions of new agents, then that's the bill that hurts you. So again, predictability versus unpredictability. Um and typically humans in the loop have to ensure that they account for again the scariest one at the end of the month is the bill at the end of the month. >> Right.

So Lucia from your seat can you walk us through a case when a customer hit exactly that? What did the team think the problem was before they worked it out that the data layer was the problem? How long did it take to get there? Usually I think um like bugs report are the most frequently things to come out and sometimes it would take you know um I think the its or the operators to to detect the issues for about like sometimes the longest one can be like one or two days um but the data layers issues can be very unified like or very like general you know um like issues happening the most but um because also in the era of AI everybody loves to install things on prime or open source, you know, like it's it's everything is very open.

It's not like before it's on cloud. It's it's the if it's like web two like we call it like the web two era. Everything is kind of the streamline and then there are things you can you can check but right now with open source and with A and B and C um and install on prime things are getting more and more complicated. So sometimes it may take you know at least half a day or one or two days and usually the issues will come up the most in the night which means you know a lot of developers will actually burn the burn the oil to to run the whole night to actually figure the is the figure out the issues.

Um so that actually is a very very common thing for many of the clients and we always do like Saturday or Sundays is like you know the time together and trying to figure out the issues and especially with the issues will come out like more when we upgrade it uh when we upgrade the the the SAS and then all the things would come to come out the same time. It's not only just the data issue but it's always the biggest issues if it comes to data.

Uh the second thing would be like the mo u I would say it's abuse issue as what Terry mentioned. So um especially right now like tokens are immediate actions right you will actually able to see the tokens went up like crazy immediately and everyone is trying to what I hear the most is always resets like reset in the night reset in the night like what's what's going to be the new thing so in like for the company like um for especially the enterprises the ones who are procuring these tokens will be the one who really wants to see where are the issues so that's why they are building up this dashboard especially actually trying to have all the it's all traceable.

So um as what I can see from the vaccine someone was asking about the questions you know the audi log is just the last step right um so they're building up the dashboard the management dashboard to be able to see um you know we call it a runtime management board uh dashboard so they will be able to see the tokens consumption they'll be able to see you know whether there are bugs or you know like report somewhere at least they can see from the like the the codings um and then they want to make everything to be traceable.

So nowadays um what I'm trying to recall the me I think it was thermofficial like once during the weekends. It's it's all about the bugs and then um because they're trying to upgrade the the tools during the weekends and then we just we we take like two or three days to actually work together with them like our engineer um that like the engineers team the SA teams are actually working with them trying to figure out issues and a lot more clients what they are asking is they want a unified dashboard to be able to recognize all the issues in one single dashboard.

Um so they it's kind of very interesting because um for the product itself there will be a product native dashboard uh but the company always have so many different metrics that they will actually build up their own dashboard. So it's so what we what we are trying to learn from them is um you know what we're also trying to help them is like we are increasing like we're also trying to build up a a full-fledged dashboard but it would never be enough for especially for enterprises because every metrics are different in every enterprises.

So um we're trying to bridge the gap but I think the dashboard issue the management dashboard is super crucial for every company that it's it's always a self-developed or it's a product native. Yeah, >> got it. Um, so Terry, what does a data layer that was actually built for this do differently on memory state and handling a burst? And if a team handed you their architecture tomorrow, what's the first thing you'd look at to know if they're ready?

Yeah, I if I was to look at where they're ready um the term that I'll use is blast radius for um for for bugs for application performance issues. um you know and and I'll also piggyback on something that Lucia mentioned because because my hope of course when you have that unified dashboard um my hope always of course it's not the data layer that is at fault there is a bug in the application so but you know you need to find where so let's say it is the data layer um that is the problem and and of course I've been talking about things like resource control and you know sort of alluding to um resolution of lock escalations these sorts of things but still as Lucia mentioned bugs can occur or or poor application design can expose behaviors that welldesigned human applications didn't uncover.

So sometimes it's not bugs, sometimes it's even just usage patterns that humans didn't previously expose or humans compensated previously. Right? So so back to your question, what do I look at? Often I'm looking at the blast radius risk of a problem. Like for example um there's a balance between um packing more and more um tenants into into fewer clusters. Um you know when you have that situation the more you isolate things blast radiuses are limited to that you know just sort of that um isolated unit. the more you consolidate then you do rely more on the sophistication of the data layer the sophistication of the infrastructure.

So again getting back to the question I look at blast radius like for example example Luca much earlier in the discussion was talking about the number of queries coming in could be a massive burst and then the latency of those queries. If I think about blast radius and I think about database design, back to my multi-tenant example, if you have if you have 10,000 agents, 10,000 tenants and you've randomly clustered your data, randomly distributed your data across multiple nodes, then the blast radius, if a query optimizer chooses a a poor plan, your blast radius is because the data is scattered everywhere. where you could scan every single tenant to find the one tenants's data that you want.

If you've recclustered the data around the tenant, then a poor plan choice, the blast radius is a stand size of that tenant. So, we can look at database design to see and then system architecture to look at, you know, if if resource control doesn't do do its job. um if the lock escalation mechanisms fall to to sort of a degraded plan, what is your blast radius? So poor designs again were typically caught by um by users or humans in the loop.

Um again, sometimes the agents are taking control of the full design. sometimes like in in Diffy's example then they're often presenting a design that then the users or the or the agents exploit. So humans do have some control. So blast radius database design system architecture design but Lucia also keyed on a a key topic which is observability. going down to the data layer. Lucia is obviously trying to look across the whole application stack and then find well okay I found a problem in the data layer even then within the data layer we need um you need to have good observability to find out which which part of the data layer is it an is it a a a query latency issue is it a lock escalation issue um or some other type of um threshold hold that was exceeded and then had a flow on effect to slow down other uh other queries or other agents.

So the last part of my answer is really about observability and then the part about observability who takes responsibility if you've identified a problem. Is it the is the agent then resolving or is it the human? Right? So that's the other part to think about um as part of your application usage of the data layer. >> Um okay, so let's just zoom out a bit to close. 12 months from now, what's true about agent infrastructure that isn't obvious today?

And could you name one thing you tell a builder to do this quarter? Um Terry, would you like to start? Yeah. So, we all know predicting 12 months out is is difficult, right? We we we didn't predict the the success or the acceleration of LLM this year. Um we didn't predict that the that the frontier the gap between open weight and frontier models would close so rapidly. uh even a week ago we weren't talking about or a week and a half ago we weren't talking about moving to like predictable models like JV so things are moving so quickly but if there's one thing that I would tell builders is Lucia and I have actually been implying here that what agents are doing is just the same as what humans have done cuz hum you know it's basically human behavior that is what what has been there to train the agents.

So learn from all of the mistakes that IT users and and application teams all the mistakes they've made over the last 20 30 plus years. Um and don't make the same mistake because you don't have months and years to redesign um or alter your application, your infrastructure in the pace that we move today. You just you don't have that luxury. For our enterprise customers, often they're looking at their two two-year plan, three to five year plans.

We don't have that anymore in as agents uh in in the way that AI applications are evolving. So for me the you know the first thing is learn from what the um the mistakes that enterprises have made and what is that? Well for me the outcome is is two key things. We know now that a unified data layer we used to have an OLTP OLAP vector full text search and then the application layer would stitch that back together. In the agent world, you may not understand that the latency that that is introduced in the data consistency.

So to avoid data consistency based hallucinations, don't have four or five different data layers that you stitch back together. A unified data layer without an ETL. Um ensures that data consistency is there. It also allows you to optimize in one place. Um, and you're not, as as Luca just mentioned, you know, token spend. Um, you know, if if AI users have to burn to tokens to stitch data back together from four different data sources, that's going to be more expensive than just pulling the data from one source.

So, a unified data layer is is the first message. The other one is open source. the rise and success of AI coding agents, you know, making application changes, improving your application is is so much quicker, uh, so much easier to do than it was 6 months ago. Now, imagine, you know, you want to change any part of your application stack. What about the data layer? Say you want new uh indexing techniques or new uh features in the data layer.

If you want to evolve rapidly to benefit your application, you must have an open source data layer as well. So a unified data layer, open source data layer to me that's the the lesson, the takeaway of what the mistakes that enterprises have made in the past and that's sort of the one even though it's multiple things that's the one thing that I would tell uh builders today. >> Thanks Terry. Um, Lucia, would you like to go next?

Yeah, I kind of want to turn it into an open floor especially like the conversation with Tabby as well because um Terry did mention about the open source thing and um like I I felt like it's I felt like everyone is especially like when you want to join this conversation or want like join today's live stream everyone is kind of like continuous learners of um AI and then especially like um Terry and I was like joking if this conversation happened last week we wouldn't be like so a little bit FOMO because last week we actually have Jeff JV and then we um and this week also we have the GPT5 5.5 um and I'm still testing it and um so so I think the key thing here is when a new model come to exist everything got re like changed again all the agents need to be rebuilt or you know something needs to be re you know reviped again or you know like the products needs to all you know to to kind of modify yourself and then customize it yourself so that to fit a new models.

So, we're always a follower. We're like, we're trying to catch up with the new trend always. And that's going to happen more frequently, I think, in the next 12 months for sure, just as what we are experiencing like today. Um, and then what I felt like the most is well, there was a joke in Chinese saying like if you're not learning fast enough, don't learn it because you you just catch up with it like probably six months later.

But that's not going to happen. is so I feel like in six months things are going to be changed totally. So um what I failed the most is um like always keep a a place for like P or like a sandbox you know for a a really changeable situation but the data layer as what Terry mentioned is I think a very important thing is what you can control like what the enterprise can always control there will be two things. First is data like what a company would have as a data is is is always the unique thing to this company.

It's not it's not unique to the LM. The second thing is actually the role base. So always role based or um always try to be um kind of like I I felt like this is a god's will to actually uh you know kind of review the whole organization chart in one company from the god's will saying you know someone or what which position can do what and then to design well just to do things by design instead of do it just recklessly.

So I think the um the authorization you know the role based thing is very crucial and data thing is also very crucial to control what's input and what's output. Um the other things open so uh be like be open-minded to you know all the open source new tools new all the new like you know agents comes to exist and also the LMS which is very dramatic changes all the time um that's actually what I want to u mention the most and also yesterday because I I actually joined a summit of the storage I was in Shenzhen I joined a summit yearly summit of storage um what I felt like very interesting is we are kind of in VIP time like uh we're in um we're kind of in a in um how do I say that?

It's kind of like a uh the word is called a hype time. Yeah, we're in a AI hype time. There are so many bubbles still like I feel like there are definitely bubbles. Um you know because the people are selling hot wares more expensively. You know people are trying to sell different things more expensively or with new topics. So still what's changed and what's not being changed. people always need to carry that kind of eyesight and trying to seize the things that it's controllable.

The other things um be cool minded don't be so like anxious be patient and keep cool minded to see things and try to analyze what's behind and always you know leave the small cozy areas from for ourselves to test new things and see oh this are see that did there something is quite similar you know like um I think Jeff you know someone was saying it's it's quite similar to something else you know days ago but it's just different structure or like deepseas again like deepse also have the plugins marketplace something something always you know I would say under the sun there's something not always new it's it's just like a different combination or it's like a Lego you know that people are trying to build up on you know different structures um so trying to understand the patterns and trying to you know because constants is the only thing that's instant but trying to figure out the patterns and find out what's not being changed is very very crucial and important in this era um so that's what I would always want to share with the the developers or everyone who's actually being this kind of revolution, the AI revolution.

Yeah. >> Uh the main target. Okay. I felt like people are asking. >> Yeah. Yeah. Okay. Yeah. I think um that's great. Clearly, agent traffic isn't a future problem to plan for. It's already reshaping what teams need from their data layer today. So, let's get started with the questions from our audience. Um, I think we'll start with the agent hype one, Lucia, because you did mention it. How do you tell the difference between agent hype and a real workload you should actually be planning for?

Um, maybe Lucia, you could start and then we could go to Terry. >> Uh, or Terry, do you want to start that question? Do you want to have that question? Because I feel like the second question is going to be my question. [laughter] >> Yeah, I'll take the first question. the the the challenge once you get to the data layer. Um th this for me has been true before uh at agents as users is once you get down to the data layer you know and even the further you go down imagine down to the storage layer a storage layer request is just a request for data right and then go up a level the data layer where a SQL statement comes in we really don't know whether it's pipe whether it's real whether it came from agent or whether it's just your boring banking application.

Right? So the f further you get down to the the data layer, we are just um receiving and processing the requests that come into the data layer. So down at the data layer there is no real discussion about hype. Um that to me occurs many layers above. What? Of course, you know, if you know, we we were talking about it earlier with regards to the the the cost or the bill at the end of the month. If you've just got, you know, um agents as users because it's cool to do that, you're going to drive up your bill, right? if they're actually performing a profitable function, then that you drove the bill up at the end of the month, but you also drove up your revenue, right?

But down at the data layer, we cannot tell whether it's a legitimate, you know, of course, once you've gone through the security validation me mechanism to to get into the data layer, we really don't know whether it's whether it's real, whether it's, you know, or whether it's a legitimate request or even whether the user was human or or is an agent. Yeah, I want to add on u to what Terry just mentioned is the ROI because Terry mentioned about the bills and you know whether whether there will be growth.

So the alli should be always calculated and reminded is if I if I actually you know foresee the agent hype and then whether my growth will also come together. So if if there's no growth then it's a fake then it's definitely the hype but if it's a true workload then there will be always a return. So I think that's a very sign like significant um like metrics. Um so I'm going to me like yeah I'm going to >> can I just jump in because it is kind of an obvious point that you raised Lucia that that it's it's a business model question right like what is your business model? >> If you if you make a dollar for every every agent that makes a request then say well how many could I have?

Well I want millions of them. I want billions of them. But if you lose a dollar every time an agent makes a request, you know, >> then your scalability is dependent on, >> you know, when you run out of money, right? So, so yeah, it is. And that's sort of you you raised a good point about the the hype. Um, hype um hype can be caught up in in losing money, whereas the reality is you want to earn money, right? So, >> yep.

Yeah. So, thank you for that, Lucia. You made me think of sort of how to piggyback and turn that question around. So, yeah. Sorry, back to you. >> I feel like I feel like in the future there will be a that it's what we discussed last time. There will definitely be an opt for u for for agents. You know, if if the agent is not making money, cut it. If the agent is making, >> save it, enlarge it, and make it ahead of the as the out chart.

So, >> clone it. Yeah. Clone it. Clone it and have more of those. Yes. Yes. Fire the unproductive agents. Fire the unproductive. >> I'm gonna go for for this one. Def's main target industry and then there will be terrorists issue like terrorist question. The next the main targeted industry um why is that? What value can you bring to customers? Okay. Um so basically I think DIY success u or def's um like PMF was kind of a luck because Dy was actually designed as a like open source one and then um if it perfectly fits the need for large enterprises um like the the the request what the large like the MNC's or uh like enterprises that will have the crossu uh business units uh corporation or crossber cooperation is what the fees main target areas because um the company needs a orchestra layers um management dashboard let's say they want to see what everyone has been has been doing with uh with the AI applications they want to see how every different departments are building up their own AI applications so um MNC's cross borders um of course business units are the main uh like the target areas uh right now and then the industries the PMF comes the second like comes gradually is what we have is the um the finance clients the most and then comes to the pharmaceutical uh why because they want to install DV on prime it's open source and then they want SLA then it goes to the enterprise multiple tenants white label and then it goes to the enterprise version so the finance and then also um pharmaceutical are the most ones and then gradually goes to right now the ones who has the money manufacturer and especially the high-end manufacturer for example like the storage semi um they are like very well I would say the very good clients of us uh again right because they have a very fixed SOP which can be transformed into workflow um so um that's that like that's what I just mentioned like if you can see a fixed SOP uh you know to be seen in one company and that's where workflows will be able to exist um and that's where also DIY was trying to target so like form um the The other one what we have is actually a retail uh retail and especially the retail that has a food supply chain like PNG still they have factories they have the OWTB systems you know MS WMS they have all the systems that need to be connected through this orchestra they have the datas to be extract from this systems and put uh and feed it for large range model so four main industries I would say finance pharmaceuticals retail and then also manufacturer the high-end ones Yeah.

Um what kind of value we can bring to them. Okay. Uh I felt like I already mentioned that but yeah that the the AI format of SOPs and also the large language model will be able to access that. Um um so basically the values that we're always bringing is also the efficiency um or you know like trying to reduce the redundant work the repetitive work and so that the human beings can actually be released for more innovative work or um you just to just to save their time for more um you know like business or front lines issues.

Yeah. Okay. Terry >> um Yes. >> Yeah. So yeah. Oh, sorry. Did you do you want me to read the question? Yeah. The the the next question I see on the on the Q&A is if a team is already seeing bursty unpredictable agent traffic today, what's the first thing they should check in their data layer before it becomes an incident? So, it's to me it's it's it's an it's somewhat ironic. It's a little funny, right? Because we talk so much about unpredictability and with unpredictability, you don't have data points.

So if you're already seeing bursty unpredictable agent traffic today, you're starting to move towards predictability. Now you have a data point, right? So you've got your one data point that that unpredictable uh agent burst agent induced burst. So then as you you know you look through your monitoring and you you drill down you want to look to see um what you know um you know what to me it's like when you when you squeeze a balloon right one when you squeeze a balloon it'll like pop out in one area and then you squeeze that and then it pops out in another area right so when you had this this burst you look at your monitor ing and say, "Okay, what what spiked?" Um, and from that you want to ask the question, well, was my system able to contain the spike?

And, you know, did it did it resolve it? Um, you know, did it allocate more resources automatically? Did it did uh resource control kick in and and lower the concurrency until the the traffic reduced? you know what what actually occurred. So let's say that um it was contained. So it didn't didn't require anyone to be um alerted and any any u problem to be ultimately addressed. It just resolved itself. So then you look at that unpredictable burst and you say okay what what happened what would happen if it occurred again?

What happened if it repeated more than once? What happened if it doubled in size? Howard. So now you've got now you've got a new data point, a new starting point. Then you start asking the questions like, okay, I'm starting to move from unpredictability to predictability. Um, of course, you still are in an unpredictable world world, but I would say you use that data point to then further in investigate and proactively identify um what would I need to do if that happened again? uh or it repeated or if it doubled or tripled in size.

Right? So that's um that's the way I would uh suggest people um investigate and and you know before it becomes an incident the second time or third time. >> Um so we just have one last question for Terry. Uh, in your experience, what breaks first when agent traffic scales? >> Um, I think my sanity is probably the first thing that breaks. Um, but otherwise, I think I think we've probably answered this so many times. Um it I mentioned earlier um you know what what breaks you know have you designed around growth going into a data scale problem have you designed around growth um causing an object scale problem and then you know there um a database like tidyb we've solved these issues data scale problems have been hit by Pinterest and and large large customers like that.

Object scale problems have been solved by solved for customers like Atlassian you know trying to make sure we have millions of tables in a in a single single cluster. So um what you know what breaks depends on your design point of which you know if I if I use my analogy of the balloon when you squeeze the balloon your design is going to dictate which which next pops out right so what breaks can depend on your um your your design is it data scale is it object scale is it um concurrency slowing down the system.

Um is it right scalability because you you now have too many too many rights. So again it it it really does depend on your design um and then your application what the bursts look like as to is it lock contention is it is it right scalability is it data scale etc. So so yeah it's it's somewhat hard to answer. Um again that gets back to you know why observability is key both as Lucia said at the application layer um and then down to the data layer because once you identify it's a data layer problem you then need to drill down a further level to the underlying architecture to find out what part of the data layer was the was the the trigger for the issue. >> Thank you.

Thank you Lucia and Terry for such a candid conversation and thank you all for joining in today. This session will be available as a replay so feel free to share it with anyone on your team. Thanks everyone and see you next time. Bye-bye. >> Thank you.