Agentic workflows are still not there

Walk into any enterprise six months into AI adoption and you'll find the same scene. There's an agent in Slack summarizing channels. Two more inside Notion. A pricing assistant in Stripe. A code reviewer in GitHub. A research bot somebody's intern built in Replit and forgot about. Someone connected ChatGPT to the CRM via Zapier. The CTO is sponsoring a "unified AI strategy." Meanwhile twelve teams are running thirty-eight agents. Nobody knows what they cost, what they touch, or who owns them. Not security. Not finance. Not engineering.

This is the agent sprawl problem. It's the second wave of shadow IT, except this time the shadow systems can write to production databases.

We've been watching this play out across every customer over the last quarter. Enterprise teams need to make one architectural decision in 2026 before any of the other AI decisions matter.

The scope of what's broken

The failure modes split into visible and invisible.

The visible ones: inference costs that grew 4x year-over-year with no attribution to which team or use case drove them. Security teams discovering an agent has been writing to a production database for three months because someone wired it up through a no-code automation tool. Compliance officers in finance, health, and government quietly killing AI pilots because no one can answer the auditor's first question: what touched the data?

The invisible failure mode is the one nobody flags in a status meeting. It's velocity. Every team is reinventing the same five patterns: an internal copilot, a customer-facing assistant, a code reviewer, a research helper, a workflow trigger. None of them share infrastructure. The same agent gets built six times across six teams. The same authentication problem gets solved six times. The same observability gap exists six times. By the time the executive team gets serious about "AI strategy," there's a year of fragmented investment that doesn't compose into anything.

The deeper problem is ownership. In the previous era of enterprise software decisions, somebody owned the architectural choice. The CIO owned the cloud decision. The CISO owned the security perimeter. The CFO owned the procurement model. With AI, the decision got made by everybody and nobody at the same time. Every team adopted tools faster than any central function could evaluate them. The people who would normally draw the architectural lines were busy approving budget requests for the next pilot.

Nobody owns AI architecture inside most enterprises right now, because everybody owns AI.

How this happened (and why it's not the teams' fault)

This was rational at the team level and incoherent at the company level.

When a frontier model gets ten times better in a year, no team can afford to wait six months for IT to evaluate a platform. So every team picks its own stack: the model, the orchestration framework, the deployment target, the observability layer. And ships.

The result is exactly what you'd expect. Dozens of working solutions. No architecture.

This is the same dynamic that produced SaaS sprawl in the 2013–2018 cycle, compressed into eighteen months. The difference matters. SaaS sprawl was a finance problem and an integration headache. You ended up with seventeen tools doing roughly what three could do, and consolidation projects took years.

Agent sprawl is a different category of problem. Agents aren't just applications. They have agency. They write code that runs in production. They hit APIs that move money. They make decisions that affect customers. When the inventory you can't see is a list of dashboards, the worst outcome is a budget overrun. When it's a list of agents, the worst outcome is something you'll be explaining to a regulator.

This reads as a tooling problem, fixable with another procurement cycle and a vendor RFP. It's not. What got skipped is an architectural decision. Architectural decisions don't get unmade by buying more tools. They get unmade by deciding what the layer beneath the tools looks like.

The architectural choice nobody's making yet

The question is what the architectural decision is about. We think it comes down to three properties. The layer running your agents has to provide all three. No enterprise we've talked to has any of them yet.

Visibility. You can see every agent operating inside your environment. Not "we surveyed our teams and they reported 38 agents." Actually observable, in a single place, by the people responsible for the perimeter. What's running, what it costs per call and per day, what it last touched, who deployed it, when it last changed. This sounds basic. Today, most enterprises cannot produce this list, because no central system has it.

Governance. You can stop one. Or scope it. Or sandbox it. The ability to say "this agent can write to these specific systems and no others" and have it enforced at the execution layer, not relied on at the prompt layer. Today, most "guardrails" are instructions sitting inside a system prompt that the next jailbreak could undo. That's not governance, that's hope. Real governance is the ability to revoke an agent's access to production at 3am from a single console and have the agent stop, immediately, everywhere.

Accountability. You can bill it back. Cost attribution by team. Performance attribution by use case. ROI attribution at all. If you can't tell finance which team's agent generated this week's inference bill, you can't make any rational allocation decision in next year's budget. Today most enterprise AI spend is allocated by hand, after the fact, with disputes.

These three properties are not solved by buying a unified AI platform from any single vendor. The agents you need will come from different places: your own engineering teams, vendor-shipped agents, open-source ones, agent marketplaces that don't exist yet but will by next year. The execution layer has to be model-agnostic and origin-agnostic. Anything that assumes you'll buy all your agents from one place is solving a smaller problem than the one you actually have.

Where this leaves us, and where it leaves you

Here's where CreateOS is. We're not telling you we've solved agent sprawl today. We're telling you we think this is the architecture problem worth solving, and we've been building toward it.

What's shipped today is Multi-agent Create. It's a builder layer for shipping full-stack AI apps end-to-end. Parallel agents — frontend, backend, database, reviewer — take a plain-language prompt to a deployed application in under fifteen minutes. That's a builder problem solved, not a governance problem solved. We're clear-eyed about which one is which.

What we're talking to a small number of enterprise design partners about is the execution layer underneath. The properties above — visibility, governance, accountability — are the spec we're working from. The partners we're working with are the ones who can tell us whether the spec is right before we ship the wrong thing.Our bet is that by 2027, the question of what runs your agents will be a board-level decision in regulated enterprises the same way what runs your data is today. We'd rather be early than right on schedule.

If you're inside an enterprise with twelve teams, thirty-eight agents, no central view, and a CTO sponsoring a strategy that doesn't exist yet, we'd like to compare notes. Not pitch. Compare notes.We're taking a small number of design partners over the next quarter. The bar is real enterprise context and willingness to share what's actually happening. In return we'll share what we're seeing across the rest of the conversations and what we're building toward.

The architectural decision your team didn't make in 2025 is the one that matters most in 2026.

We think there's still time to make it deliberately. Reach out at business@nodeops.xyz if you want to make it together.