Agents Under Management
A Conversation with Dome Systems Founder Dave McJannet
If 2025 was the year agents showed us what they’re capable of, 2026 is the year we start to put them under management.
AI governance, the layer that controls what agents inside a company can access and do, is quickly becoming a crowded market. There’s a deluge of point solutions and startups, each trying to own a slice of the stack – model gateways brokering LLM calls, tool gateways policing what agents can touch, identity startups minting credentials for non-human actors.
Moments like this reward pattern recognition. So I wanted to talk to someone who’s seen this movie before.
Dave McJannet was CEO of HashiCorp for nearly a decade, through its IPO and $6.4B acquisition by IBM. Under his leadership, HashiCorp became the default provisioning layer, one of the defining infrastructure businesses of the cloud cycle.
He believes agents today are where the cloud was fifteen years ago – there’s a proliferation of builders and new applications, but no default solution for oversight and control.
His new company, Dome Systems, wants to be just that – a unified governance platform where a company can register every AI agent, set the rules for what each one can access and do, and maintain a record of every action.
What I love about this conversation is Dave’s clarity of thought. Infrastructure is the business of imposing order on dynamic, chaotic systems. And Dave’s discernment and precision is legible in the product he’s building.
We spoke about how he thinks the agentic stack will mature, why now is the right moment to build AI infrastructure, his principles for building a product that endures — and telling a story that makes customers believers, not just buyers.
01 | From HashiCorp to Dome
EO: HashiCorp built the default provisioning and control layer for cloud. The core architectural bet behind the company was that infrastructure would get increasingly heterogeneous and multi-cloud, and therefore, there was a need for a separate, standardized control plane.
At Dome, you’re now building a governance layer for the agentic stack. What’s the core architectural bet this time?
DM: Every company I’ve been part of was catalyzed by a platform shift, a new architectural approach to building applications that triggered a corresponding change in infrastructure requirements.
As you point out, HashiCorp’s bet was that there would be a multitude of cloud platforms, and so the enterprise problem would be one of consistency.
We think a similar dynamic will play out with agents, only bigger this time. In the cloud era, there were six or so platforms where people went to build new applications – Amazon, Microsoft, Google, and the like. In the agentic world, you have those, plus companies like Salesforce, Databricks, Snowflake, and Workday, all exposing agents.
You can’t have a different way of enforcing policy and access across all these different applications. You need to standardize.
So ultimately, the paradigm is the same for agents as it was for cloud – given the heterogeneity of application types, you need a layer that creates operational consistency.
Do you think developers and product owners are feeling that yet, starting to crave standardization?
We’re in the early phases of it. Paul Maritz, the former CEO of VMWare, used to say these platform transitions are both more profound than you realize, and take longer than you realize. That was true of virtualization, then cloud. It will be true of agents.
Early in every platform shift, people start building – in different places, with different tools, across the organization. That gets unwieldy. And with agents, that sprawl is magnified. Because you have professional developers building on Bedrock, Vertex, and Kubernetes, but also now citizen developers building with Claude on their desktops…
Yeah, I think CISOs and CFOs are starting to feel that sprawl, in terms of risk and spend.
We talk to a lot of enterprises. Right now, fifty years of IT policy is being thrown out the window as executives try to push their employees to use AI. Give everyone Claude Code and you get an explosion of new applications… which is a good thing. But where are these applications deployed? What can they access?
We’re starting to come out of the euphoria. Now the mood is – let’s get this under control.
Do you have a framework for what “heterogeneity” actually looks like in the agentic stack, to get your arms around it so you can build a unified layer on top?
One lesson from repeat entrepreneurship is that product architecture is everything. Get the architecture right, and your value proposition naturally compounds.
For example, with Terraform1 we architected the product for heterogeneity, so new providers could plug in. So every new technology that got released made our product more valuable.
For Dome, we started with – what is an agent?
An agent is a piece of code, talking to a model, talking to backend systems or tools. So heterogeneity will show up across those three axes — the platforms the code runs on, the models it calls, and the systems and tools it connects to. Every enterprise needs an arbiter, a neutral layer across all three, so they have flexibility in where they run their applications.
02 | Building the security guard for agents
You’ve said the fundamental difference between this moment and the cloud era is that agents are inherently non-deterministic, meaning less predictability in the application.
As you reflect on your time at HashiCorp, what parts of the playbook transfer to this new paradigm, and which parts do you have to abandon?
Dome is solving a very different problem than HashiCorp. HashiCorp provides the platform that applications of all kinds run on. Dome is the security guard in the room when one particular kind of application – an agent – is running. So technically, not a lot translates.
What does transfer? Like at HashiCorp, Dome’s product will be in the runtime path. That requires us to build a level of trust with our customer. Trust, I’ve learned, is earned in thimbles and lost in buckets. So we need to approach customers with a level of seriousness, a sense of partnership.
We also learned at HashiCorp to follow the market and keep innovating, because it wasn’t always clear where the long-term infrastructure patterns would land. There’s a similar lack of clarity around the agentic stack, so we’ll need to stay at the cutting edge and move in tandem with demand.
How are you building this “security guard,” one that can oversee non-deterministic software?
We want every kind of agentic call — agent-to-model, agent-to-tool, agent-to-agent, agent-to-person — on one, unified platform. So step one is registering every agent within the enterprise.
Step two is assigning guardrails for those agents – policies, quotas, filters on what can come through. We provide some policies out-of-the-box, and we’ll keep adding new types as agentic capabilities advance.
Fundamentally, we want guardrail decisions to belong to the user. We give the tools and knobs, but you decide where the line is. And because we audit everything, you can write a new rule, replay it against the last seven days of history, and refine it intelligently. We’ll also suggest policies based on what we’ve learned running the platform for others.
So the architecture is simple – a platform where agents register, plus guardrails for enterprise control.
Are you introducing functionality like self-learning or LLM-as-a-judge2
Yes, we have that.
So how does a user know when to trust the system’s judgment versus write and modify the guardrail themselves?
In truth, the market is earlier than people think. Yes, there are complex scenarios where you want to apply agentic judgment at the time of calling, and our platform offers that.
But for 99% of use cases, users want the basics. For each agent they want yes/no guardrails tied to the caller’s identity, with everything logged to the audit system. And then the ability to write a few blanket policies on every model and tool call.
I imagine there are so many permutations of different guardrails, and the product experience could get overwhelming if not designed thoughtfully. How do you keep it manageable for the user?
The infrastructure patterns are now stable enough to start to create a clear set of guardrails. It ties back to the framework I laid out, that the control points of agents boil down to code, model, and tool.
A year ago, that pattern wasn’t so clear. Hence why we had a lot of model brokers controlling only the model axis, or tool gateways governing only tool permissions. Now we know the problem requires an integrated platform across all three.
03 | Moving away from open-source
Dome’s go-to-market is fundamentally different from HashiCorp’s. Terraform won through an open-source motion – community adoption first on free tools, and then you monetized with add-ons and hosting.
But Dome is fully proprietary. You’re built on top of open standards like Cedar3 and MCP4, but the product itself is closed. Why that approach? Does it reflect something more fundamental about how you see open-source right now?
I’ve been in open-source for a long time. HashiCorp was my fourth open-source company.
But what’s different for Dome is our end users are security and ops people, and open-source usually gets adopted by developers and DevOps people. Ops and security buyers are different, they want a vendor relationship out of the gate.
What we’re building is analogous to a WAF5 in that we’re inspecting every agent call. And there’s a reason firewalls aren’t open-source. Our product is not going to end up in the runtime path unless there’s someone our customers can call if things go wrong.
But there are open-source companies with hands-on commercial support. Is it the deployment requirements that make open-source hard here?
I don’t anticipate much onboarding work for this platform. Configuration is straightforward. I just think this product gets deployed by traditional ops people, doing traditional things. Open-source just doesn’t fit the motion of how enterprises adopt security tools.
It’s interesting, I haven’t seen any big open-source companies created in the AI world yet, and I wonder why. It might be that in a world where I can point an agent at your public GitHub repo and reconstruct your entire application in two hours, giving any IP away is more dangerous.
Maybe, but it’s still so early. In this initial period, most of the value in AI has been in the tech itself – the model weights, harness code. If that’s where value sits, it’s hard to build a sustainable business by opening your code.
But as we mature and get applications that create value in other ways – through network effects, owning the payment rails – maybe we see more commercial products with some open-source strategy? My guess is it’s more where we are in the cycle than coding agents making open-source obsolete.
But how long would it take to recreate Kubernetes if I pointed some agents at it? Not very long. The ease with which someone can copy and redirect open-source code is a fundamentally new dynamic.
04 | Super-intelligence still needs oversight
Model labs are investing a lot to make models more reliable, better aligned, and better at reasoning. How do you think about the longevity of your product as AI improves? Why, in theory, should Dome’s TAM grow as AI gets better?
I’m not worried about AI disrupting our platform.
An executive at a Fortune 50 company recently told me they feel squeezed from every side – model vendors trying to lock them into their model, data vendors pushing exclusivity. Enterprises are deeply reluctant to get locked in.
If enterprises want choice, they need a vendor-neutral way to interface with all these different providers. Yes, the shape of the intelligence will change. But the need for companies to harness these applications consistently – and enforce compliance when an agent talks to other agents or connects to databases behind your firewall – will not.
I’m trying to get at something a little different. Imagine we have 50+ model providers, and it’s easy to swap in and out, so plenty of choices…
It will probably be a lot more if you include small language models too…
Exactly. So even with lots of providers and very little lock-in, the general level of intelligence will keep going up.
What happens to governance when agents can reason about compliance and security decisions at runtime, faster and better than anything we can control through a centralized platform?
I’m smiling because I recall a meeting I was at a couple months ago where it became clear how fast developer frameworks were moving. So yes, soon agents could do exactly what you’re describing.
But that’s all the more reason to retain control over agents through a separate mechanism, from the outside. Even a perfectly aligned, superintelligent agent that governs itself gives the enterprise no way to check that governance – or shut the agent down when the person who built it leaves the company.
Agents are clever. But fundamentally, an agent is just a piece of code. And so it should be governed like all your other code.
We’ve been jokingly calling what’s emerging in AI right now “one-tier apps,” where the UI, logic, data, identity, secrets, and policy all collapse into one. But there’s a reason why decades of computing led us to multi-tier apps, so infrastructure concerns stay separate from app concerns and policies can be enforced in a way the application can’t override.
As smart as agents get, I think that pattern still applies.
05 | Tell market stories, not product stories
Your roots are in product marketing. You’ve done it across big data, cloud, and now AI. I think product positioning and narrative building is maybe one of the most valuable traits a founder can have now, given how competitive software has become.
Any practical advice would you give to other founders when it comes to standing out and positioning their product in today’s market?
Product marketing is an art and a science. I sometimes feel like it’s a certain brain type that finds it easier, and it tends to be the less logical brains.
My number one principle is – don’t tell product stories, tell market stories.
The first mistake entrepreneurs make is talking about what their product does. That’s one story you need to tell, but there are actually two others.
I’ll use GitHub as an example.
GitHub’s product story is: “Where people build software.” It’s a functional description, that you build software on GitHub.
Your company story is what your business stands for. For GitHub, it’s: “How software is built.” It makes a declaration that GitHub wants to own how software gets made, that the company wants to own the entire software development market.
Your market promise is what becomes true for the end user, the world you’re building for them. For Github, it’s about “empowering developers to build great software.” It’s a philosophy about how the market should work.
Detangling those three distinct stories lets your company communicate in a crowded market.
Any common pitfalls you’ve seen, founders describing their market story in a way that doesn’t land?
I think the common mistake is defaulting to telling the product story. You see that over and over again.
A long time ago, there was a practice called Pragmatic Marketing that was popular in Silicon Valley. The phrase I recall from that is that your job is to be a market expert, not a product expert, because there are already plenty of product experts already inside your company.
What’s scarce is knowledge of the market – why the market is structured a certain way, who buys, why they buy, what language they use for the problem.
There’s no one rule for this stuff. It’s hard. But market over product is generally the right answer.
06 | Rapid fire
What is one narrative or belief in AI you think the industry is too bullish on?
That everything will be reinvented. So many of the SaaS companies have taken a hit under that logic. I think many of those companies will be just fine.
You’re already seeing signs of that. People are realizing that the SaaS companies that own infrastructure or data will be beneficiaries of all the new agents getting deployed. And even the companies people point to as challenged because of AI still have lots of opportunity to innovate, to add agents as a first-party consumer of their products.
Don’t forget that these incumbents have an enterprise agreement with every account a startup wants to sell into. That distribution is not easy to unseat.
What’s your favorite AI-native product today, Dome aside?
That’s easy. Self-driving cars. It’s such a good illustration of the new paradigm we’re in.
The first four or five generations of Waymo were built deterministically – inventorying every rule, every road, and running if-then as the car interacts with the world.
The new version is just an LLM running on top of a GPU in every car – taking inputs in the form of code, giving it to a model that makes a decision, and then commands the tools to do things. It’s a probabilistic application, and it’s 1,000x better than the deterministic model just five years ago.
What’s the best piece of advice you got before you launched Dome, and who gave it to you?
My wife told me – don’t do something later stage, because you’re always drawn to these cutting-edge platform transitions. I think that’s good advice. I find these things energizing. They’re unstructured, messy, with tremendous opportunity to provide clarity in those kinds of markets.
I think we covered it, thank you so much.
I find this stuff so cool. Thanks for the opportunity to chat.
Terraform is HashiCorp’s flagship product, an open-source tool that lets engineers define their cloud infrastructure – servers, networks, databases – in configuration files and provision it with one consistent workflow across AWS, Azure, Google Cloud, and hundreds of other providers. Its provider architecture, that anything with an API can plug in, is the compounding design referenced here.
LLM-as-a-judge is a technique where a language model is used to evaluate outputs or make rule-based decisions in place of hand-written logic or human review. In a governance context, rather than writing an explicit policy, you ask a model to assess each action against a standard written in natural language.
Cedar is an open-source policy language created by AWS for writing and enforcing authorization rules – who (or what) can perform which actions on which resources. Policies are deterministic and formally verifiable.
MCP (Model Context Protocol) is an open standard for connecting agents to tools and data, increasingly the default interface for agent tool calls.
A WAF (web application firewall) is a security layer that sits in front of a web application and inspects every incoming request in real time, blocking attacks before they reach the app.