Two flavors of a performance “Brendan”

Several AI performance engineering agents now exist that either use or are trained on Brendan Gregg’s work. One category, sometimes privately called an AI Brendan, acts as a helper that interprets flame graphs and eBPF metrics. The other, a virtual Brendan, has been trained on his publications to produce something that sounds like a cloud-hosted copy of the engineer himself—an idea Gregg notes is “easy” to approximate given more than 90 talks, 250 blog posts, 600 open source tools, and 3,000 book pages of training material.

Gregg is upfront that this is a personal post, not an employer statement, and he won’t discuss internal project details. He also isn’t recommending any product. The distinction between the two types matters for what you can expect them to do.

  • AI agents do Brendan-like work: performance recommendations, flame graph and eBPF metric interpretation. Several exist and the general idea has real utility.
  • Virtual Brendan is trained on his publications to imitate him. Gregg estimates this would automate only about 15% of his actual job, and the model would go stale unless continually updated as the industry changes.

None of these products involve Gregg directly, and at least one has already failed—at some cost. He’s not ready to write off the concept, though. A bigger concern: some projects claim far more than they deliver. With no benchmark for Gregg’s capability, a vendor could sell a “virtual Brendan” that is little more than a dashboard with a few eBPF line charts. Gregg recalls times when his actual suggestions to projects were dismissed as too hard or low priority, which makes him suspect some companies are chasing a quick payout rather than a serious tool.

Pricing and the copy-paste problem

Commercial pricing is a structural headache. At roughly $20 per instance per month, a customer could analyze one instance, then copy the tuning changes across an entire fleet. Worse, there is no practical way to keep those changes secret—a problem one auto-tuner project tried to solve by hiding its modifications entirely. At a presentation of that product a few years ago, the audience of performance engineers immediately started brainstorming how to reverse-engineer the changes. Gregg’s own list: checksum the filesystem before and after, trace syscalls, diff every tunable and config setting, or just run the agent through a debugger if the terms of service allow it. He concludes that a tool would need to be a genuine rootkit to stand a chance, and even then, kernel-level debugging tools would expose it.

Secret tuning also collides with change control. The next company-wide outage triggers the standard question—“did anyone change anything?”—and an agent that changes production systems invisibly becomes a prime suspect, guilty or not. A simpler observation: fixes that work well eventually get upstreamed. A Java setting that yields big gains gets filed as a JVM ticket; a hardware-specific win gets pushed upstream by the vendor. Over time the agent finds fewer wins because the wins get absorbed into the target software.

That logic pushes the whole idea toward in-house or open source collaboration. Internally, there’s no reason to hide changes, and fixes can be contributed back upstream. Gregg sees that model as far more viable than a commercial one.

The analysis pricing model goes stale too

Selling analysis as a product has its own mismatch. It competes against the performance consultant model—pay one expert to analyze and fix, then use those fixes fleet-wide forever with no subscription. Software pricing that recharges monthly feels off by comparison. Even something as straightforward as a free trial is awkward: you’re asking engineers to spend time testing a tool whose return is unknown.

Building the thing is hard in its own right regardless of model. There’s orchestration, UI, logging, debugging, security, documentation, and support across different runtimes and clouds, all requiring constant updates. And ROI is just as difficult to quantify in-house as it is commercially.

The blame and IQ problems

AI agents that tune systems will inevitably get blamed for outages, even when they aren’t the cause, simply because their changes are invisible. That alone is a compelling reason to keep them on a tight leash. There’s also a subtler risk on the customer side. If companies treat AI as a replacement for performance engineers, they reduce their own “performance IQ.” Gregg has already watched large companies spend tens of millions on low-feature monitoring products because they lacked the in-house expertise to build something better and cheaper. He fears a feedback loop: fewer staff enter performance engineering, so the industry’s collective expertise shrinks further.

What’s actually useful today

Gregg isn’t new to AI assistance. He already uses ChatGPT in his own work—finding release notes, tracking down an old LKML patch from a vague description that would have taken hours of searching. That kind of time-saving research is a proven, low-risk use.

