The End State Is Not One Vendor

Securing the Agentic Era — Edition 4

I watched a product demo recently where the same system wrote a piece of code and then, in the next breath, told me it was secure. Generate, then verify, one smooth flow, one vendor, one screen. The room nodded. It looked like the future: no integration, no seams, no arguing between tools. One platform that does everything.

I have given versions of that demo myself. And I have started to think the smoothness is the problem.

The question I get most often from enterprise leaders right now is some form of "when does this consolidate?" Which vendor is going to win the agentic stack. When can they stop stitching tools together and buy the one platform that generates, orchestrates, tests, secures, and ships. The instinct behind the question is reasonable, and it is also, I think, about to lead a lot of smart organizations somewhere they do not want to be.

Here is the contrarian position, stated plainly: the end state of the agentic stack is not one vendor. It is not even mostly one vendor. It is deliberate coexistence, and the sooner you architect for that as the goal rather than a phase you are waiting to grow out of, the safer and more durable your setup will be.

Why consolidation feels inevitable, and why that instinct is now stale

The pull toward a single vendor is not irrational. It comes from the last two decades of software, where the main cost of using many tools was integration. Every additional vendor was another contract, another dashboard, another data model to reconcile. Consolidation genuinely reduced that overhead, so "one pane of glass" became a real and reasonable goal. Buyers learned to treat fragmentation as friction and consolidation as maturity.

That calculus was correct for the world it came from. It is being quietly imported into a world where it no longer holds. In the agentic stack, the thing you gain by consolidating, one vendor handling generation and verification together, is exactly the thing that removes the property you most need. And most people making the consolidation argument have not noticed the trade they are making, because in the old world there was no trade. Integration overhead was a cost with no hidden benefit on the other side. Independence between your tools was an accident, not an asset. Now it is the asset.

The property consolidation destroys

The whole of my thinking in this series comes back to one line: the generator cannot be its own auditor.

When the same system writes code and checks it, the check inherits the writer's blind spots. It cannot flag the assumption it did not know it was making, because the same model made that assumption in both roles. This is not a claim about any particular vendor being careless. It is structural. A reviewer that shares the author's context shares the author's errors. We know this in human systems, which is why the person who wrote the code is not the person who signs off on the release, why the maker is not the grader, why auditors are independent of the companies they audit. We built separation of powers into every serious system that has to be trusted, precisely because self-certification is not certification.

The agentic stack is now colliding with this principle at speed. The most convenient version of the future, the seamless single vendor, is the one that collapses generation and verification into the same context, the same model family, the same incentives. It feels like progress because it removes friction. It is removing the friction that was doing the checking.

Coexistence, in this light, stops being a tolerance you extend while the market sorts itself out. It becomes a design requirement. You want the thing that builds and the thing that verifies to come from different places, with different assumptions and different incentives, for the same reason you want an external auditor. Not because multi-vendor is philosophically nicer. Because independence is a security property, and single-vendor consolidation spends it.

What this means for how you architect

If you accept that, a few things follow, and they cut against the current buying instinct.

Treat verification as deliberately independent, by policy. The system that checks your AI-generated code, config, and actions should not be the system that produced them. That is a line worth drawing explicitly in your architecture, not a preference to be traded away for a smoother procurement.

Stop treating multi-vendor as a temporary state. If you are designing your stack as a waiting room until one platform is mature enough to absorb everything, you are designing toward the exact configuration that removes your independent check. Design for coexistence as the destination. Build the integration seams as first-class, not as scaffolding you intend to tear out.

Keep the handoff between systems, do not engineer it away. When work passes from the system that builds to a separate system that checks, that handoff is the moment an independent set of eyes gets to look at it. It feels like friction, an extra step, an extra tool, an extra integration. But that step is where the second opinion lives. Remove it in the name of a smoother experience and you have not just saved a step, you have removed the only point where something other than the builder examined the work.

Ask vendors the separation question directly. When one product both generates and secures, ask how the checking is independent of the building. Not whether the check is good. Whether it is independent. If the answer is that the same model does both because that makes it seamless, you have learned something important about what you would be buying: convenience bought by deleting the second opinion.

None of this means run ten tools for the sake of it. Sprawl is real and has real costs. The point is narrower and sharper: the one boundary worth protecting on purpose is the boundary between the thing that builds and the thing that checks, even when a vendor offers to make it disappear.

The bigger arc

Every prior edition of this series has circled the same center. What you reviewed is not what runs. Where you put the model is a security decision. The generator cannot be its own auditor. They are all versions of one idea: in the agentic era, trust comes from independence, from separation, from something outside the system being able to check the system.

Consolidation is the opposite motion. It is the market's natural drift toward one throat to choke, one bill, one screen. That drift will be sold to you as maturity, and it will be genuinely convenient. But the agentic stack is the first place where the convenient consolidation and the safe architecture point in opposite directions, and where the friction you are being sold on removing is the friction that was keeping you honest.

So I am not waiting for a winner. I do not think there should be one, at least not across the whole stack. The organizations that come out of this era with systems they can actually trust will be the ones that decided, on purpose, to keep the builder and the auditor apart. That is not fragmentation. It is separation of powers, and we are about to find out how much we need it.

---

This edition builds on earlier ones in the series, including "What You Reviewed Is Not What Runs" and "Where You Put the Smartest Model Is a Security Decision," available in the archive.