Classical IT was a tool. Agentic IT is architecture. Four layers — data foundation, model access, orchestration, governance — contain strategic decisions that cannot be delegated to IT.

The IT question after the agent turn

Essay #005 · 2026 · Reading time 6 min · Field: IT / Digitalization · Market: Mittelstand

When a Mittelstand company introduced IT thirty years ago, the question was clear: which system do we buy, how do we integrate it, who operates it? The answer lay in a software solution — an ERP, an accounting package, a CRM. IT was a tool. The business processes were the actual structure, and IT helped make them more efficient.

In the age of agents, this relationship tips. IT is no longer a tool. It becomes architecture. What exactly is meant by that is the topic of this essay — and why the question of how your company handles IT will matter more in the coming three years than in the past thirty combined.

Tool versus architecture

Tool and architecture are two ways of thinking that ask different questions.

The tool mindset asks: what problem do we have, and what tool solves it? The answer is a purchase or an in-house build. Responsibility usually sits with an IT department or a service provider. The leadership is informed, approves, and otherwise stays out.

The architecture mindset asks: how does our company take shape when we build this technology in as load-bearing? The answer is not a purchase — it is a structural decision. It determines which ways of working are possible, which roles remain meaningful, which data flow where, which decisions are made automatically and which remain human.

Classical IT was a tool. Agentic IT is architecture. The distinction sounds linguistic but is real: those who treat agentic IT as a tool buy inadvertent structural decisions along with it.

Four layers of an agentic enterprise architecture

A load-bearing agentic IT has four layers. The leadership does not need to master each layer technically. But it must know that these layers exist — and who in its house is responsible for each.

First layer: data foundation. Which proprietary data does the company have, and how are they made accessible? That sounds trivial — it is not. In most Mittelstand companies, data sits scattered across so many systems that agentic systems can only be built on top once order has been established. Establishing that order is work, and it must be done carefully, because later decisions rest on it.

Second layer: model access. Which agentic models are used, under which conditions, with which guarantees? This is the layer that changes fastest. Those who today make a long-term decision for a particular model are building on sand. The model layer should therefore remain flexible — a switch of the underlying model must not throw the whole company into turmoil.

Third layer: orchestration. How are the various agents and models connected into end-to-end workflows? This layer decides what the company can actually do with its agents. A single agent is not especially useful. A chorus of agents working well together can take over a substantial portion of office work. Building and maintaining orchestration is the most complex of the four layers — and the one most likely to require own work.

Fourth layer: governance. Who is allowed to use which agents for which tasks? How is it traced who decided what, and when? What may an agent do autonomously, what must be approved by a human? This layer is the one most often forgotten — and the one whose absence produces the most expensive frictions later. Data protection, liability, compliance: all rest on this layer.

Why this architecture is an entrepreneur’s topic

Each of these four layers contains decisions that change the company at its core.

The data foundation decides which knowledge becomes structurally accessible and which remains in silos. Who controls whether silos get dissolved — or not? The IT lead? The affected department heads? Or leadership, because these are strategic questions?

Model access decides which external vendors the company becomes dependent on. That is a question very close to classical corporate strategy. Who decides it?

Orchestration decides which workflows get automated and, with it, their logic locked in. This is the question of what flexibility the company retains in the future — and what it gives up.

Governance decides how the company acts when something goes wrong. These decisions are rarely made before things go wrong. But those who do not make them leave them to chance.

If all this is IT decisions — and not entrepreneur’s decisions — then IT has a power it should not have. Not because the IT leadership means ill. But because it is the wrong authority to decide strategic questions with long-reach consequences.

Three patterns that fail

“Our external service provider does that.” A digital service provider you have worked with for ten years gets the mandate to build agentic infrastructure. That is comfortable because you trust the provider. It is problematic because governance decisions get outsourced to a partner whose interests are not fully identical with your own. The provider builds an architecture that stabilizes its own business — not necessarily the one that serves the customer strategically best. Operational help with building individual layers is different; problematic is when the same provider makes the architecture decision that it will then build.

“We buy a ready-made suite.” A large vendor offers a complete solution covering all four layers. That reduces the complexity of the decision to a single signature. Tempting, but the deepest form of lock-in possible in this context. Those who buy all four layers from one vendor have given up their architectural independence.

“We build everything ourselves.” An internal tour de force with the goal of maintaining maximum control. Can work in exceptional cases, but in most companies ties up more capacity than the actual core justifies. You bind resources that are missing elsewhere.

What works instead

What works is a hybrid architecture with clearly defined in-house and bought-in parts. Leadership decides which layers the company must control itself and which it can purchase. The data foundation usually belongs in-house. Model access is kept swappable. Orchestration is partly bought, partly in-house. Governance is fully an entrepreneur’s matter.

This decision cannot be made from an IT paper. It requires the decision-maker to understand what each layer delivers — and where the strategic levers sit. That is the spot where the entrepreneur’s participation becomes irreplaceable. Not to master the technology, but to inhabit the structure.

The actual point

The IT question after the agent turn is no longer an IT question. It is a question of enterprise architecture — and with it a question of leadership. Those who delegate it delegate not technology. They delegate strategy.

The companies that stand structurally strong in five years will be those whose leadership has understood the four layers — not in the detail of every line, but in their strategic consequences. These leadership teams will have made decisions that cannot be captured in a spreadsheet. They will have taken positions that are not immediately obvious from the outside. They will have overcome resistance from their own IT departments.

And they will know their architecture. That is the difference.

— Axel Roth