AI changed distribution. Can you keep up?
Why every company needs to show value now — or lose
There’s a temptation to try to make agents as impressive as possible up front: Give them all the data, do all the configuration, then brag about how much value you can add. That’s the wrong approach: You need to show people what your product can do immediately – even if the functionality is limited. If you don’t, you risk losing to someone who does, whether it’s an enterprising engineer building in-house or another vendor.
At Herald (recently rebranded from RunLLM, in case you haven’t seen), we’ve flipped our distribution model in the past couple months from a top-down, enterprise-oriented approach to a bottoms-up approach that enables developers to try our product quickly and with minimal change. To do that, we’ve rolled out a new CLI that’s up and running on your laptop in minutes – like Claude Code or Cursor – without requiring you to upload any credentials to the cloud.
We’d obviously love for you to install our CLI, try it out, and share any feedback that you have – but we also think that what we’ve learned reflects something fundamental about distribution of AI products.
What we learned
It’s worth starting with why we were previously in a different mode of distribution. Our product – an AI DevOps Agent – understands a team’s product, infrastructure, and business and helps engineers answer questions, debug issues, and discover incidents before customers complain. By its nature, this kind of agent requires access to a lot of different data: code, telemetry, infrastructure, CI/CD, documentation, and so on. To show off the full value of the agent, we encouraged our customers to connect as much data as possible – but for understandable reasons, engineering teams won’t blindly connect all of those data sources to a new agent without the appropriate security and legal review. The process we set up was to engage with a company’s leadership, get buy-in, go through legal & security review, get access to all the data, then show teams what we could do.
That works to an extent, but it leaves a lot of opportunity on the table. While getting the necessary approvals, we found that a number of teams – especially the most AI-enabled ones – would quickly move on to other priorities or go with an in-house solution. We could talk about why DIY solutions are worse until we’re blue in the face – most vendors are right now! – but the fact that teams can make themselves successful more quickly than ever is incontrovertible.
That’s what led us to conclude that we had to show engineers value immediately. Once they understood why we were better than what they could build in-house – even if with limited access – then we could justify the time and effort required to get comprehensive access. Of course, to do that, we had to address security concerns too. Long story short, we built a version of our agent that has a familiar form-factor (Claude Code-style CLI) but, critically, keeps all of your credentials local. An engineer can now install the agent with npm install -g @herald-ai/herald, point at the tools that they already use locally (e.g., AWS CLI, Grafana MCP, etc.), and see what Herald can do immediately.
The implications
None of this is to say that everyone should go build a CLI. We’re working with developers, so we set out to build something that was familiar to them, but your target audience, their ideal UX, and what value you can show in a limited capacity might very well be different. In many ways, building a CLI is actually harder than traditional product-led adoption because you lose the ability to instrument many of the adoption funnel signals that you can capture on a web app.
The traditional wisdom for a lot of developer-led adoption is that you want to show people the full value of the product up front rather than gating features. While that’s true, agents are all about data access, and an individual user or small team is never going to be able to provide full data access. Your product should be designed for that limitation. It’s reasonable if your product would be better with more data, but it needs to be good with limited data.
There’s unfortunately no one-size-fits-all solution to operating with limited data. In our case, we’ve customized an implementation of our predictive issue detection feature to each data source that a user might configure. The full implementation works better when there’s multiple data sources to correlate across – but the explicit compromise made it easier for us to show value to the user immediately. What compromise you can make to show value immediately is the question that should drive your implementation.
Given that we’re talking about an adoption strategy that puts product front and center, you might be tempted to think that we’re saying every agent should adopt a PLG motion. Not quite. While giving people a taste of what your agent can do up front matters, you very well might still need humans in the loop to solidify and grow usage. For our agent to truly be successful in an enterprise, we still need to go through security approvals and a team-wide deployment. Predictive issue detection will still be most valuable when the IT team connects all the relevant data sources. The difference is that we can now operate in both modes – limited data to show value quickly, and comprehensive data to show the full value.
Is this universal?
Our initial thought was that this was unique to developers – a lot of the people we talk to are Claude Code zealots, after all. The more we think about it and look around, the more we realize that this is a challenge that every software vendor is going to face in the next few years.
To be clear, there are exceptions. Companies like Sierra and Decagon seem to be growing at a breakneck pace with large enterprise contracts, and security products have always been bought & sold differently than other software infrastructure. It’s worth noting that these hard-to-adopt products have a unique data advantage that comes from embedding, and we’re explicitly advocating for a transition from hard- to easy-to-adopt – or at least a dual approach. That’s a topic for another post.
But again, these exceptions are noteworthy because plenty of software that you might expect to be purchased top-down – inference infrastructure, voice agents, sales tooling – is seeing a pattern where a usage-first adoption is driving growth. You should build for a world where every vendor has to show value now.