Vlad: Two hundred and seven billion dollars. That's what Gartner says enterprises will pour into AI agent software this year alone.

Vlad: That's up a hundred and thirty-nine percent from last year. Money is not the problem anymore.

Vlad: The problem is nobody can tell you if it's working. Not even the companies spending the most.

Vlad: Uber burned through its entire 2026 AI coding budget by April. The whole year's money, gone in four months.

Vlad: And when a reporter asked whether any of it paid off, nobody at Uber had a clean answer.

Vlad: So today we're not talking about whether AI works. We're talking about why almost nobody can prove it does.

Vlad: We've got a company that logged every dollar and can show you the receipts. And a company that built agents its own security team actually trusts, with the numbers to back it up.

Vlad: The difference between those companies and Uber isn't the technology. It's what they built around it.

Vlad: We're going to walk through three stories this week that all sit on the same fault line: money going out the door, and no reliable way to check what came back.

Vlad: One company can't answer the question at all. One shows you the infrastructure that makes the question answerable in the first place. One already built it and is running it in production today.

Vlad: Let's get into it.

Vlad: Welcome to Hack the Stack, the weekly show for senior IT and AI leadership who actually have to deliver, govern, and maintain AI in production.

Vlad: I'm your host, Vladimir Cvijanovic, joined by Kate, our technology and data architecture lead, and Zoltan, our old-school IT skeptic. Every Tuesday, we skip the vendor marketing pitch and break down what's actually happening across the stack. Let me get right into this week's first topic.

Vlad: So, Kate. Two hundred and seven billion dollars into agent software this year. Where does that number actually come from?

Kate: Gartner's projection. Up from eighty-six point four billion last year. That's a hundred and thirty-nine percent growth in twelve months.

Kate: And here's the part that should make every CFO nervous. Gartner also flags two hundred and thirty-four billion in existing enterprise software spend as "at risk." Agentic tools are eating budgets that used to belong to other vendors.

Vlad: So this isn't just new money going into agents. It's existing licenses getting displaced at the same time.

Kate: Both, at once. Which is exactly why finance teams are asking sharper questions this year than they did in 2025. There's more to justify on both sides of the ledger.

Zoltan: Last year it was "try the pilot, see what happens." This year somebody wants the pilot to actually show up on a spreadsheet.

Zoltan: So we are replacing one subscription with a more expensive subscription that also writes bad code sometimes.

Kate: Not exactly. Some companies are actually pulling this off. Uber just isn't one of them.

Zoltan: Uber burned its whole yearly AI coding budget by April. That is not a rollout. That is a fire.

Vlad: Walk us through what actually happened there, Kate.

Kate: Uber's president, Andrew Macdonald, had to step in and cap AI coding spend at fifteen hundred dollars per employee per month.

Kate: That's a hard ceiling, applied company-wide, after the money was already gone.

Zoltan: Reactive governance. My favorite kind.

Vlad: But it's not just Uber overspending on nothing. There's a real mechanism here. Explain "tokenmaxxing."

Kate: Tokenmaxxing is what happens when the defaults do the deciding instead of the team. Premium models come pre-selected on enterprise plans. High-reasoning-effort settings are on by default. Million-token context windows auto-activate.

Kate: Nobody chose to spend more. The infrastructure just quietly pushed everyone toward the expensive option every single time.

Zoltan: That is, annoyingly, a very old story. Default settings have always been where the money leaks out.

Vlad: One quote from the piece stuck with me. "Teams aren't burning spend because they love waste. They're burning it because the default infrastructure pushes them toward it."

Zoltan: Which is a polite way of saying the vendor's pricing model is doing exactly what it was built to do.

Vlad: You think the defaults are deliberate, not just careless?

Zoltan: I think a company selling tokens by the million has no incentive to make the cheap option the obvious one. Call it what it is.

Kate: I won't fully go there, but I won't fully disagree either. Whether it's deliberate or just careless design, the effect on the bill is identical.

Kate: Right, and that's why blanket caps don't fix it. Agiloft tried per-person token caps and found seventy-four percent of users never even hit them.

Kate: The caps weren't targeting the actual cost driver. They scrapped the whole system.

