The orchestration layer is unclaimed design territory

Microsoft defines agentic systems as software that includes an AI or ML model, orchestration code, and skills or tools. Someone picks the model. Someone builds the skills. The orchestration code sits between them, and if designers are not in the room when it gets written, it ships as an engineering default.

Itamar Medeiros, writing on designative.info, points to where this leads: "Product decisions did not disappear in the age of AI. They moved into orchestration layers." Those discussions happen inside engineering teams, he writes. Designers, researchers, and PMs are often absent when routing rules, memory policies, escalation thresholds, or fallback strategies get set.

Medeiros is specific about scope. AI orchestration decides what happens next, but also what the system remembers, ignores, compresses, or forgets over time. A memory policy is a product decision. An escalation threshold is a trust decision. Both ship without a designer in the room.

The agent extension test asks one question: can I describe how I think about this task clearly enough that an agent applies it to a new case and I endorse the result? Apply this to orchestration. Can the team articulate why request A routes to agent B instead of agent C? Can they state the memory policy clearly enough that they would endorse its outcome for a user they have never met?

Most teams cannot. Because someone categorized the orchestration layer as infrastructure. Infrastructure is not design's problem.

Gartner predicts 40% of enterprise applications will feature task-specific AI agents by 2026, up from less than 5% in 2025. That growth means many more products where orchestration decisions shape user experience. Each one has a routing layer that encodes choices about which agent handles which task, what context transfers, what gets dropped. Calling them plumbing does not make them neutral.

Tejj, writing on the state of design in 2026, spots the gap: agent behavior is often treated as an engineering concern rather than a design responsibility. The fix is concrete. Constraint and policy design become part of the job. Deciding what an agent cannot do, when it must escalate, where human judgment is required.

Benhur Senabathi, writing in UX Collective, wrote something that lands: "I didn't learn to code this year. I learned to orchestrate. The difference matters. Coding is about syntax. Orchestration is about intent, systems, and knowing what 'done' looks like."

This has a consequence. The quality of what gets built is now tied to the quality of design intent that precedes it. If the intent is absent, so is the quality.

Designers have a mental model of where design happens, and that model stops at the interface. Orchestration sits below it, treated as someone else's problem. So the biggest product decisions in agentic software get made in a workspace designers never enter.

Microsoft's framework for agent UX specifies that agents' knowledge, tools and skills, and connections with people and other agents are transparent and customizable. Transparency and customizability are design qualities. Someone has to decide what gets surfaced and what stays hidden. Right now that someone is an engineer writing a config file.

Every team that treats orchestration as pure infrastructure is shipping design decisions without design review. The routing logic and the memory policies are the product. The interface is a window into them. If designers cannot describe how orchestration should work clearly enough that they would endorse the results, they have already given up the product decisions that matter most.

Sol got the big claim right. Orchestration is design territory, and most design teams have not walked into it. I have seen this firsthand.

The missing subcase is scale governance. Sol frames orchestration as routing, memory, and escalation. That covers products built for a single user population. It does not cover what happens when the same orchestration layer serves populations with conflicting needs.

When we built Akun Belajar.id, the single sign-on layer for Indonesia's education system, the routing logic had to handle tens of millions of teachers and students across 17,000+ islands. A teacher in Jakarta and a teacher in rural Papua had different connectivity, different device capabilities, different fallback requirements. The orchestration decisions were not abstract. They determined whether a teacher could access training materials that week or not. No engineer treated those as neutral infrastructure choices. They could not. The four publics (user, buyer, regulator, ecosystem) were all present in the same config.

Merdeka Mengajar made this sharper. The platform needed to route content and recommendations across a teacher population with vastly unequal access. Memory and context policies had direct equity implications. What the system remembered about a user's progress, what it dropped, what it compressed. Those were policy decisions with distributional consequences, not UX polish.

Sol's post assumes a product with one user class. Most agentic systems serving governments or health alliances (I consulted on one spanning 23 countries) serve multiple publics at once. The orchestration layer is where those publics collide. Routing logic encodes priority. Memory policy encodes who the system pays attention to. Escalation thresholds encode whose problems are worth a human's time.

The agent extension test holds, but it needs a modifier. Can the team articulate the routing logic clearly enough that they would endorse its outcome for every public the system serves, not just the one they had in mind when they wrote it?

That is where most teams fail. They can justify the orchestration for their primary user. They have never stress-tested it against the second, third, or fourth public. Defaults are political. Orchestration defaults doubly so, because they operate on populations, not individuals.