Agent Observability: Monitoring and Understanding Agents at Internet Scale

Hi, everyone. I hope you are super excited for the afternoon session and sufficiently caffeinated. My name is Daniel Nadasi. Our agents are up to no good. They are doing bad things, and they potential have the potential to do many more bad things. Hopefully, they're doing some good things as well. That would be much appreciated, but they are definitely and categorically doing many bad things. We also have lots of agents.

You know, I will not speculate as to how many, some of that will come out in the talk, but they are you know, we we are absolutely lousy at Google with agents. They're just everywhere, and so we have problems on account of these many agents doing bad things. And hopefully, this is resonating with some of you. I'm betting some of you are in companies where you're feeling roughly the same thing. So the challenge that I want to talk about today is not just how you set up observability for one agent, which is definitely a worthwhile and and and sort of challenging discipline in its own right.

But how do you set up observability so that you know what all of these agents are doing in parallel at the same time across thousands or tens of thousands of agents? Clicky. Come on, clicky. There we go. So I start most of my talk with the same sort of warning, which is Google is, you know, not the average company. We are extremely large in a few dimensions, including the number of people that we have working on things, including the number of software engineers who are actively developing agents and developing code, also in the terms of the sort of number and the scale of the products that we And our scale has one particular implication, which is we also tend to develop a lot of things in house in terms of the frameworks and the platforms that we build on top of. So I'll tell the story about how we as Google are solving these problems, But, you know, take what you will from this talk from this talk.

It's it's fairly likely that our story is not exactly portable to to your situation, but I believe there's some durable lessons in here. Alright. So as I said at the start, our agents are up to no good. But let's sort of dive into exactly how this how this pans out.

So my primary motivation for getting involved in a lot of this work in our context was was sort of security and looking at the damage that agents could do. But there's a whole bunch of reasons you might want to invest in observability for agents. The most obvious, I think, is if you are building an agent, you want to know what it's up to.

Right? And they might do this for the purposes of debugging or understanding whether it's adhering to the sort of task completion metrics that you've set up for your own agent. But you might also be interested in observability for other reasons, and that includes, you know, compliance and governance. If you have certain guarantees that you want to provide for all of the data that you are processing, and you wanna make sure that in your agentic workflows, you are making those same guarantees and they're still adhered to as for regular software, then you are also interested in in in observability for that reason.

If you're an end user and you are using a company's agents, you might be interested in observability so that you know what the heck the agents did with your data or did with your request and whether it was successful. And then you get into the space of, say, you know, AI and ML core development. If you're interested in, say, closing the agentic loop and and retraining or things like this, then you're interested in making observations about agents as well. But as I said, there's lots of good reasons why you might get involved in this.

There's also security, and the agents up getting up to no good, and that includes behaviors such as your agent might be trying to exfiltrate data, your corporate information, getting it sent to the Internet. It might be trying to take down various jobs in production. It might be trying to expose security vulnerabilities and things like this.

And the reasons why this might happen are pretty varied. It could be because your agent is being instructed by the creator of the agent to do nefarious things. It could be because a user is trying to do some sort of prompt injection based attack, and therefore, you know, manipulate your agent into doing the wrong thing. Or because, bless them, our agents have some sort of semi autonomous kind of thing, your agent might just think that the most creative way to solve a problem and the best way to solve a problem is to do something that we would consider not so great.

Hey, agent. I'd like you to make sure that you run always run this job in production. Oh, but there doesn't seem to be any, you know, space or any production quota. Well, I'm just gonna take down every other job in production so that we can make space for your job. So thanks, agent. You've just created a massive production outage.

So there's lots of different reasons why you might get involved in observability, and one of the complex parts of this discussion is is sort of navigating all of the potential things that you might wanna do here. But the interesting observation from starting to unwind this is a lot of the data that you actually want to retain about what agents are doing is common.

You can you can and you can kind of sketch it out. You wanna know, you know, roughly the prompt, the chain of thought, what tool calls were made, what permissions and scopes the agent had access to, when all of these things happened and the sequence that they happened in, and, you know, a canonical set of identifiers for identifying, you know, the conversation ID, the agent ID, and so on.

So I'll sort of run with the example of security for the rest of this talk, but I think one important thing to keep in mind is there's actually a lot of common observability based patterns that fall out of the same solution set that we're talking about building here. Alright. So we've talked about sort of what the nefarious things are, but let's talk about the space of the agents themselves and how you can do this.

Because one important thing, especially if you're optimizing for security, is you can't trust that you you you can't leave gaps. You can't leave major gaps in your agentic space because otherwise, you know, it only takes one. If one agent is doing a particularly bad, particularly nefarious thing, then, well, you know, you're you're stuffed.

You can't you can't do much with that. So in order to do that, we need to enumerate the space of agents. Now I assume, based on the talk so far today, this is probably accurate. Most companies have a have a pretty robust and wide ranging suite of agents that are taking action in various ways across their company, and that includes, you know, software and coding agents to help software engineers develop code. It includes computer use agents.