Zoltan: So the ceiling wasn't touching the people burning the money.

Kate: Correct. The real fix companies are converging on is routing, not rationing. Databricks built Smart Routing into Unity AI Gateway. It reads prompt intent, file references, stack traces, and picks the cheapest model that can actually do the job.

Vlad: So instead of telling engineers to use less AI, you're telling the system to pick the right tool for each task.

Kate: Exactly. Pair that with what the piece calls "conscious model selection." Training engineers to actually choose Opus, or Sonnet, or a cheaper tier, by task, instead of defaulting to the top model out of habit.

Zoltan: And who is actually doing this well? Or are we just describing a nice idea again?

Vlad: Fair. Give him a real number, Kate.

Kate: Everlaw. CTO Max Christoff has the cleanest before-and-after in the whole piece. A thirty-five hundred dollar token spend took a Java infrastructure project from nine and a half engineer-months down to two and a half.

Kate: Then a bigger swing. Twenty-seven to forty thousand dollars in token spend took an unlaunched product from ninety to a hundred engineer-months, down to nineteen.

Zoltan: That is a real number attached to a real outcome. I will allow it.

Vlad: High praise, coming from you.

Kate: He's actually being generous today.

Zoltan: Don't get used to it.

Vlad: What made Everlaw different from, say, Uber. Same category of spend, opposite result.

Kate: Everlaw scoped the work before spending. They picked a defined project, a Java infrastructure rewrite, measured the engineer-months it normally takes, then measured it again after.

Kate: That sounds obvious, but almost nobody in the article did it. Most companies just let usage grow and hoped it added up to something.

Zoltan: So the secret to proving ROI is measuring before you spend, not after someone in finance asks for it.

Vlad: Which sounds like basic project management, and it is. It's just being applied to AI spend for the first time at most of these companies.

Vlad: Let's talk about Databricks' Smart Routing a bit more concretely. How does it actually decide which model gets the job?

Kate: It reads deterministic signals first. What kind of file is referenced, what's in the stack trace, how complex the requested execution actually is.

Kate: Then it layers model-based classification on top, essentially a smaller model judging how hard the task really is before handing it off to the right tier.

Zoltan: So you're paying for a small model to decide how much you should pay for a bigger one.

Kate: When you put it that way it sounds silly, but it works. The classification cost is tiny compared to the savings from not running every trivial task through a frontier model.

Vlad: And it's in beta inside Unity AI Gateway, so this isn't a finished product yet.

Kate: Correct, worth flagging on air. Early days, but the direction is the right one, routing by task instead of defaulting to the most expensive option every time.

Vlad: What about the companies that don't have Everlaw's numbers? Because the piece says most don't.

Kate: Right, that's the honest part of the article. Outside Everlaw, nearly all companies lack hard ROI figures.

Kate: SUSE's security agents categorized close to ten thousand CVEs since May, but that's an anecdotal efficiency gain, no dollar attached. Promova says their Opus usage alone eats a third of their monthly token spend, but again, no before-and-after business metric.

Zoltan: So the story isn't "AI doesn't work." The story is "almost nobody built a way to measure whether it works."

Vlad: Say more on Promova specifically, because a third of monthly spend on one premium model tier is a big number to just sit with unmeasured.

Kate: Dmytro Palaniichuk, their Head of Engineering, is upfront about it in the piece. Opus alone eats roughly a third of the company's entire monthly token spend.

Kate: They noticed the pattern shifted. They haven't yet tied it to a business outcome the way Everlaw did.

Zoltan: Noticing the pattern is step one. Most companies in this piece haven't even gotten that far.

Vlad: What about SUSE? Ten thousand CVEs is a big claim, even without a dollar figure attached.

Kate: SUSE's GM of Technology, Rick Spencer, says their security agents have categorized close to ten thousand CVEs in the company's vulnerability database since May, using a three-bucket system.

Kate: That's a real workload shift, engineers not manually triaging thousands of entries one by one. But it's reported as an anecdotal efficiency gain, not tied to a saved dollar amount.

Zoltan: So we believe them, we just can't put it on a slide next to Everlaw's numbers.