The more ambitious version—AI pattern matching over flame graphs—follows the old “recent performance issue checklist” practice, just automated. Gregg’s Fast by Friday methodology aims to make systems root-cause analyzable within five days; an agent that matches known issues against flame graphs, metrics, and other data supports that goal. For companies with no performance engineers at all, he estimates matching previously seen issues could yield roughly 10–50% performance gains. Calling such an agent a “Brendan” makes more sense than a random name like Siri or Alexa, so long as it’s clear the agent is Brendan-like, not a genuine virtual copy.

Gregg’s broader point: he has suspected this day would come since he started in the field, and he doesn’t think the industry should stop experimenting. The problem is projects that claim a lot and deliver little. With AI datacenters getting more expensive and systems more complex, performance engineering needs more help, not less. He wants agents that “claim a lot and do a lot”—and wishes luck to the projects that take that seriously.

What a “Virtual Me” Can and Can’t Be

Talk of a “Virtual Brendan” or similar AI agents based on a real individual’s published work is becoming more common, and the engineering reality is far more nuanced than the marketing suggests. The core constraint is simple: my publications are an incomplete, stale snapshot of what I actually know and do. Any agent trained on them is necessarily partial and degrades over time as the underlying content ages.

That incompleteness is not just about gaps in coverage—it’s structural. Blogging and talks are spare-time hobbies that reflect whatever I’m currently interested in or working on. That means topics like observability, profiling, tracing, and eBPF get far more coverage than tuning, benchmarking, or distributed tracing, which I’ve written almost nothing about. The depth is also limited: I summarize best practices, but my head still contains every performance issue I’ve debugged over the last 20 years. Books like Systems Performance are an attempt to encode enough knowledge to make a reader a competent performance engineer, but even those are not “The Complete Guide to Brendan Gregg.” My drafts routinely approach 2,000 pages, and publishers push back on binding and volume limits, so roughly half gets cut—the least useful half, by my own judgment, but still missing from any training set. Scraping publications designed for human attention spans is simply not the same as engineering the best possible product from the start, regardless of the legal questions around training on copyrighted books and selling the result.

Freshness is an equally serious issue. Methodologies are durable, but tuning advice ages fast. I deliberately avoid sharing tunables in most cases, precisely because people copy-paste them into environments where they don’t apply, so that’s more an incompleteness than an obsolescence problem. The staleness issue has gotten worse since I joined Intel: I’ve published much less, partly due to focus on an internal strategy project and partly because I now feel that blogging means giving up weekends, unpaid, to train my own AI replacement.

Where These Agents Actually Fall Short

Current AI agents built on this material automate only a narrow slice of the job. They can assist with analysis, reporting, and tuning of issues that have been seen and solved before—useful, but a small fraction of the work. In a prior post I listed 10 activities a performance engineer performs (A–J); analysis and tuning is only 2 of those 10, and these agents do only half of that analysis well. That puts their effective coverage near 15% of the role.

The other half of analysis involves never-seen-before issues. Seen-before problems are often fixed before they ever reach a senior engineer, and the genuinely novel ones have no online corpus to train from—precisely where current agents are weakest. Most practitioners will face a smaller but still significant portion of these novel cases, so the gap is not unique to me.

There’s also ambiguity in the name itself. When people say “Virtual Brendan,” they often mean a systems-performance/flame-graphs/eBPF project more than an actual digital copy. That shorthand can mislead business stakeholders into overestimating what the tool does. And even setting that aside, I don’t know everything. Performance is vast, and at large companies there are teams that go deeper on specific areas than I do—at Netflix, for example, a dedicated team handled distributed tracing, so I never had to own that topic deeply despite its importance.

From Rule-Based Tuners to AI Agents

The idea of codifying an individual’s expertise predates modern AI. The first effort I know of was “Virtual Adrian” in 1994: Adrian Cockcroft’s tool, described in Sun Performance and Tuning (2nd ed., 1998) as “having Adrian actually watching over your machine for you, whining about anything that doesn’t look well tuned.” It did both analysis and tuning, but was strictly rule-based. That book also launched my own performance career—I read it and Solaris Internals to test my interest and ended up falling in love with the discipline. So I’ve known about virtual Adrian for decades, and suspected a Virtual Brendan might one day appear.

Other rule-based auto-tuners followed, though not named after individuals. Red Hat maintains TuneD, a daemon for monitoring and adaptive tuning of system devices. Oracle has bpftune (by Alan Maguire), an eBPF-based effort—which one might affectionately call “Virtual Alan.”

