Meet the Anthropic Engineer Keeping Its AI Agent Trustworthy

We talk a lot about the magic of AI agents. We see the demos where a model like Claude schedules meetings, writes code, or researches a market, and it feels like we’re finally living in the future. But for builders, the real work isn’t in the demo; it’s in the plumbing. If you can’t trust the data flowing through your system, your agent isn’t an assistant—it’s a liability.

Gurmeet Saran, an engineer at Anthropic, spends his days thinking about this exact problem. He isn’t just training models to be smarter; he’s building the infrastructure that makes them auditable. His perspective is a reality check for anyone currently building in the AI space: privacy and reliability aren’t things you can just bolt on at the end.

The Myth of the Quick Fix

There’s a common trap for founders: the belief that if the model is good enough, the rest will work itself out. We think we can patch privacy issues or data hallucinations with a better prompt or a thin layer of middleware. Saran’s career, which spans stints at Yahoo, Intuit, and Meta, suggests the opposite. The most catastrophic failures in tech often stem from architectural flaws, not coding bugs.

At Yahoo, Saran saw how lack of standardized data could paralyze a company. Different teams would report different numbers for the same metric, like daily active users. It sounds minor, but when you’re allocating millions in resources based on those numbers, inconsistency is a poison. He solved this by creating a single source of truth—a central repository that defined exactly what a "user" was. This lesson followed him to Meta, where he built systems to fix inflated video metrics. The takeaway for builders is clear: if your foundation is shaky, your scaling will only amplify the errors.

Privacy by Architecture, Not Policy

During his time at Intuit, Saran worked on systems to detect fraudulent tax filings. When you’re dealing with IRS data, there is zero room for error. This is where the concept of privacy as an architectural requirement, rather than a legal checklist, becomes real. If you build a system and then try to hide sensitive data later, you’re playing a losing game of whack-a-mole.

For AI agents, this is even more complex. These systems don’t just pull data; they take sequences of actions. They reason, they store state, and they interact with external tools. If a builder hasn’t designed the system to recognize and protect sensitive data at every step of that sequence, the risk of leakage is massive. Saran’s work at Anthropic is focused on ensuring that as Claude processes information, the privacy protections are baked into the very way the data moves.

The Observability Gap in AI

One of the biggest hurdles we face right now is that our monitoring tools haven’t caught up to our models. We have excellent tools for monitoring traditional databases and web services. We know how to check for uptime, latency, and throughput. But how do you monitor the "reasoning" of an LLM in real time? How do you ensure that the internal logic the model used to reach a conclusion was sound?

Saran uses a medical analogy that I think hits home for anyone in the AI trenches. Imagine a doctor treating a patient based on vital signs. If the medical equipment is miscalibrated, the doctor might make a fatal mistake, even if they are the best physician in the world. In the AI world, the model is the doctor, and the data infrastructure is the medical equipment. If the instruments are giving bad readings, the output doesn’t matter.

Making AI systems genuinely auditable and transparent is one of the more important engineering problems of the next decade, and it doesn’t get talked about as much as model capabilities do.

What This Means for Builders

If you are building an AI startup or integrating agents into your enterprise, you need to shift your focus from "capabilities" to "audits." It’s easy to get a model to do something impressive once. It is incredibly difficult to ensure it does that thing reliably, safely, and privately ten thousand times in a row.

Builders should be looking at three specific areas based on Saran’s approach:

• Standardization: Define your metrics and data handling protocols early. Don’t let different parts of your application interpret user data in different ways.
• Traceability: You need to be able to look back at an agent’s action and see exactly what information it was working with at that specific moment. If you can’t trace the logic, you can’t fix the failure.
• Privacy Integration: Assume your model will encounter sensitive data. Build the filters and governance into the data pipeline before it ever reaches the model’s context window.

The Need for Standards

We are currently in the "Wild West" phase of AI. Every team is inventing their own way of doing things. Saran’s involvement with organizations like the IEEE points toward a future where we have actual standards for AI infrastructure, much like we have building codes for skyscrapers. This isn’t just about red tape; it’s about creating a common language so that we can trust the tools we build.

The engineering community needs to move beyond the hype of what LLMs *can* do and start focusing on the rigor of what they *should* do. As AI development spreads globally, having these standards and pathways for engineers everywhere to participate will be the difference between a fragmented, dangerous ecosystem and a robust, professional one.

The Takeaway

The real value in AI isn’t going to come from the flashiest model. It’s going to come from the systems that are the most trustworthy. As a founder or a builder, your job is to be the skeptic of your own creation. If you can’t prove why your agent made a decision, or you can’t guarantee the privacy of the data it used, you haven’t built a product yet—you’ve just built a very clever experiment. Focus on the plumbing, and the magic will take care of itself.

---

Read the original at IEEE Spectrum →