Vlad: Which is fine, as long as everyone's honest about which category a claim falls into. Anecdote or audited number. Don't blur the two.

Vlad: What happened after the caps and the fear, though. Did anyone actually walk back the panic response?

Kate: Two companies did, and both are worth naming. Microsoft canceled Claude Code licenses across its Experiences and Devices division entirely.

Kate: And Duolingo reversed a plan to fold AI usage directly into performance reviews, after employees pushed back hard.

Zoltan: Tying a bonus to how many tokens someone burns. Who thought that would go well.

Vlad: So the first wave of enforcement tactics, mandates, hard caps, performance tie-ins, they're already getting walked back.

Kate: In favor of routing and awareness instead. Teach engineers to actually choose the right tier for the job, rather than punishing them for using the tool at all.

Zoltan: Punishing usage never worked for VPN traffic either. Don't know why anyone expected it to work here.

Vlad: That's exactly it. And there's a second problem buried in there. The piece flags coding agents proposing twenty surface-level fixes instead of addressing the actual underlying bug.

Zoltan: So even when it's fast, it might be fast at doing the wrong thing.

Vlad: There's also a quality risk buried under the efficiency story, not just a spend one.

Kate: Right. The piece flags that model evaluations are imposing deterministic checks on non-deterministic output. Tests that worked against one model version don't reliably transfer to the next one, and these vendors ship new versions quarterly.

Zoltan: So your test suite is chasing a moving target, and the target moves every three months whether you're ready or not.

Vlad: Which means the routing and the measurement work isn't a one-time project. It has to be maintained the same way you'd maintain any other piece of production infrastructure.

Vlad: Which is why this isn't an AI-capability problem. It's a measurement and routing problem. That's the thread we're going to keep pulling on this episode.

Vlad: Let's move to topic two, because this is where you actually start to see the receipts. Or the lack of them.

Vlad: Kate, tell us about this piece on retrieval-augmented generation. Building trust in agentic RAG.

Kate: This one's from The New Stack, written by Jeremy Daly, sponsored by Oracle. Worth saying up front, it's a vendor framework piece, not a case study. No customer names, no adoption numbers.

Zoltan: An Oracle-sponsored article arguing that you need database-level enforcement. Shocking twist.

Kate: I said the same thing before I read it. But the mechanism holds up on its own merits, sponsor or not.

Vlad: We flagged the same thing back in Episode 003, with an EDB-sponsored piece. Worth being consistent about naming it every time.

Zoltan: Every vendor writing a technical framework has a product they'd like you to buy at the end of it. Doesn't make the architecture wrong. Just means read it with your eyes open.

Kate: Agreed. And there are no customer numbers here either. No adoption figures, no before-and-after. This is a mechanism piece, and it should be judged as one.

Vlad: What's the actual claim?

Kate: That RAG systems don't lose trust because the final answer is wrong. They lose trust because nobody can see how the system decided what to retrieve in the first place.

Kate: The piece lays out five mechanisms. First, structured retrieval logging. Every query rewrite, every source picked or rejected, timestamped with ranking scores. So you can audit a retrieval decision after the fact, the same way you'd audit a database query log.

Zoltan: That part is not controversial. That is just logging. Everyone should already be doing that.

Vlad: You'd think, but most RAG deployments I've seen skip it entirely because it slows down the first demo.

Zoltan: Nothing gets skipped faster than the boring part that makes the audit possible later.

Vlad: Second mechanism, Kate.

Kate: Metadata-driven filtering. Authority, effective dates, document owner, approval status, jurisdiction, all embedded directly into the retrieval logic instead of inferred from text similarity.

Kate: There's a good line in there. "A similarity score is an opinion. A scope filter is a rule the system can enforce."

Vlad: Meaning don't let the model's sense of relevance stand in for an actual permission check.

Kate: Exactly right.

Vlad: Give me a concrete example of what that looks like breaking, in practice.

Kate: Imagine two versions of an HR policy doc sitting in the same vector index. One's current, one expired eighteen months ago. To pure similarity search, they read almost identically.

Kate: Without a scope filter checking effective dates and approval status, the model might just retrieve whichever one embeds closer to the query, expired or not.

