Openlayer

AI governance isn’t documentation, it’s infrastructure Discover how to embed reliability, security, and compliance directly into your AI workflows. 👇 Read the whitepaper and future-proof your AI stack

I recently heard an analogy about AI replacing jobs that stuck with me. People often think of a doorman’s job as just opening and closing doors. If you see it that way, it’s easy to think automation is simply about making that process automatic. But that view misses what makes the role special. The doorman’s real value isn’t mechanical, it’s human. The greeting, the small kindness, the sense of welcome. Replace them with a sensor, and all of that disappears. That's what I'm seeing with AI teams right now. The ones trying to fully replace people with agents aren't hitting their targets. Systems fail in strange ways. Edge cases stack up. Quality slips. The ones augmenting people are moving. Support resolves more with better outcomes. Engineers ship faster without cutting corners. Operations scale without adding headcount. Human-in-the-loop isn't a fallback. It's the pattern that works. We're building Openlayer with that belief. So the next time you're thinking about where to deploy AI, ask yourself, are you trying to replace the doorman with a sensor, or are you giving humans better tools to do what they're already great at? The answer will shape everything that comes after.

The quickest way for a PM to lose an engineering team’s trust? Pretend to understand the stack. The strongest PMs I know aren’t buried in code. But they also aren’t allergic to it. They carry just enough technical depth to: - understand how the architecture fits together - walk through a flow like a user and spot gaps - recognize when tech debt is about to trip the team - document the “why” behind a decision so it doesn’t get lost six months later None of that is engineering. It’s product intuition sharpened by technical fluency. And it doesn’t stop at engineering. The same is true in design reviews and GTM discussions. The PMs who thrive are the ones who can speak to people in their language - technical enough for engineers, visual enough for designers, practical enough for marketers. I’ve seen and felt that shift myself - moving from writing code as an engineer to running product as a founder. The biggest unlock wasn’t learning to architect every detail. But learning to ask the right questions, in the right language, so decisions could move faster. The point isn’t for PMs to just do more. It’s to make the whole team faster by removing the friction that slows everyone else down.

Last week, I sat in on one of those meetings where everyone's right but it’s really hard to progress (precisely where your momentum slows down). Two teams were deciding on a new AI feature. Product and engineering were focused on shipping something customers would love. Risk & Compliance wanted proof that it was safe, fair, and compliant. Both teams were right. The handoff is where things get tricky. I’ve seen companies try to bridge that gap with documents, policies, spreadsheets, meetings. That’s where momentum dies and “compliance” becomes a box-tick. What worked better for us: turn policy into something the system can run. → Instead of a 50-page compliance doc, write tests that can fail your build. → Instead of quarterly risk reviews, set up alerts that tell you when things drift. → Instead of audit panic, log everything by default. Map your tests to real frameworks (EU AI Act, ISO standards, whatever your lawyers care about). But make them run automatically. Now engineering owns the code. Governance owns the risk. And they both speak the same language, a working software. The key is to start with a single policy. Turn it into a test. Gate your next release on it. And then repeat. If compliance is slowing your AI roadmap, let’s talk. At Openlayer, we help teams turn policies into code so engineering and governance can finally move in sync.

We’re thrilled to see so much momentum around our executive AI dinner series. Thanks to everyone who joined us in Austin, next up: Boston and New York. Interested in joining? jaime@openlayer.com

We built an AI assistant to help write AI tests. Then we used it to dogfood our own platform. Meta? Absolutely. Essential? Even more so. Here's what happened: We shipped the Openlayer Assistant - a tool that lets you describe your AI problems in plain English and get back tailored tests for your system. Think natural language to reliability testing. If we're asking you to trust our platform with your AI systems, we better be willing to bet on it with ours. The feedback loop is invaluable. We ship improvements, measure their impact under actual load conditions, then iterate based on concrete performance data. No assumptions, no delayed feedback cycles — just direct insight into system behavior. The assistant has evolved well beyond test generation now, improving precisely because we're subjecting it to the same rigorous evaluation we'd recommend for any production AI system. Dogfooding isn't just about validating that your product works. It's about proving you're willing to hold your own systems to the standards you set for your customers.

We’re excited to join the Comcast NBCUniversal LIFT Labs Enterprise Accelerator alongside an incredible cohort of #AI innovators. Looking forward to collaborating and showcasing how Openlayer helps enterprises ensure their AI systems are safe, reliable, and compliant.

Last month, Cursor released their CLI. Around the same time, I met a Fortune 500 engineer who walked me through his setup: At Openlayer, we're building evals for AI systems, so I'm constantly watching how developers actually work with these tools. Here’s what it looked like: - He uses Claude Code (or ChatGPT) to draft a full plan of action for a new feature. - Claude then implements the plan, breaking it into chunks. - He layers in “personas”: a Planner to map the work, an Executor to code, and a Debugger to test. - Each persona has access to the API spec, sample data, even the server — so they can emulate a real user, run the system, and debug in production-like conditions. It’s like having an internal team of agents working in parallel. What I love about Cursor CLI is that it lets you see the edits live inside your IDE. You can watch the code generate, review diffs as they happen, and step in when something starts to spiral. Tools like this blur the line between “writing” and “reviewing” code. But faster the loop, the more important the guardrails. If your product relies on AI, your evals need to evolve too. And your tests need to live in terminal, editor, and production, all linked.

Detecting PII in AI workflows shouldn’t take weeks. With Openlayer, it takes a few clicks. Our unified platform for AI governance and evaluation helps you flag PII, hallucinations, bias, and toxicity in real time 🎥 See how easy it is →