Vendor Consolidation and the Platform Play

Every security vendor is a platform now. Check any vendor's homepage and you'll find the word within the first scroll — platform this, unified that, one console to rule them all. The industry has decided, collectively and loudly, that the future is fewer vendors doing more things.

There's a real argument underneath the marketing. Any security leader will tell you the integration tax is brutal: a dozen best-of-breed tools means a dozen agents on every endpoint, a dozen consoles, a dozen data models that don't quite line up, and a SIEM in the middle trying to translate between all of them. Alert fatigue isn't just a staffing problem; it's an architecture problem. When your EDR, your email security, your cloud posture tool, and your identity provider all see the same attack from different angles and can't agree on what happened, that's not defense in depth. That's confusion in depth.

Consolidation promises to fix this: one agent, one data model, one console, one throat to choke. And in fairness, when it works, it's genuinely better. Correlating an endpoint detection with an identity anomaly and a cloud misconfiguration in a single timeline — without building custom integrations — is the kind of thing that makes analysts' lives materially better. The platform vendors aren't selling nothing.

But let's talk honestly about the tradeoffs, because the pitch decks don't.

First, best-of-breed exists for a reason: depth. The vendor that does one thing obsessively is usually better at that one thing than the platform vendor's fifth acquisition, still half-integrated, wearing the platform's logo. Consolidation means accepting "good enough" in categories where you used to have "excellent." Sometimes that's the right trade. Sometimes the category where you downgraded is the one the attackers walk through. Nobody puts that in the business case.

Second, lock-in is real and it's priced in. Moving to a platform is easy; moving off one is a multi-year migration touching every team. The vendors know this. The discounts are generous in year one and the renewal math is different in year three. I'm not saying it's a trap — I'm saying it's a commitment, and it should be evaluated like one, with eyes open about exit cost.

Third — and this is the one that keeps me up — concentration risk. We spent last summer learning what happens when a single vendor's bad update can take down 8.5 million machines. The platform play, taken to its conclusion, is more eggs in fewer baskets, by design. A unified platform means a unified failure domain. The vendors will tell you their testing and staged rollouts make this safe. They told us that before, too.

None of this means consolidation is wrong. For a lot of organizations — especially ones drowning in tool sprawl with a three-person security team — fewer, better-integrated tools is obviously the right answer. The mistake is treating it as a strategy instead of a tradeoff. "We're consolidating" isn't a plan. It's a direction, and directions need destinations.

Here's what I'd actually evaluate, stripped of the slideware: can you get your data out, in a usable format, on demand? How good are the APIs really — not the documented ones, the ones you'll actually need at 2 AM? What's the honest exit cost, in engineering months, not license dollars? And does the platform's weakest module cover a category where weakness gets you breached?

The vendors all want to be your platform. That's their business model, and it's a fine one. Your business model is different: it's not getting breached. Keep those two models separate in your head, and the consolidation decisions get a lot clearer.

AI Agents in the Enterprise: Hype vs. Production

Every vendor demo this year follows the same script. A smiling presenter gives an agent a vague instruction — "handle the onboarding for our new hire," "triage these support tickets" — and the agent proceeds to do ten magical things in sequence: reading email, querying systems, drafting documents, updating records. The audience applauds. The pilot gets approved.

Then the pilot meets production, and production has questions the demo never asked.

The gap between the demo and the deployment is where agentic AI currently lives, and it's wider than the marketing suggests. Not because the technology doesn't work — it does, often impressively — but because a demo is a controlled performance and production is an uncontrolled environment. The demo has clean data, cooperative tools, and a presenter standing by. Production has expired credentials, APIs that changed last Tuesday, ambiguous instructions from tired humans, and edge cases nobody wrote down.

Start with the most boring problem: permissions. An agent that can "handle onboarding" needs access to HR systems, IT provisioning, badge systems, and half a dozen SaaS tools. In the demo, someone handed it a god-mode service account. In production, your identity team takes one look at that and has a completely reasonable panic attack. Scoping an agent's access to least privilege — while keeping it useful — is a genuine engineering problem that no framework hand-waves away. Every enterprise running agents in production has a war story about the agent that could read everything and write to more than it should have.

Then there's the 3 AM test. A demo runs for eight minutes with a human watching. Production runs unattended, at night, when things break. What does your agent do when the third tool in its chain returns an error it's never seen? The honest answer, for most current implementations, is: something unpredictable. Maybe it retries in a loop and burns through a budget. Maybe it hallucinates a workaround. Maybe it just stops, silently, and nobody notices until morning. Building agents that fail loudly and safely — that know when to escalate to a human instead of improvising — is the actual work, and it's the work nobody puts in the keynote.

Cost is the sleeper issue. Agentic loops consume tokens the way a teenager consumes data: constantly, and more than you estimated. A single complex task can involve dozens of model calls, tool invocations, and retries. Multiply by real volume and the bill arrives with an expression you haven't seen from finance before. The teams succeeding here instrument everything — per-task cost, per-tool latency, retry rates — and treat the agent like a system to be optimized, not a magic box.

And then there's evaluation, the least glamorous and most important discipline in the whole space. How do you know the agent did the right thing? "It looked right in the demo" doesn't scale. Production agent teams are building eval harnesses — replaying historical tasks, scoring outcomes, catching regressions when the model or the tools change. It's testing, basically. The industry spent fifty years learning that software needs tests, and now we're rediscovering it for agents, one incident at a time.

I want to be clear about where I land on this: the technology is real. I've seen agents do genuinely useful multi-step work that would have been science fiction three years ago. But the deployment discipline is years behind the demos. We have 2025-era agent capabilities wrapped in 2015-era operational maturity — no serious evals, no cost controls, permissions by vibes.

The enterprises that will win with agents aren't the ones running the most pilots. They're the ones doing the boring work: scoped credentials, failure modes, evals, observability, cost accounting. The demo gets the applause. The plumbing gets the production deployment.