Zoltan: And now you've got an agent confidently citing a policy that legal retired a year and a half ago.

Zoltan: I've watched three vendors sell "semantic relevance" as a substitute for access control. It never ends well.

Vlad: What's the third piece?

Kate: Citation provenance. Every claim the model makes gets mapped back to a specific source excerpt during generation, and gets verified before the answer ships. Anything that can't be traced gets removed or qualified.

Zoltan: So instead of trusting the model to be honest, you make it show its work or it doesn't get to talk.

Kate: That's a pretty good summary, actually.

Zoltan: I have my moments.

Vlad: Fourth and fifth?

Kate: Fourth, access control at the database layer. Row and column-level policies enforce who sees what, independent of the retrieval service. Tenant isolation becomes a hard boundary in the database, not something the application has to remember to check.

Kate: Fifth, content-as-data, never content-as-instruction. Retrieved documents are treated as untrusted input, full stop. If a document tells the model to do something, that's not a valid instruction. Only the application's own logic gets to instruct.

Zoltan: Prompt injection through your own knowledge base. I've been saying this for two years and nobody in a boardroom wants to hear it.

Vlad: Why does that specific failure mode matter so much for this audience?

Zoltan: Because the document doesn't have to come from an attacker. It can be an old policy PDF somebody uploaded three years ago that still says something the model shouldn't repeat as current.

Kate: Which is exactly why rule five treats every retrieved document as data no matter where it came from, internal or external. The model doesn't get to decide a document is trustworthy on its own.

Vlad: There's a line in the piece I want to read. "The agent decides what to ask. The retrieval layer decides what may be returned."

Kate: That's the whole architecture in one sentence. Separation of concerns, applied to trust.

Vlad: There's a second quote in there too. "The closest match is not always the most appropriate source."

Zoltan: Which is the whole flaw in pure similarity search, stated plainly. Close isn't the same as correct.

Kate: Right, and that's why the piece keeps hammering the point that more control can improve coverage, but control alone cannot create trust. You need the logging and the provenance too, not just tighter filters.

Vlad: For a company migrating an internal wiki or a support knowledge base into a RAG system, where does this actually start? Which mechanism goes first?

Kate: Logging, honestly. You can't retrofit an audit trail after the fact. If you don't capture the decision at the moment it's made, it's gone.

Zoltan: Which means the boring infrastructure work has to happen before the flashy demo, not after. Nobody wants to hear that in a kickoff meeting.

Vlad: What does the piece admit it doesn't solve?

Kate: Two things. It doesn't touch the operational cost of this much logging and policy maintenance. And when two sources contradict each other, both looking valid, the piece just says that needs a human, not an algorithm.

Zoltan: So the honest answer to "which source is right" is still "call someone."

Kate: For now, yes. Nobody's cracked that one cleanly yet.

Vlad: And it's Oracle, so of course the answer involves buying more Oracle database.

Zoltan: At least they said it out loud instead of pretending otherwise.

Vlad: Kate, if you had to rank these five mechanisms by how much they'd actually reduce risk for a mid-sized CEE company, which two matter most first?

Kate: Logging and citation provenance. Those two together mean you can reconstruct exactly what happened after any incident, which is what a regulator or an auditor is actually going to ask for.

Kate: The database-layer access control matters just as much long-term, but it's a bigger lift. Start with the two you can actually ship this quarter.

Zoltan: Sensible advice. Rare, from a vendor-sponsored piece, but sensible.

Vlad: For a CTO trying to put a RAG system in front of customers or regulators, "we log every retrieval decision" is the whole difference between defensible and indefensible.

Vlad: Which brings us to the company that actually built something like this around agents already in production. Figma.

Vlad: Kate, this is the case study. Walk us through it.

Kate: This is from InfoQ, based on interviews with Matthew Sullivan, formerly Figma security, now at Nition, and Brad Girardeau, who manages Figma's security engineering.

Kate: Figma built three specialized agents layered on top of Panther SIEM. Alert-triage, code review, and coding guidance.

Vlad: What's the actual stack underneath that? Because "AI agents" alone doesn't tell you much.

