Leadership - 2026-08-17 - 3 min read

Closed Source Isn't a Moat. Here's the Filter I Actually Use.

Secrecy alone is a head start, not a moat; the real filter is whether an asset gets more or less valuable as the underlying model improves, which is what actually decides what's worth protecting.

MoatOpen SourceGovernanceOrvena

Originally published on LinkedIn on August 17, 2026.

Three posts in, I've shown you a schema for organizations and a runtime for containing agents. Neither one's defensibility comes from secrecy — Orvena's source has been public the whole time. I think the instinct to keep things closed and call the secrecy a moat is one of the more common mistakes I see people make when they're deciding what to build.

Dynamic-schema platforms, sandboxed agent runtimes, spec-driven generators — these are known patterns. Someone can rebuild most of what I've described here without ever reading my source. If "nobody can see it" is doing the load-bearing work in your defensibility story, you don't have a moat, you have a head start, and head starts erode on a timeline set by everyone else's model, not yours.

So I run a different filter now, and I run it on myself before I run it on anything else: when the underlying model gets better, does this asset get more valuable or less? An intermediate layer that exists to make code generation cheaper — templates, scaffolding, an IR that turns plain language into an app faster — gets less valuable every time the frontier model improves, because the model is closing the gap the layer was built to bridge. A layer that exists to make a human's intent checkable — versioned, diffable, something you can hold someone accountable for — gets more valuable on the same timeline, because a more capable, more autonomous agent makes "can I verify what it actually did" a harder question, not an easier one.

That filter is also why I hold myself to kill criteria instead of just conviction. If a regulated buyer tells me plainly that a vendor log is good enough and they won't pay for agent-level evidence, the governance bet is wrong, and I'd rather find that out from one honest conversation than keep building past the point where it stopped being true. A bet you can't describe a way to lose isn't a bet, it's a hope.

None of this makes the code itself worth protecting. What's worth protecting — and worth versioning, and worth showing someone — is the reasoning underneath it: what I chose to build, what I chose not to, and what would have to happen for me to admit I was wrong. That's the actual throughline of these four posts, and it's the same answer to a different question each time: the org schema makes an organization's premises checkable, Orvena makes an agent's report checkable, and this is what makes my own bets checkable.

If "AI architect" is going to mean anything more than knowing which framework to reach for, I think it has to include being the kind of person who writes the kill criteria down before you need them.

Working on something like this?

I help teams ship AI-native systems — architecture, governable autonomy, and the evidence discipline to back them. One conversation is enough to see whether it fits.

Discuss fit