Elementum AI

One Human, Four Systems

Nader Mikhail
One Human, Four Systems

Here's a question almost no one asks when buying enterprise software.

Why do you run four different systems for the same person?

Your sales rep has IT problems. They also have HR problems. They also have procurement problems. They also, occasionally, sell something. You bought four different systems for those four different problem domains. You pay four different vendors. You manage four different data schemas. You configure four different sets of approval flows.

The sales rep is one human.

Why It's Built This Way

The four-system architecture is a relic. ServiceNow won IT. Workday won HR. Coupa or Ariba won procurement. Salesforce won sales. They each built a workflow engine for their domain, wrapped it in a domain-specific UI, and convinced you the four problems required four products.

That made sense in 2010. None of these companies could orchestrate across each other. Cross-functional workflow was a custom integration project. So they each owned a vertical slice and charged you for it.

The slices have hardened into silos. Your IT team doesn't talk to your HR team. Your procurement team doesn't talk to anyone. Your sales ops team is rebuilding the same approvals logic for the third time. Every cross-functional workflow becomes a project. Every employee request hits a different system.

What you don't see on the org chart: each of those four systems has its own outsourced operations team running underneath it. Four licenses. Four BPO contracts. Four sets of people doing the same kind of repetitive work the AI on top is supposed to make obsolete.

This isn't an architecture. It's a tax on every internal function you run.

The Employee Doesn't Care About Your Org Chart

When your sales rep needs a new laptop, a budget approval, and a vacation day in the same week, they don't think about which system owns each request. They want to ask one place and get it done.

That's what every CIO building a corporate GPT is converging on. One front door. Employees ask. The system figures out where the request goes, runs the workflow, returns the answer.

The four systems behind the scenes? They're not features anymore. They're friction.

What One Front Door Actually Does

A front door agent — call it concierge, call it whatever you want — sits behind your corporate GPT and routes employee requests across the four domains. The employee doesn't know which system handled what. They don't need to.

Here's what changes operationally.

Employee requests stop being categorized by system. They get categorized by intent. Workflows stop being domain-specific. They run across domains in one orchestrated path. Data stops being siloed in four schemas. It lives in one data cloud, queried by the orchestrator. The four vendors stop being four vendors. They become — at best — four data sources your orchestration layer can replace one at a time.

The 30/70 Split

Most of these workflows aren't even agentic. About 30% of them require real judgment — interpreting ambiguous requests, reasoning over unstructured policy documents, handling edge cases. The other 70% are deterministic. The same approval chain runs the same way every time. Audit needs it that way. Compliance needs it that way.

Modern orchestration runs both. Agents where you need reasoning. Rules where you need reliability. Humans where the work is genuinely ambiguous and high-stakes.

Three first-class citizens: humans, agents, rules. Same workflow. Different actors at different steps.

The legacy SaaS bundle was never built for that. Workday's workflow engine wasn't designed to run agents. ServiceNow's wasn't designed to run deterministic rules across HR data. The four-system architecture forces you to pick one workflow engine per domain — even when the actual work crosses all four.

What Replaces the Four

One orchestration layer, sitting on your data cloud, running across IT, HR, procurement, and sales. One front door for employees. One pricing model that doesn't charge you per seat for four UIs your employees barely use anymore. And — once the orchestrator is doing the routing, the processing, and the exception handling — one radically smaller human-in-the-loop function instead of four parallel BPO operations.

The four systems don't all disappear at once. Some shrink to read-only data sources while the orchestration layer takes over the workflows. Some get turned off when the migration is complete. The four BPO contracts shrink alongside them.

Either way, the four-vendor architecture is no longer the answer. Neither are the four operations contracts holding it up.

The question to ask the next time a SaaS vendor pitches you: does their product assume your other three systems will still be there in five years? And does it assume your four operations contracts will still be running alongside them?

If the answer is yes, you're buying a bundle that's already breaking.

Nader Mikhail is the CEO and co-founder of Elementum, the open orchestration platform.