Levi Strauss spent a year building function-specific AI agents — one for HR, one for finance, one for IT, one for retail operations. Then, in a Microsoft customer story published on 4 June 2026, it described the next move: a single “Super Agent” inside Microsoft Teams that sits on top of all of them. An employee asks about inventory, files an IT ticket, or starts an HR process, and one conversational entry point routes the request to whichever underlying agent should handle it. No more knowing which system owns what.

It’s a clean piece of product design. It’s also, underneath, an architecture decision wearing a product name — and it’s the same decision that’s now landing on every enterprise that built more than one agent. Databricks reported multi-agent workflows grew more than 300% as organisations moved from pilots to production in early 2026. Once you have several agents, you have to decide how they relate to each other. There are two shapes, and enterprise architecture has strong opinions about both because it has built both before.

For the rest of us: what a “Super Agent” actually is

Companies didn’t set out to build a fleet of agents. They built one for the HR team because HR asked, one for finance because finance asked, and so on — each solving its own problem, each with its own way in. Then employees were left holding four different chat windows and no idea which one answers a question that spans two departments.

A Super Agent is the layer that fixes that: one thing you talk to, which figures out where your request should go. The interesting question is what sits behind that single front door — and there are two ways to wire it.

In hub-and-spoke, one orchestrator agent sits in the middle and every other agent hangs off it. The hub receives your request, decides who handles it, and passes it down. In mesh, the agents talk to each other directly as peers — no single boss, they coordinate among themselves. Both give the employee one entry point. Underneath, they behave very differently when something goes wrong or someone asks who’s in charge.

The two shapes

Enterprise architecture has run this experiment

Here’s the part that should make anyone who lived through 2010-era integration projects smile. This is not a new problem with a new answer. It’s the Enterprise Service Bus versus point-to-point debate, wearing 2026 clothes.

The ESB was the hub: route everything through one central bus, and you get one place to enforce policy, one place to monitor, one schema to reason about. It was also one place for everything to break, and over time it tended to become a bottleneck that every project had to negotiate with. Point-to-point integration was the mesh: systems talked directly, which was resilient and fast to extend — until you had two hundred undocumented connections and no single place to see what talked to what, or to change a rule everywhere at once.

Neither won outright, because they’re not really competing on quality — they’re trading the same two things in opposite directions. Hub-and-spoke concentrates your blast radius and your control in one place. Mesh distributes both. If the orchestrator is wrong, or down, or compromised, everything routed through it is affected at once — but you also have exactly one place to audit, budget, and govern. A mesh has no single point of failure, and no single point of control either. When an agent in a mesh misbehaves, there’s no central chokepoint that saw it happen.

That symmetry is the whole decision. You are not choosing which architecture is better. You are choosing where you want your single point of failure and your single point of control to be — together in the hub, or dissolved into the mesh.

Why the blast-radius question comes first

For agents specifically, the concentration argument is stronger than it was for plumbing, because agents act. An ESB that routed a malformed message caused a failed transaction. An orchestrator that routes a request to the wrong agent — or is manipulated into doing so — can cause the wrong action to be taken in a real system: an order placed, a record changed, a payment released. The blast radius isn’t just data anymore; it’s behaviour.

Which is why, for a controlled employee-facing rollout like Levi’s, the hub is a defensible choice: one Teams interface, one orchestration layer on Microsoft Foundry, one place where routing, permissions, and audit live. When the priority is governability over raw resilience — and inside a company’s own operations, it usually is — you want the single point of control, and you accept the single point of failure as the price. You just have to know that’s the trade you made, and harden the hub accordingly.

What this means

The “Super Agent” framing is good marketing and slightly dangerous procurement, because it hides an architecture decision behind a feature. When a vendor or an internal team proposes one, the useful questions aren’t about the brand. They’re the old EA questions, unchanged: Where does the blast radius concentrate, and is that node hardened for it? Where does governance live — one place, or nowhere in particular? What’s the coordination cost as you add the fifth, tenth, twentieth agent?

I run a small version of this on my own server: Hermes coordinates a couple of sub-agents, and even at that scale I had to decide whether it bosses them or they negotiate. The answer for me was a hub, for exactly the reason Levi’s likely chose one — I wanted a single place to see and stop what the whole system was doing. The org chart for your agents is a real org chart. Draw it on purpose, before the product name draws it for you.

References