It includes things that are sort of like classes like corporate enablement agents or work work enablement agents that are, you know, acting on email and spreadsheets and documents and all of this kind of stuff. But it also includes agents that are in our products, you know, chatbots and etcetera, which are which are, you know, talking to our back end systems. And it also includes things that people are creating kind of ad hoc.

You know? They're going into a system. They are, you know, going in going into Claude code and developing, you know, an agent that fulfills a particular need for them kind of day to day, being very creative. And that's not just software engineers. Right? Especially with, you know, agentic development UIs, it's very, very easy to go into a a UI and click a button and have you know, say, I wanted to access these these these in in these scopes, and now, you know, my agent is ready and fully autonomous. I provide a system system instruction, and then you're you're ready to go. Right? So it's very, very easy for these agents to proliferate. And compounding this, you think about the observability problem.

If this is the space that we're dealing with, how do you even know what the totality of agents are? For those of you who remember Jeff's talk from earlier today, an agent is essentially a loop glued to an LLM and glued to some tools. So it is very, hard if you've got a billion line code base, but even if you have a substantially smaller code base, to distinguish the general code that you've got going from the from the space of from the space of of agents specifically.

So how do you manage that? How do you actually disentangle the agentic stuff from your total production surface area and total corp surface area? And how do you do that, importantly, without crushing yourself under a mountain of data, without forcing teams through a sort of super onerous process? For those of you who saw Hamish Songsmith's talk on on governance earlier, you know, you don't wanna send teams a 200 question questionnaire to have them register every agent that they're doing just so that you can know what agents are up to.

Right? Okay. So let's move into how we solve this problem. At Google, we have a particular way in which we approach development. It is not super unusual, but it is incredibly load bearing. And that is we don't let our developers do everything. Right? And so partially, we mean this in the regular CSO sense of the word, You know, there's a corporate firewall, and it limits some actions that you can take.

You can't install arbitrary software in arbitrary ways on a corp device, and and so on and so forth. So the usual stuff. But actually, I mean it in a slightly different sense in this case, which is also we don't let software engineers make arbitrary or we don't encourage, I should say, software engineers to make arbitrary decisions about what platforms and frameworks they use in arbitrary ways.

And there's a whole bunch of reasons for this. Right? Including economic ones, you don't want to necessarily purchase licenses for everything for every possible kind of database. That's that's definitely true. But also, you don't want the proliferation of different ways of doing things, which makes it extremely hard for people to reason about what what what things are going on.

So this means that more or less for every possible software engineering problem that an engineer could imagine solving, be it data storage or data processing or building an ML model, there's only a handful of ways of typically recommended ways of doing it. So this ends up being extraordinarily load bearing, and here's basically how we solve the core of the agent identification and logging problem.

Okay. We use the uniformity of our developer ecosystems and tools to our advantage. As I said earlier, an agent is more or less a loop glued to an LLM and some tools. So there's three things you could log. You can log at the loop level, you can log at the LLM level, and you can log at the tool level.

You know, this sounds kind of dumb, but, like, as far as load bearing insights go, it's it's it's pretty meaningful. So at the loop level, you have typically an agent framework of some kind. Most people, when they build an agent, are either building directly on an agent framework like ADK or building on a layer that's somewhere grounded on one of those frameworks, which immediately gives you some really important logging points.

You can hook into those agent frameworks, which all have, you know, various various hooks for these things, and say, okay. Well, I'm going to make sure that everyone at my company every time this this framework is instantiated at my company, I'm going to log a certain amount of information. And we already talked about what kind of information that is, but that's things like the prompt and the user ID and so on and so forth. A lot of sort of e mark for data protection here, which which I'll get back to because that's that's very important. But for now, just bear with me.

You so you log all of that stuff by default. If someone's building on it, you you've got those logs. And you log basically important metrics that you care about, how many tool calls were there, how many you know, what was the agent ID, things like that. And you log as much as you can, like, of the actual full trajectory. Every of the entire conversational sequence, which back ends it went to for the tool calls, which back ends it went to for the LLM, and so on and so forth, using standard tracing methodologies. You do some amount of canonicalization because you don't want to have various different ways of doing this in different frameworks, and you put it in a central data store.

None of this is rocket science. Right? The incredibly load bearing piece here is that we are doing it once for each framework, not once for each team, and not once for each agent. So that is the secret source to making it actually scale. Importantly, this now becomes extremely efficient to implement, which means we can partner with a whole bunch of teams to get get all of these things rolled out relatively cheaply.

And teams love it because no team is gonna tell you no agent developer is gonna tell you, hey, I hate the idea of, like, having better security or I hate the idea of having better observability. I hate the idea of having better debugging. But they will say it's not the top of their feature stack rank. Right? And what you're gonna tell them is, well, you're gonna get it for free.