Machine learning entered the picture around 2010. I met mathematicians applying ML to system metrics to identify performance issues. Their approach assumed system metrics were trustworthy and complete, which I pointed out was a “garbage in, garbage out” problem: some metrics were unreliable, and there were many blind spots that my tools were designed to help fill. I advised fixing the metrics first, then doing ML—but that never happened.

AI-based auto-tuning companies arrived by the late 2010s. Granulate (founded 2018) pioneered automatic, no-code software tuning with AI, and Akamas followed in 2019. Intel acquired Granulate in 2022—about 120 staff, reportedly for USD$650M—to boost cloud and datacenter performance. As shared at Intel Vision, the technology could deliver roughly a 30% CPU reduction on Ruby and Java workloads, and Intel’s press release noted it would leverage the company’s 19,000 software engineers to expand capabilities.

The subsequent years were difficult for Intel overall. Granulate was rebranded “Intel Tiber App-Level Optimization,” and by 2025 the project was reportedly put up for sale. Finding no takers, it was shut down. An Intel statement said the decision came after “extensive consideration” as part of the company’s portfolio review and transformation process.

I learned about Granulate within my first days at Intel. I was told it was based entirely on my work—flame graphs for profiling and my publications for tuning—and that supporting it was part of my job. Behind the interface was a considerable amount of orchestration infrastructure for safe tuning changes, which is not trivial. The first demo I saw highlighted a dynamic flame-graph variant, shown to me as if it were novel; I recognized it as the d3-flame-graphs that Martin Spier and I had built at Netflix.

It was dizzying to see my work “AI’d” and monetized, but since it was now an employer-owned project, I couldn’t complain. There was also an upside: an AI agent that could tune the world using solutions I’d already published, sparing me from repeating myself and freeing time for new problems. The people building the tool were genuinely pleased I’d joined—the CTO received a standing ovation when the news was announced. Automating known tuning for everyone struck me as good for the planet.

The real difficulty came from those on the periphery without performance expertise who were nonetheless enthusiastic about selling a wholesale Virtual Brendan. Human me—the actual performance expert—was given no role or voice in that vision; the implicit message was that once my brain was copied, I was no longer needed. That was the only time I’ve been concerned about AI’s impact on my career, and not for the usual reason. The risk wasn’t being replaced by a better AI—it was being replaced by a worse one that people believe is better, amplified by marketing until everyone else believes it too. Human me wouldn’t stand a chance.

Looking ahead, in-house agents are emerging at scale. Uber runs PerfInsights, which analyzes code profiles to surface optimizations. While writing this post, I also came across Linnix, described as AI-powered observability. The field is moving quickly from rule-based scripts to learned agents, but the fundamental limits of published knowledge as a training substrate remain.

The Reality Behind Virtual Brendans

More computers exist than performance engineers can tune. That gap leaves most systems running untuned and wasting resources. AI performance agents offer a path forward — run them on everything and reduce global energy use. Some of these agents will be branded as "AI Brendan" or "Virtual Brendan," but that label doesn't mean they were trained on Brendan Gregg's work or received his direct input. Nor does it imply any brain-uploading steampunk scenario. Virtual Brendans only target roughly 15% of what a performance engineer actually does, a scope Gregg outlined in an earlier post on performance engineering team roles.

What Happened at Intel

Intel and an AI auto-tuning startup it acquired for $650M — a company whose approach drew from Gregg's work — were early movers in this space. After further investment, Intel shut the project down. Gregg notes the decision came amid broader struggles at Intel, and the company's public statement cited only a core business review rather than any technical failure. The idea itself wasn't invalidated by the shutdown.

The Economics of AI Tuning

Commercial AI auto-tuners face structural problems. A customer can pay for one server or instance, then copy and paste the tuning changes across their entire fleet — mirroring the established pricing model of hiring a performance consultant for a fixed engagement. For third-party code, the risk is even more direct: eventually, someone will upstream the AI's suggestions into the original project, eroding whatever competitive advantage the tuning tool had. In-house tools don't carry these burdens. That may point to the real future of AI tuning agents: either internal development or non-commercial, open-source collaboration.