Four nouns. One primitive. The SaaS market fragmented work-tracking into incompatible boxes — and the cost of that fragmentation is now load-bearing because agents reason about state, not the noun on the label.
Every team that does knowledge work tracks the same thing: a unit of work, with a state, an owner, a history, and a place. The dev team calls them issues. The support team calls them cases. The ops team calls them tasks. Compliance calls them findings. Sales calls them opportunities. Finance calls them invoices. Each system of record handles the same primitive — and ships it under a different noun, in a different box, with a different audit trail.
This post is about what happens when you notice that, and what the cost has been of pretending it isn’t true.
Pick any work-tracking tool a team uses, and look past the marketing. What’s actually inside?
A row. With a status. An assignee. A description. A bunch of comments stacked on top. A few attachments. A link to other rows. A history of who changed what when. A place to live — a project, a queue, a board, a sprint, a list.
Call it an issue and it becomes Jira’s brand. Call it a case and it becomes Zendesk’s brand. Call it a task and it becomes Asana’s brand. Call it a ticket and it becomes everyone’s brand at once because the noun pre-dated the category.
Under the labels, the same five fields. The same state machine. The same lifecycle. The same audit trail.
The SaaS category didn’t grow that way because the underlying primitives were genuinely different. It grew that way because vertical specialisation was the easier go-to-market. You can sell a CTO an “issue tracker for engineering” without having to also explain why the same tool would serve customer support. You can sell a CX leader a “helpdesk platform” without having to argue it’s actually a workflow engine wearing a customer-shaped hat. So everyone did. And the market accepted four brands for one primitive, the way water accepts four labels for itself depending on whether you’re drinking it, watering plants with it, washing dishes in it, or flushing.
This wouldn’t matter if the work also fragmented neatly along the same lines. It doesn’t.
A customer reports a problem to support. Support opens a case. The case turns out to be a real bug, so support pings engineering. Engineering opens an issue. The issue is scoped to a sprint and becomes part of a release. The release ships. Support is told via a Slack thread, opens the original case, drafts a reply, closes it, and updates the CRM record so the renewal team knows the friction was resolved before the next quarterly check-in.
Count the systems of record that just touched the same unit of work: helpdesk, issue tracker, sprint planner, CRM. Four boxes. Four audit trails. Four IDs for the same underlying thing. Four places someone might go looking for the truth about what happened — and four places where the truth is partial.
For human teams, this is mostly endured. People learn which box owns which step. The handoffs become rituals. The integrations get bolted on. Zapier sells a connector. Someone writes a runbook. The bug-to-case-to-issue-to-CRM flow takes 20 minutes of human attention every time it happens, and most of that attention is just translation — copying a description from one tool’s text field into another’s, mapping one tool’s status to another’s, copy-pasting a customer ID across the gap.
The translation tax is high. The bigger cost is the fragmentation of context. Nobody, after the fact, can answer the question what really happened with this customer’s bug? without piecing together a story across four interfaces. The audit trail is real in each tool and fictional in the aggregate. Six months later, when someone asks why a regression slipped through, the answer has to be reconstructed from screenshots and Slack search.
That’s been the status quo for fifteen years. It’s worked because humans tolerate it, and because the cost of building the unified alternative was higher than the cost of stitching the federation together.
Both of those assumptions are now wrong.
Humans tolerate fragmentation because they learn the routing through experience. The intern who’s been there six months knows that bugs reported by Enterprise customers go in Zendesk first, get triaged into Jira if they’re real, and only loop back when there’s a fix to communicate. The senior eng knows that the “deadlines” field in the project tool is decorative and the real deadline lives in the customer’s Slack DM. None of this is written down. All of it is learned. All of it is paid for in onboarding time and tribal-knowledge dependency.
Agents don’t have tribal knowledge. They have whatever you give them through their tool surface.
So when an agent is asked to do something operational — summarise the open work this customer has across all our tools — it has to navigate the fragmentation explicitly. It needs to query four different APIs with four different vocabularies. It needs to join the results across four different ID spaces. It needs to learn that the “status” enum in tool A maps to a different set of values than the “state” enum in tool B. It needs to know which tool is canonical when they disagree. It needs to know which fields are real data and which are decorative.
You can do this. We’ve done it. It’s the integration tax for agents, and it’s enormous — not because any single step is hard, but because the integration layer becomes the actual workflow. Every prompt that touches operational data is fighting four data models before it can start reasoning about the work. The agent spends more tokens normalising state than answering questions.
The version of this problem that humans solved with onboarding and tribal knowledge, agents have to solve with prompt engineering and brittle joining logic. That logic is the same logic, over and over, in every team that tries to wire agents into their existing stack. It’s not load-bearing work. It’s translation work. The category called this an integration problem and built an industry around solving it (Zapier, Workato, Tray, dozens more). Agents make the integration tax visible by paying it on every interaction instead of once at config time.
And the integration tax doesn’t compose. Adding a fifth tool to the federation doesn’t add 25% more work — it adds another set of pairwise translations against all four existing tools. The graph grows quadratically. Every new tool is another set of “how does its ‘priority’ map to ours” decisions that nobody actually owns.
The federation cost was livable when humans were paying it once. It is not livable when agents are paying it every time they touch the surface.
Here’s the unintuitive part: the primitive that all of these tools converged on is small. Smaller than any single tool’s marketing implies.
A unit of work has:
That’s it. Seven fields. Every “ticket / case / task / issue” tool on the market exposes some superset of those seven fields under different names, with different defaults, behind different UIs.
What changes between tools is not the primitive. It’s the configuration around the primitive — the state machine the team uses, the SLAs that apply, the fields they care about beyond the core seven, the rules that fire on state transitions, the views and queries that surface the right rows to the right people.
That configuration is what specialises the tool to a use case. Engineering configures a sprint cycle, a priority field, a “blocked” state, a dependency graph. Support configures an SLA, a customer-facing channel, a sentiment field, an auto-routing rule. Compliance configures an evidence field, a sign-off step, a retention policy. None of these change what the primitive is. They change what’s wrapped around it.
A horizontal workflow engine ships the primitive once and lets each team configure on top. The vocabulary specialises through configuration, not through forking the primitive into a separate product.
When we designed Ekso, we made the choice to ship the primitive once. There is one shape for a unit of work — the data model calls it an item, lives in a container, has the seven fields above, and is acted on by the same set of MCP tools whether it represents an engineering issue, a support case, a compliance finding, or a sales opportunity.
The team configures from there. A support team adds an SLA constraint and a customer-facing channel; engineering adds a sprint cycle and an estimate field; compliance adds an evidence template. The configuration changes the vocabulary, the workflow, and the agent’s available actions. It does not change the engine underneath. That means the rule MCP tool, the finance MCP tool, the time MCP tool, and every other piece of the surface area work the same way for support cases as they do for engineering issues. One model. One MCP surface. One audit trail.
The bet underneath is: in a world where agents have to read, reason, and act across your operational surface every day, the cost of running multiple incompatible primitives is much higher than the benefit of brand-specialised tools for each function. Specialisation in vocabulary — what to call things, what fields to surface, what state machine to enforce — is cheap to configure on top of one engine. Specialisation in the engine itself, scattered across four vendors, four data models, four audit trails, is exactly the integration tax agents pay forever.
The most common pushback to a horizontal architecture is that specialisation matters. Engineering workflow is different from support workflow is different from compliance workflow. A tool that tries to be all of them ends up being good at none of them.
That argument was right for the human-driven era. It is no longer right.
It assumed three things that no longer hold. First, that the UI was the product — so an interface optimised for engineers and a different interface optimised for support agents needed to live in different products. Second, that the workflows themselves were rigid enough that “engineering workflow” was a stable thing you could specialise a product around. Third, that the integration tax between the specialists was a one-time cost paid by humans at handoff, not a per-interaction cost paid by software on every operation.
All three assumptions are now historical. The UI is increasingly a thin convenience layer on top of an MCP surface — the agent talks to the data, the human approves the result. The workflows are increasingly composed dynamically by agents that need consistent primitives to reason about. And the integration tax has gone from “humans pay it twice a day” to “the agent pays it on every interaction, in every prompt, in every workflow it runs.”
When the integration tax was bounded, vertical specialisation was a reasonable bet. When it’s unbounded, it isn’t.
Tickets, tasks, cases, and issues are the same thing wearing four jackets. The jackets matter for the humans who sell each one. They do not matter for the work, the audit trail, or the agents reasoning across them.
The next five years of operational software will resolve to one of two architectures. Either a federation of specialists with MCP bolted onto each one — and an industry of glue-tool vendors selling the federation back to you as a “unified experience.” Or a horizontal native built around the actual primitive, where the specialisation is configuration on top of one engine.
The federation choice keeps the noun fragmentation. Agents pay the integration tax forever, in tokens and latency and brittleness. The horizontal choice gives up the easy go-to-market story (“the X tool for Y teams”) in exchange for the agentic dividend — one model, one surface, one audit trail, one place where the truth about the work actually lives.
We bet on the second. That’s the bet underneath every other choice — read-only by default, MCP-native from day one, rules and agents as complements, the headless-first architecture. They’re all downstream of the same observation: the noun is decorative. The engine is the product.
If that’s the right read on where ops software is going, every team running 4+ specialised tools today is going to spend the next five years either paying the federation tax or rebuilding on a unified base. The work isn’t getting more fragmented. The tools that pretend it is are.
This post is the category anchor for everything we publish here — the “why horizontal?” reference for the rest of the writing. The launch post sets up the headless-first architecture this argument depends on; rules are an agent’s best friend covers the rules-vs-agents pairing that runs on top of the engine described here.
One workspace for tasks, tickets, time, and money. Free for unlimited users. Cloud, on-premise, or your own infrastructure.