Kate: Amazon Bedrock Knowledge Bases and Kendra for search, Tines for automation, Snowflake as the data warehouse, osquery for querying systems directly. Claude Opus is the model doing the reasoning.

Kate: And it's wired into monitoring across AWS, Okta, GitHub, and GCP, so the agents actually see what a human analyst would see.

Zoltan: A real stack, not a single API call wearing a trench coat. Good.

Vlad: Why security specifically, as the function Figma chose to hand to agents first? That's a high-stakes place to start.

Kate: Exactly because it's high-stakes. Security teams already live with structured alerts, existing tooling, and clear escalation paths. It's actually one of the more measurable functions to layer agents on top of.

Zoltan: Let's hear the numbers before I decide whether to be impressed.

Kate: Alert-triage delivers seventy percent faster resolution on complex security alerts. On-call pages dropped twenty percent, because agents adjust severity instead of just flagging everything.

Kate: They surfaced over a hundred previously unknown vulnerabilities, including two critical flaws traditional tooling had missed entirely.

Zoltan: Okay. That is a real number, and it is not a small one.

Vlad: What does "adjusting severity instead of just triaging" actually mean in practice?

Kate: Instead of every alert waking someone up at 2 AM, the agent looks at context, past incidents, the actual blast radius, and decides how urgent this really is before it ever reaches a human.

Zoltan: So the agent's acting as the triage nurse, not the analyst. The analyst only sees what actually needs them.

Vlad: Which is a completely different job than most people picture when they hear "security agent." Less autopilot, more filtering.

Kate: There's more. The AI code reviewer hit eighty percent precision in its first month. Adding a second automated review step improved known-bug detection by thirty percent. Automated coding guidance cut certain error classes by half.

Vlad: What's actually driving that? Because a lot of companies have thrown agents at security and gotten noise, not results.

Kate: The load-bearing design choice, in Sullivan and Girardeau's own words, is memory. Not a bigger model. Memory.

Kate: Three types. A record of past alerts. Accumulated behavioral guidance from human corrections. And learned database and schema structures the agents build up over time.

Kate: Their quote: "Memory ended up being the thing that had the most impact on how useful the system became over time."

Zoltan: So the agent gets better the way a human analyst gets better. By remembering what it got wrong last time.

Vlad: Walk through the alert-triage agent's actual workflow. What does it do when a real alert comes in?

Kate: It ingests the Slack thread history around the alert, pulls the steering memory, accumulated guidance from past human corrections, and works through a scoped toolset.

Kate: It can query over a hundred internal data sources to investigate. And when it hits high confidence on the fix, it opens a pull request itself.

Zoltan: A hundred data sources is not a toy demo. That is a serious integration surface.

Vlad: And there are explicit prompts built in to keep sensitive data from leaking into whatever the agent outputs.

Kate: Right, that's not incidental. With that much data access, you need the guardrail baked into the prompt layer, not bolted on after something goes wrong.

Vlad: What about the tuning order? I remember something counterintuitive in the summary.

Kate: Right, this is the part I actually love. They tuned precision before recall.

Kate: Their reasoning: the historical bugs you already have can only measure recall. If you optimize for catching more known issues first, you have no way to tell if you're also flooding the team with false positives.

Kate: So precision gets nailed down first, or the recall numbers don't mean anything at all.

Zoltan: That is genuinely disciplined engineering. Most teams chase the flashy recall number and call it a win.

Vlad: Explain that distinction once more, plainly, for anyone who isn't a security engineer listening right now.

Kate: Precision is how often the agent's flags are actually real problems. Recall is how many of the real problems it catches overall.

Kate: If you chase recall first, you catch everything, including a flood of false alarms, and the team learns to ignore the agent entirely.

Zoltan: Alert fatigue. The oldest failure mode in security tooling, just wearing a new AI costume.

Vlad: And every agent-opened pull request is draft by default. A human still has to hit merge.

Kate: Every single one. Plus explicit prompts to keep sensitive data out of agent outputs.

Zoltan: Draft-by-default. So somebody at Figma has read the same headlines we have about agents merging code nobody reviewed.

Vlad: Fair guess.

Vlad: What's the honest limitation here? Because InfoQ isn't a puff piece, presumably.

