Why Today's AI Agents Don't Scale

Why Today's AI Agents Don't Scale — and What Will Change That

A practitioner's perspective on where multi-agent tooling actually stands today.

Working with today's agent tools produces a strangely familiar feeling. Terminals, configuration files, command-line paths, manual copy-and-paste of context between tools. With one agent, this works. With several running in parallel, you lose the overview. And suddenly it all reminds you of something you thought was long behind us: MS-DOS in the early 1990s, just before Windows arrived.

Diagnosis: We are in the DOS phase

Anyone working with agents today — in a coding setup, a CRM configuration, or an experimental multi-agent workflow — knows the picture: command-line tools, YAML or JSON configurations, manual connections to data sources, context windows you fill by hand, outputs you pass from one agent to the next. Running one agent is manageable. With three, things get cluttered. With ten — say, in a real end-to-end process from lead qualification through quote to after-sales service — today's tooling landscape simply cannot orchestrate cleanly.

Picture a typical sales process: one agent qualifies incoming inquiries, a second drafts initial quotes from that, a third takes over service initiation after order receipt. The question anyone who has actually built something like this can answer honestly: who hands what context to whom? Who documents one agent's decision so the next can pick it up traceably? Who notices when something has gone wrong and steps in?

This is precisely the experience DOS users had in the early 90s. Powerful — for the initiated. Enterprise-ready at scale — not.

What Windows brought back then

The graphical revolution comes down to three things. A visual metaphor: windows, desktop, file manager — a surface where you could see what was running. Parallel visibility: several applications at once, each with clear status. And consistent behavior between applications: copy-paste, drag-and-drop, shared interaction patterns.

These three things are largely missing from agents today. There is no surface where multiple agents work visibly side-by-side and make their handovers traceable. Agents often run as black boxes, with no orchestration view, no clean status trail. And there is no consistent behavior between them — each calls each other differently, every interface has its own conventions, context handover is manual work.

Initial standardizations are emerging: protocols for tool integration, early approaches to agent-to-agent communication. But that corresponds more to the step from pure DOS to a more comfortable DOS shell than to the leap to Windows. The actual operating model for multi-agent workflows in enterprises — persistence, handovers, observability, error handling as natural parts of a platform — is still missing.

Where the analogy breaks down

Three breaks are worth knowing, otherwise a useful image becomes a misleading one.

1. Vendor Landscape: DOS was a single vendor's system, replaced by Windows from the same vendor. The agent world is heterogeneous — different models, providers, architectures. A single “Windows layer” is unlikely to emerge; what's more probable is a bracket of open standards, with several competing surfaces sitting on top.

2. User Diversity: Back then, the goal was to lift one user type out of the command line. Today, power users and business processes coexist. Both need answers — and that is a more demanding task than 1995 was.

3. Timeline: That earlier transition took roughly a decade. Here, we are likely talking about two to three years. That changes preparation, because there is no time to get everything right on the first attempt.

The race for the orchestration layer

Several actor groups are approaching the same point from different directions: the layer above individual agents that handles handovers, status, error handling, and persistence.

• LLM providers are increasingly extending their tooling toward this orchestration layer — with standards for tool integration, desktop applications, modular skill concepts.
• The hyperscaler platforms are building their own agent studios and positioning their existing cloud infrastructure as the natural home for multi-agent workflows.
• The CRM and business application platforms are betting that orchestration most sensibly emerges where data, business logic, and processes already live — on their platform.
• In parallel, open frameworks and open-source projects work on the same question, with the advantage of vendor independence and the disadvantage of lacking enterprise readiness.

Who will write the Windows of the agent era is open. Most likely, no single layer will emerge, but a market picture with two or three dominant orchestration platforms, held together by open standards. What is certain: several strong actors are investing heavily, and positions are unsettled.

Consequences for B2B industrial companies

Three conclusions can be drawn today — neither in hype-driving mode nor in wait-and-see mode.

1. Pilot projects are sensible, but should be classified as what they are: learning experiences in the DOS phase. They show what is technically possible, sharpen process questions, and build internal experience. The expectation, however, that they will scale seamlessly into complex end-to-end processes once the right tool is at hand is unlikely to be met within the next one to two years.

2. Examine the platform strategy honestly. Which orchestration layer fits the existing IT landscape? Those centered on a particular business application platform will need to watch its orchestration offerings carefully. Hyperscaler-centric architectures will reach different answers. Hybrid scenarios — the norm in mature B2B landscapes — will be the most demanding category. This conversation cannot be delegated.

3. Document processes now in agent-ready form. This is the preparation that already counts today — regardless of which layer eventually prevails. Cleanly described processes with clear handovers, documented decision logic, and defined escalation paths are, in any agent scenario, the prerequisite for automation to be more than a gimmick. Anyone neglecting this will end up building twice in the Windows phase.

What remains

Transition phases are usually recognized only in hindsight. The challenge is recognizing them looking forward — without falling into the hype. Anyone who dismissed DOS in the early 90s as “still unusable” missed the leap into the next phase. Anyone who dismisses today's agents as “not yet ready” could make the same mistake. But the opposite is also true: anyone who declares every agent pilot a productive business process is mistaking the DOS phase for the Windows phase.

The sober answer is the old one: processes before tools. Even — especially — in the DOS phase.