Herald

Last week, a VP of Engineering told us his team had already built most of what we do. We'd spent four meetings with the engineers who actually run reliability for him. We knew where their data lived, what systems they used, how they triaged incidents. So we knew the team was working almost entirely by hand — getting paged, spinning up channels, linking tickets manually. He thought they were further along than they were. We knew more about the state of his org than he did. This isn't new. Leaders have always been a few steps removed from the work. Enterprises have grown for decades despite that gap. But AI makes the gap expensive in a way it never was before. Here's why: an agent only creates value when it conforms to how your team actually works. That requires a clear picture of the current state and a real definition of what "good" looks like. If you don't know what good is, an LLM won't tell you — it'll just help you get to the wrong place faster. The VP was anchored on a demo built on hard-coded workflows and runbooks. It looked impressive. It also wouldn't survive contact with the complexity of his actual stack — a stack he'd partly lost track of. So the risk wasn't that he'd buy nothing. It's that he'd buy something that amplified the disorganization already there. The fix isn't more diligence from the top. It's trusting the people doing the work to make the call. They're the ones living with the pain. They know what's worth automating and what good looks like, because they're standing in the ground truth every day. The further you sit from that ground truth, the more likely you are to believe your team is light-years ahead — or behind — where it actually is. That's the part AI doesn't fix for you: https://lnkd.in/gEXnfNqH

Herald has been named to the Redpoint InfraRed 100, recognizing the top private companies defining the future of cloud infrastructure. Thank you to Satish D. and the Redpoint team for the recognition. Want to try Herald? We now offer Herald CLI — completely free, full-featured, and up-and-running securely from your terminal in minutes. Join the waitlist: https://lnkd.in/ge37zaaU See the full list of 2026 InfraRed 100 honorees and accompanying industry report: https://lnkd.in/dVPBWKhh

RunLLM is now Herald. There's a story behind it, and it starts with a moment every engineer knows. It's 3am, an alert fired, and you're looking at something you've never seen before, a novel incident. Your runbooks don't cover it. Your tools tell you something is wrong, but none can say why or how, or what to do about it. For decades, that's been the deal. Something breaks, you fix it fast. Companies are pretty good at it. But it comes with real costs — alert fatigue, engineer burnout, and the moments when customers tell you something is down before you know it yourself. So we asked a different question: what if you didn't have to wait for something to break? What if your systems could tell you what's about to go wrong, before alerts fire, before customers notice? To herald something is to signal that it's about to happen. And that's the shift we're bringing to observability and reliability: from t₊₁ to t₋₁, where t is the moment something breaks. To deliver on this promise, we're offering Herald CLI — a full-featured, completely free agent that runs securely on your laptop and gets up and running in minutes. Try it on your own stack to see how Herald moves you from being behind a problem to getting ahead of it. 👉 Sign up for Herald CLI early access here: https://lnkd.in/ge37zaaU 👉 Read more about the Herald brand from our CEO Vikram Sreekanti: https://lnkd.in/ghhfu9i8

Lots of exciting news to share today! 1. RunLLM is now Herald. The new name reflects the fact that our AI SRE is the only product on the market that operates autonomously — teaching itself about your product & infra, detecting early warning signs of incidents, and investigating without runbooks. Read more: https://lnkd.in/dWQZ8rzi 2. Herald was named to the InfraRed 100, an annual list recognizing the most promising private companies defining the future of cloud infrastructure. Thanks to Redpoint for the recognition!  3. We're releasing the beta of the Herald CLI — an agent that runs securely on your laptop and gets up and running in minutes. Sign up for early access here: https://herald.dev/cli

Recently, we paid less than $100 in tokens to rebuild our entire website from scratch and wire it into a headless CMS. Previously, that would've been a retainer with a web design consultancy. I think about this every time a prospect tells me someone on their team spent a weekend building a homegrown version of what we sell. The old enterprise sales playbook says: argue them out of it. Walk through the maintenance burden. The opportunity cost. The features they haven't thought through yet. That playbook is wrong right now. Building something yourself is fun. It feels like agency. The harder you push against it, the more you look like a vendor making a desperate argument. What works instead is one of two things. Either you onboard faster than the DIY version takes shape — anything longer than a weekend loses. Or you become the substrate the DIY engineers build on top of, so they get the satisfaction of building and you get embedded. We wrote about how you enterprise AI sales is changing, what happened in this awkward maturation phase, and what comes next: https://lnkd.in/eftcHZPG