Kate: They cite Wiz's finding, a vulnerability called GhostApproval, that AI coding assistants can be tricked by malicious content sitting inside a repository.

Kate: They also point to a separate sandbox-escape disclosure from OpenAI as a comparison point. Same category of risk. Agents doing things outside the boundary they were supposed to stay inside.

Zoltan: Which is exactly what draft-by-default and scoped tooling exist to catch. Doesn't mean the risk goes away. Means somebody's actually watching for it.

Kate: And Sullivan and Girardeau are upfront that their exact setup depends on company size, the risks you face, and the feedback loops you already run. It's not a template you copy and paste.

Zoltan: A working system that admits it doesn't generalize. Refreshing, honestly.

Vlad: You're two-for-two on grudging compliments this episode.

Zoltan: Don't tell Kate. She'll get insufferable about it.

Kate: Too late. Already logging it.

Vlad: One more line worth repeating. On the limits of automation, Sullivan and Girardeau say the agents "are not perfect, but neither are humans."

Vlad: That's not a defense of sloppy automation. It's an argument for building the same checks around agents that you'd want around a junior analyst.

Vlad: So let's pull these three together, because they're really one story told from three angles.

Vlad: Uber spent its entire year's coding budget by April and still can't tell you if it paid off. Not because the technology failed. Because nobody built anything to measure it against.

Vlad: The RAG piece shows exactly what's missing at the infrastructure layer. Most retrieval systems can't show their own work. No log of what was retrieved, why, or on whose authority. So when someone asks why the model said what it said, there's nothing to point to.

Vlad: Figma is the answer to both of those problems, built and running in production. Memory instead of a bigger model. Precision tuned before recall, so the numbers actually mean something. Every agent-opened change reviewed by a human before it ships.

Vlad: Same category of spend across all three examples. Completely different outcomes. The difference isn't the AI. It's whether anyone built the routing, the logging, and the review gates around it before scaling the spend.

Kate: And none of the three companies that got this right did it with a bigger model. Everlaw scoped the project first. Figma leaned on memory and tuning order. Both are process decisions, not model decisions.

Zoltan: Which is the part that should worry the vendors selling "just upgrade to our newest model and the problem goes away." That was never the fix.

Vlad: That's delivery and governance, not a model upgrade. It's infrastructure work most teams skip because it's less exciting than the demo.

Vlad: If you're the one signing off on next year's AI budget, that's the question worth asking before you approve another line item. Not "does the model work." "Can anyone here show me the log."

Vlad: So here's the one thing to take out of this episode. Before you approve another dollar of agent spend, ask for the retrieval log and the before-and-after number, not the demo.

Vlad: If your team can't produce either one, you don't have an AI problem. You have a measurement gap, and that's fixable faster than most people think, because it's an infrastructure decision, not a model decision.

Vlad: That gap is closeable in weeks, not quarters, if someone actually owns it. It doesn't need a new model. It needs someone assigned to build the log.

Vlad: Start with logging what your systems already retrieve and decide. That alone puts you ahead of most of the two hundred and seven billion dollars being spent this year with no way to check the receipts.

Vlad: And pick one function, the way Figma picked security, rather than trying to instrument everything at once. Prove the measurement approach works somewhere small before you scale it across the org.

Kate: I'd add one thing. Precision before recall isn't just a security lesson. Apply that ordering to any agent you're evaluating, in any function. Know your false-positive rate before you brag about your catch rate.

Zoltan: And keep a human on the merge button. Every story we covered today that went well still had someone checking the agent's work before it shipped. That part doesn't go away just because the model got better.

Vlad: Three separate lessons, one shared root cause. Uber skipped the measurement. The RAG piece shows what the measurement layer actually looks like. Figma shows what happens when you build it and staff it properly.

Vlad: That wraps up this week's episode of Hack the Stack. If you're building or scaling AI infrastructure in your organization and want to discuss how to solve these delivery or governance bottlenecks, let's talk. You can book a call directly via the link in the show notes, or send me a direct message on LinkedIn.

Kate: We'll be back next Tuesday with another breakdown of what's real and what's hype across the stack.

Zoltan: Try not to deploy anything into production before then.

Vlad: Until next week.