The industry is in the middle of one of those transitions that look obvious in retrospect and feel chaotic in real time. GenAI to agents. Or to use the framing every CIO is using on calls this quarter: from “we have a chatbot somewhere on the site” to “we have eight agents wired into our production systems and our compliance team has questions.”
The transition is happening fast. Enterprise applications integrating task-specific AI agents are projected to go from under 5% at the start of 2025 to roughly 40% by the end of 2026. Eight times growth in a single year. The buyers we talk to are not asking whether to ship agents. They are asking whether their company is on the right side of that curve or the wrong side.
The transition is also breaking things. 88% of organizations that have shipped agents in the last year have reported a confirmed or suspected security incident. Only about 14% of agents reach production with full security and IT approval. Executive confidence in agent controls runs around 82%. The 67-point gap between what executives believe is in place and what is actually in place is the canonical 2026 problem.
The buyers who do this best end up looking like Legacy: email-only at go-live, four channels twelve months later, 8x case volume, and named owners tied into the workflow the whole way. The buyers who do this worst end up with agent sprawl, weak controls, and security work starting after production.
What 2026 made concrete
Some incidents are mostly a vibe. The 2026 agent-platform incidents were not. They were multi-vector failures with named CVEs and counted artifacts.
Control-plane compromise, including one-click remote code execution patterns exploitable against localhost-bound instances by tricking an authenticated user into visiting a crafted page. The gateway did not need to be internet-facing to be compromised.
Marketplace risk, where a public skills registry ran without meaningful customer-level governance on uploaded skills. Researchers confirmed malicious skills across the registry at peak; many looked benign in the listing and targeted developer workstations.
Tenant isolation failures, including social-style agent layers exposing unsecured databases containing emails and agent API tokens after they had grown to large active agent counts.
Publicly exposed instances with insecure default configurations: weak or missing authentication on administrative endpoints, default passwords on internal databases, and open ports that were intended for local-only access.
None of this is best understood as one clumsy team. Agent platforms discovered the failure modes the same way every previous wave of new infrastructure discovered them: in production. The lesson is structural. When governance is a feature you bolt on, you ship with it off until you remember to turn it on, and the difference between “remember” and “forget” is a CVE on the front page of Hacker News.
The architectural answer
The Atlas thesis is older than the 2026 incident cycle, but the cycle made the thesis legible to enterprise buyers in a way no number of pitch decks could.
The substrate-first design choice that Atlas makes: every property a security or compliance team needs is an invariant of how the substrate runs, not a feature an operator opts into. You cannot turn off source receipts. You cannot turn off owner checkpoints on actions that touch sensitive external systems. You cannot turn off the audit log. You cannot disable tenant isolation. Each would require a substrate-level code change, and each is gated by a contract that says we will not make that change without your security team in the loop.
The incident pattern maps to this directly. Control-plane compromise is the failure mode of an agent control plane built without the assumption that authenticated UIs will be attacked via the browser. Supply-chain abuse is the failure mode of a marketplace built without provenance and customer governance as a substrate property. Token exposure is the failure mode of an agent-to-agent layer built without tenant isolation at the database level. None of these failures are exotic. They are the failures you get when governance is treated as a feature backlog item rather than as a substrate primitive.
What Legacy proves
Legacy is the customer evidence that the substrate-first design works in production over time, not just in pitch decks.
Twelve months on Atlas. Started with email-only support deflection. Added web chat as the second channel once email proved itself. Added voice agents on inbound calls as the third channel. Added agents integrated into their CRM and kit-ordering system as the fourth channel, using connectors from the Clarm catalogue. Total case volume across all channels in month twelve is roughly 8x what it was in month one. Named owners have been tied into the workflow the entire twelve months. There has been no board meeting about an agent doing something outside the approved ground layer.
The Legacy progression is the answer to the question every enterprise team is asking right now: “How do we get the agent-deployment lift without becoming the next security headline?” The answer is to start with the channel that is the hardest to embarrass yourself on, build trust in the substrate over months not days, and let the integrated agents come last after the governance posture has been audited a dozen times by your own team.
What we are not saying
We are not saying open-source frameworks are the wrong category. For many teams it will be the right answer in 2027 or 2028 once the security tooling around agent frameworks catches up.
We are saying: in May 2026, the enterprise reality is that the substrate has to do the work governance teams expect, on day one, by default, with no toggles. The buyers we talk to who have shipped a single agent and now want to ship eight are not arguing about whether they need this. They are asking who has the architecture today.
Atlas has it today. Read the architecture, read the Legacy case study, or book a pilot discussion if your team is having the agent-scale conversation now.