Finding product-market fit has always been the holy grail for every startup. In AI, it might not be the "we've made it" moment it once was. The traditional advice once you find PMF is to operationalize. Codify the ICP. Build the playbooks. Deepen the product. The point is consistency — $N in, $M out. In AI, consistency is a liability. Customer preferences are being rebuilt every week. The demo they saw last night is the new benchmark. If that signal takes three weeks to travel from a sales call back to a roadmap decision, you're already behind. The companies that win aren't going to be the ones that find PMF first. They're going to be the ones that keep replacing their own product while the market is still figuring itself out: https://lnkd.in/gnNzz5MC

If customers had been willing to write us $250K checks on day one, we would have built the wrong product. With RunLLM, we set out to build the same AI SRE agent everyone else was building: an RCA agent triggered by alerts, driven by customer-maintained runbooks. It was the obvious answer. Humans use runbooks, so the agent should too. Except alert thresholds are noisy. Nobody actually maintains their runbooks. And the agent inherits every gap. We didn't figure that out because we were smarter than anyone else. We figured it out because the market gave us time. Enterprise SRE buyers don't move fast. They have committees. They want weeks to evaluate. They ask hard questions about what happens when something breaks at 3am. That slowness is put us on the right track. In a fast market, the competitive pressure forces you to ship the obvious solution and iterate from there. You don't get time to ask whether you're solving the right problem — you just have to start solving something. In a slow market, you're forced to keep asking. And for hard problems, the obvious solution is rarely the right one. The interesting question in AI SRE isn't "how do we automate the runbook." It's "how do we detect early warning signs, validate them, and find root cause before any threshold alert fires?" We didn't get to that question by moving fast. I see a lot of founders right now benchmarking themselves against Cursor's growth curve and feeling like something is wrong. For most infrastructure problems worth solving, that curve was never going to apply. And the slowness you're frustrated by is probably the thing that's going to make your product impossible to copy in three years. Friction is information. Don't optimize it away too early: https://lnkd.in/gpe3xZA6

AI doesn't just speed up software delivery. It changes where validation happens. If AI is writing code faster than humans can review it, production is increasingly where we find out whether that code actually works. Ben Sigelman has spent decades building production systems at Google, as founder of Lightstep, and as co-creator of OpenTelemetry. His view is that staging can only tell you so much. Real workloads, real users, and real failure modes only show up in production. And that has major implications for reliability. If production becomes the place where software is truly evaluated, observability has to become a continuous feedback loop into how software gets shipped, judged, and improved. 👉 Read the full piece: https://lnkd.in/gTCvbaHV

Agents can't choose between structure and flexibility. We learned this the hard way. In the early days of RunLLM, we built the way most AI SRE vendors still build: have customers write runbooks, encode them as workflows, let the agent execute them in response to alerts. It worked in demos. It fell apart in production. The moment an alert looked different from anything we'd seen before, the agent was useless. The moment a customer's architecture changed, the runbook was stale. We were shipping a glorified lookup table and calling it an agent. The instinct is to flip the other way. Let the model figure it out. Give it good context, a capable loop, and get out of the way. That works until you try to run it at scale. Context windows fill up and something has to decide what to keep. Costs balloon and something has to route cheaper tasks to cheaper models. Multiple agents need to coordinate and something has to orchestrate them. Each of those is an engineering decision that can't be solved by asking the model nicely. The teams building serious agents have all landed in the same place, independently: structure where it has to be enforced, flexibility where reasoning matters, and a deliberate architecture deciding which is which. Picking a side is how you avoid doing that work. New post on the AI Frontier this week on why the Python vs. Markdown debate is the wrong debate: https://lnkd.in/gmu3mVAR