It's gonna be automatic. It's gonna be easy. And it'll just bring me back to the sort of e mark for data protection. There is a bit here where you have to be very careful. If you're logging anything by default, that's data retention, you know, and data retention can be ill advised in certain cases. So you wanna be extremely careful about about retaining too much data if you are obligated not to or if you're violating user expectations and and so on.

That is a solvable problem. You just need to have the right conversations up front. And teams might ask you about it, and you can say, yes, we're prepared for that. Alright. So that's the load bearing bit. This doesn't get you everything because there are gaps. Let's imagine put yourself for a second in the shoes of a malicious person.

Are you going to use the recommended development workflow for implementing your agent? Probably not. Right? And so in the worst case, are there gonna be gaps, but also people are just not aware of the recommended workflows or they're being creative and and finding work right, or they're just trying something. Right? So I told you already, you can log at three places.

You can log at the loop level, which essentially the framework manages, or you can log at the LLM level and or log at the tool level. There's two ways of doing each of those. One is you can log on the receiving side, and two is you can log on the calling side. If you are lucky enough to run your own LLM, as Google does, you can do this for the LLMs, But for the tools, many of the times where important corporate information is being accessed by an agent, that information or that service is managed by your company.

Right? So here's one anchor point you can use very concretely. You have to solve the problem of how you connect the agent ID between your loop and your tool. You have to pass it through because otherwise you can't deep duplicate the logs. But again, this is a solvable problem. And then you put it in the same format and unify it with the with the same logs that you made before to put it in your wonderful data lake so that you can perform analysis and then understand what your threat model is.

So that works. If that doesn't work for you, if you don't happen to run your own LLM but you want to do logging on the interactions, for example, to catch things where people haven't built on a framework, then you log on the calling side. And that's a little trickier. Right? But in most cases, when things are running in production or when things are running on people's, you know, corporate devices, workstations or laptops and so on, you have some kind of endpoint anchor that you can use. Right?

H t outgoing HTTP connections, outgoing RPC connections, and you can do use those as the anchor. I've kind of gone through these in decreasing order of fidelity. So one concern here is that as you go down this ladder, you get less and less detail, but that's manageable. Right? You can you can you still get valuable information, and again, as long as you're passing through the right IDs, you get extreme telemetry. And by the end of this, there's still gaps, but the gaps are, you know, progressively, which each each stage of this methodology, much tinier and tinier.

So you end up with a vanishingly and increasingly small fraction of of the surface area of possible agents not being tracked. You end up with a wonderful database and data lake of of of invaluable analysis that can be used for putting in place controls and things like that that you didn't have before, and you can be relatively confident it covers close to a 100% of possible agents at your company.

Alright. The role of controls. This is not to talk about how to implement controls. I simply do not have time, but I will put one thing in front of you, which is, if I haven't stressed it already, limiting the number of ways in which people can do things is very load bearing for a great observability strategy, which means controls have a role for observability as well, specifically.

For example, if you don't allow people to connect to a certain LLM or you don't allow them outgoing Internet connections of a certain kind, then your observability job gets a lot easier because you don't have to observe those things at all, or you can observe those things purely for the purpose of validating that the control is working.

You don't have to say, oh, I'm afraid of all of these agents talking to this LLM that I don't like. You simply, you know, assume that they don't exist, or you can validate that they don't exist using observability. And that, again, is extremely load bearing. Come on, clicky. You can do it.

Alright. So just revisiting. You anchor you instrument the framework. You instrument the endpoints, and then and you use controls to control the surface area, controls and guidance for your for your engineering base to to limit the possible ways in which agents can be developed. And together, this gets you an agent sort of observability strategy that can then power whatever security insights and things like that that you want, detecting the lethal trifecta.

Now, possible because you have agents logged with all of the attributes that you could possibly want. I think there's a few lessons here that that are are really worthwhile. Number one, agents are, you know, fundamentally able to be developed in such a rich and dynamic amount of ways that having that developer guidance, which I think is a good idea generally, is ends up being extremely load bearing.

Secondly, the importance of not trying to get to a 100%. I think this has come up to a few times in in previous talks, but there are a very high number of variations that can be possibly manifested by your agents. So you will never get to a 100%, but you can get to 80% very, very easily, and you can get to 98% very, very easily. And so using those diminishing returns kind of kind of methodologies to get each fractional improvement is very valuable too.

The last thing I'll mention just before I step off is one problem I haven't talked about is data volume. As the number of agents at your company explodes, say because people are running 200 coding agents at the same time, the data volume of this log space also explodes. Right? And so one thing that is manageable at the start but then becomes rapidly less manageable is how to manage that data volume.

And we're just at the start of that journey, like we're coping with the data volumes for now, but maybe I'll come back next time to talk about how we solved that problem. Thank you, everyone.