What should you weigh when choosing an AI work-automation service? Say you're comparing three candidates. All three run roughly the same cutting-edge model, and when you run a demo, the output looks about the same. So what are you actually supposed to look at?
The vendors don't answer this well either. Plenty of agentic services still lead with "we use the latest model." A few years ago that was a differentiator. Not anymore. This piece makes a single claim: in a market where the models have converged, what decides the contest isn't model performance — it's the context that accumulates while that model handles your work.
First, one term. Agentic SaaS refers to software you subscribe to monthly without installing (SaaS, software as a service) that takes a goal a person hands it and works through multiple steps on its own to get it done. It reads your email, books your schedule, drafts your documents, and figures out what to do next.
Most of the quality in what an agent does comes from the capability of the large language model underneath it — the AI that understands human speech and generates text. The problem is that nearly everyone can now use that model. You just call the top-tier models a handful of companies have built — the most advanced performance available at any given moment, which is why they're commonly called frontier models — through an API (the connection point a program uses to call an external capability). Prices keep dropping, and the gap between the first- and second-place models has narrowed. For most work, both do the job just fine.
In other words, the raw material has become common. You can't dig a moat with common materials. A moat was originally the water channel dug around a castle to keep attackers from crossing; in business it refers to a structural barrier that keeps competitors from easily catching up. Simply calling the same model everyone else calls won't raise that barrier. If I switch to a better model today, my competitor switches to the same one tomorrow.
So the contest moves down from the model itself to what gets left behind and piles up while that model works.
The key word is context. Context means all the background knowledge needed to handle that particular customer's work. Who works with which vendors, why last month's delivery slipped, the tone this customer wants their reports in, what you learned to watch out for after one painful mistake.
None of this lives inside the model. The model knows the world in general; it doesn't know your company's last six months. It only comes into being as the service works alongside you and gathers it, piece by piece. And once it starts to accumulate, a virtuous cycle kicks in. The more context there is, the more accurate the judgment; the more accurate the judgment, the more work you hand over; the more you hand over, the more context piles up again.
When data gathers in one place, it develops gravity. The work that uses that data gets pulled toward it, and the work pulled in produces more data in turn. A small clump of context that started tiny grows its own mass this way, forming a field of attraction that no one can easily pry loose.
Here's the decisive difference. The vendor doesn't control model performance. When the model company raises the bar, competitors rise right along with it. But accumulated context grew out of the customer and the service working together. It's not something a competitor can buy and slot in overnight just by spending more. This is where a real barrier and a fake one part ways.
Picture a small furniture workshop. The owner handles sales alone and farms work out to two or three outside woodworkers. One day a big client calls: "Can you move this order's delivery up by ten days?"
Feed that request to a generic automation tool with no context, and you get a polite draft reply. The sentences are smooth. But that's as far as it goes. Whether moving it up by ten days is even possible is something the owner has to work out in their own head. Which woodworker has capacity right now, whether this client has cried urgent before and then paid late, whether pulling the delivery forward pushes other orders back. The tool knows none of it. In the end the owner does all of it. The tool just took dictation.
An AI project manager with accumulated context moves differently. If it has worked with this shop for months, it knows that single line of a request has several things riding on it. There's a record that this client made similar requests twice last quarter and paid later than average. It knows from recent scheduling that woodworker A is slammed with another job while B has room this week. So it doesn't just toss over a draft. It adds judgment on top: "This client tends to pay late, so how about attaching a deposit-up-front condition," or "Handing this to B looks like it can make the ten-day cut, though another order next week slips by two days."
The model in both cases may be identical. The gap came from the several months of context that piled up in between.
Let's go one layer deeper. What this shop has accumulated comes in two kinds. One is raw data — the client list, past order history, the record that payments ran several days late. Easy to pull into a table and hand to another service. The other is the way of judging that got carved out on top of it. Conclusions like "it's better to require a deposit from this client" or "route urgent requests like this to B" are things the service refined by living through what went wrong and what worked across countless cases. These judgment rules can also be exported if you write them down as documents or memory. In fact, services like Claude offer the ability to export accumulated memory and bring it into a different environment (official guide). That said, moving the rules doesn't mean the performance comes with them intact. For a new service to reliably arrive at the same judgments, it usually needs a fair amount of fresh adaptation and trial and error all over again.
That's where switching costs come in. A switching cost is the price you pay to move to another service. Not just money — the time and hassle of teaching everything from scratch, and the risk of quality dropping in the meantime, all count as cost. The moment the shop switches, it can export both the raw data and the judgment rules, but it still takes time to break the new service in before it works as smoothly as the old one. Once the owner has been through that once, they won't switch unless they really have to.
This yields a trick for competitive analysis. To gauge the strength of a service, ask less "how smart is it" and more "what do you lose when you leave?" If leaving costs you nothing, there's no moat. That's the service with nothing but a good model. Conversely, a service where leaving means rebuilding months of adaptation from zero won't be stolen easily, even if its model is ordinary.
One caveat: on day one of signup, the switching cost is zero. Nothing has accumulated yet. This moat is made by time. Put another way, the design that holds a customer early on — long enough for context to start piling up — sets the size of the moat six months later.
So do you win just by piling up as much context as possible? It's not that simple. There are three traps.
First, switching costs bind customers, but taken too far they imprison them. The moment someone trying to leave feels they can't take their own data out, that's not a moat — it's a shackle. A service that clamps a shackle on pays for it in reputation. The moat that lasts comes not from "making it impossible to leave" but from "they could leave and don't." Whether it's raw data or judgment rules, the side that keeps export open at all times wins over the long run.
Second, context is only an asset while it's fresh. If a client's situation six months ago differs from today, stale context actually invites the wrong call. The design for discarding and refreshing matters as much as the design for accumulating. Trust a service that explains how it keeps context current over one that brags about how much it has piled up.
Third, the deeper the context, the greater the responsibility. Knowing a company's payment history, vendor relationships, and internal situation means holding that much sensitive material. A service that's hazy about how it protects this, how far it uses it, and who it keeps it from — its risk deepens right alongside the context. Deep context and the trust to handle that context have to move as one body.
To sum up, where you should look when sizing up a competitor changes. The smoothness of the demo screen is performance at zero context, and that's about the same for everyone anyway. The question narrows to one: how is this service turning the customer's context into an asset?
Attempts to dig this context moat show up differently depending on the shape of the service. Some services gather a customer's scattered pile of documents into one place and turn it into searchable memory; others wedge themselves into the workflow itself and bank the reasoning behind decisions.
The shape ONTLE chose is the dispatched-worker model. Rather than putting a person in someone's place, it stands beside small businesses and solo founders who can't easily hire more people, shouldering the repetitive judgment work they face every day to lighten their load. Think back to the furniture workshop: the context a dispatched model accumulates is this — which client pays late, which outside woodworker urgent orders have been routed to, under what conditions the owner has turned work down. To lighten the load you have to know that company's situation, and to know it you have to live through it alongside them and let it pile up. What piles up that way becomes a position that can't be easily pried loose.
The market's next stage splits here too. Right now we're in a phase where services advertise themselves by "which model do you use," but once models fully level out, that line loses its force. The question that remains comes down to one: the service that has worked with you for six months — did it turn those six months into your asset, or just let them drain away as logs? Shifting the center of gravity in competitive analysis from the model to the context — that's the most practical angle for reading this market.
Even if the sheer volume of work is low, there's a definite grain to the repetition. Things like a client's tendencies, a preferred reporting style, the points where things went wrong in the past accumulate regardless of scale. If anything, smaller companies have more tacit judgment living only in one owner's head, so when that starts piling up out in the open, the felt effect is even bigger. What matters isn't the amount but whether that context actually feeds into the next decision.
With a healthy service, you should be able to. When choosing a service, I'd recommend confirming "can I export my data" before you sign. The side that keeps export open and aboveboard is, paradoxically, more trustworthy and gets chosen for longer.
The opposite. The better the model, the higher the value of context. It's the same as how the better you explain your company's situation to a smart person, the better their judgment gets. A better model doesn't remove the need to know your company's situation. If anything, among competitors using the same model, the context gap shows up even more sharply.
What gets leveled by open source is the model and the tooling. Those were never the moat to begin with. Context built with a specific customer isn't the kind of thing that can be released as open source. The more free tools there are, the more the differentiator tilts toward what you've built with those tools.