For thirty-plus years, enterprise software asked companies to hand over their processes. Order-to-cash, procure-to-pay, plan-to-produce. We bought platforms that encoded "best practice," configured them as far as they would bend, and changed the business to fit the rest.
Agentic AI asks for something different. It does not just run the process. It decides inside it. Which customer request is urgent. Which load to accept. Which exception to escalate. Which supplier to call first.
That is a frontier change, literally. The reliance on technology moves from process to reasoning.
And that should make every executive pause before signing the next platform contract. Because the question is no longer only "does this software fit how we work?" It is "whose judgment is now running my business, and can I change it when I need to?"
My answer, as a builder and an operator, is uncomfortable for a market full of agent platforms: build more of it yourself than you think you should. Not everything. But the parts that decide.
One afternoon
A concrete example first, because this debate has too few of them.
Zen Trucking runs on an agent platform we built entirely in-house. It handles business conversations and system interactions across voice and text: a dispatcher calling in, a driver texting a status update, a broker asking about capacity.
When TypeSafe released Jev in mid-September, a "System One" model that only classifies, routes, decides, and scores 20–200x faster and 40–400x cheaper than small frontier models, I added it to our platform in a single afternoon. That was enough to stand up a multi-stage pipeline in which Jev handles the fast, narrow decisions and the frontier model is called only when the situation genuinely requires it.
The result: faster responses, fewer classification misses, and lower cost. Jev makes its routing decision in about 250 milliseconds, so when a driver or broker opens with small talk, the kind of exchange that needs a quick, light reply, the conversation no longer waits on a large model to work out what is happening. On cost, every 10,000 knowledge-base questions now cost us about $0.76 in Jev calls and save about $4.76 in reply-model tokens: roughly $4 net. Every dollar spent on the router saves about six on the model behind it. It also reduced our use of the frontier model we had originally deployed, which opens further cost reductions.
We could do that in an afternoon for one reason. We owned the seams. Nobody's roadmap stood between us and the change.
It had not always been that way. Our first version was stitched together from off-the-shelf pieces: a workflow tool, a hosted voice-agent service, and a frontier model behind both. Each piece worked on its own. Dialing them in together, across vendors with their own abstractions, latencies, limits, and release cycles, was a nightmare. Every fix in one place moved a problem somewhere else.
A useful thought experiment: what would it take to make the same Jev change today if we were built on a general-purpose agent framework, or had stayed on the vendor stack? At best, a wait for someone else's integration. At worst, a re-platforming.
Architecture doesn't go obsolete. Components do.
The standard objection is: the technology is moving so fast that anything you build will be obsolete next year.
That is true of components. It is not true of good architecture.
Modularity is not a feature you add to an architecture. It is one of its defining characteristics. When you build something meant to last, you make a small number of choices that must carry you for years: where decisions are made, how components talk to each other, where state lives, how you observe and evaluate behavior, where a human steps in. Get those right and models, voice engines and tools become replaceable parts. Get them wrong and you live in one of two failure modes. Either you are in a permanent state of rebuild, or you wake up in the not-too-distant future inside an edifice that is already falling behind.
The winners in this market have not been picked. That is exactly why the architecture has to be yours. It is the only thing that lets you pick again.
The crowded middle
Between the model providers and the enterprise sits a fast-growing layer of agent platforms, orchestrators, copilot builders and "digital worker" suites. There are far too many of them, and many will not survive. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, and estimates that only about 130 of the thousands of vendors claiming agentic capabilities actually offer them. The rest is "agent washing."
Some are valuable. Many are thin: orchestration and a monitoring dashboard wrapped around someone else's model. Their moat is the effort it used to take to build what they sell, and that effort is collapsing. The same AI that powers their product is making it easier every quarter for a competent team to build the equivalent, fitted to its own business.
There is also a bundling problem. Buy an agent platform, and you rarely get just the one piece you need. You get all of them: its memory model, its tool abstraction, its prompt format, its evaluation approach, its idea of what an "agent" is. You end up living with all of it, including the parts that fight your business.
This calls for real discernment in choosing who you work with. A simple test for any vendor in the agent stack:
Could we replace you in a sprint?
If the honest answer is no, you are not buying a component. You are funding someone else's moat, with your operating logic as the collateral.
"Raw" building blocks are dependencies too, until you commoditize them
A fair challenge: even a homegrown platform depends on model APIs, speech engines, telephony and cloud infrastructure. Isn't that just a different set of vendors?
Yes, until your architecture commoditizes them.
The point is not zero dependencies. The point is that your architecture decides how each building block is used, so that no single one is irreplaceable. When model access sits behind your own routing layer, when prompts and policies live in your repository and not a vendor's console, when evaluations run against your own test cases, a model becomes a supplier you can switch, not a platform you are married to. The Jev story is precisely that: a new supplier entered, and we moved part of the work to it in an afternoon.
That also answers the uncomfortable trend at the top of the stack. The frontier model companies are steadily absorbing the layers above them: tool use, memory, orchestration, agent runtimes, enterprise suites. OpenAI's Frontier, launched in February as an end-to-end platform for enterprises to build and manage agents, is the clearest example so far. It is rational. Valuations of their size cannot be earned by selling tokens alone. They require owning more of the customer.
For an enterprise, that is exactly the danger. The more of your agent stack you take from one provider, the more of your reasoning runs on terms you do not set: pricing, model behavior, deprecations, data policies. Use the frontier models. They are extraordinary. But use them as inputs to your architecture, not as your architecture.
From process to reasoning: the ERP lesson, raised a level
I was recently on the front seat of a large enterprise platform implementation that went badly wrong. A mid-size supply chain and logistics service provider set out to modernize its entire operating system. On paper, the match was sound: the platform's demonstrated capabilities lined up with the broad operational needs of the business.
In practice, the business ran on just enough undocumented "hidden factory" work and process intricacy to break it. The consultants missed it. Management could not see it. And each of those details sat on a critical link in the core chain of events. Testing never captured those conditions, because nobody knew to write them. Early noise from users was dismissed too quickly. When everything went to production, the system halted.
It was brutal to watch, and it was not unusual.
The pattern is familiar. The platform is designed for something slightly different from how the business actually runs. The executive sponsor doesn't fully understand the gap. The software vendor doesn't either. And everyone marches forward together into the abyss.
That is not incompetence. It is structural. Major platforms have to fit as many customers as possible, so they push hard to reduce variation. As we wrote in Who Cleans Up?, "an enterprise system, by its nature, imposes its own logic on a company's strategy, organization, and culture."
Now raise that a level. With ERP, the imposed logic was a process. You could see it, map it and work around it. With agentic systems, the imposed logic is judgment: how ambiguity is resolved, what counts as urgent, when to escalate, what the customer is told. It is far harder to see, and it drifts when the vendor changes a model underneath you. And a reasoning system that misses a hidden-factory condition may not halt the way that platform did. It may keep running, and quietly decide wrong.
And unlike ERP, the failures are harder to see on the books. We have yet to find a company that has disclosed a charge for a failed AI program. AI spend runs through operating expense. A misfit agent platform does not show up as a write-off. It shows up as slightly worse decisions, every day, at scale.
Two questions every executive should be able to answer before adopting an agentic platform:
1. Is it well-designed and configurable enough to support how my business actually runs, not how the average customer runs?
2. Can it encode the conditions and judgments that differentiate how I run my business, and can I change them myself when the market moves?
If the second answer is "only through the vendor," the differentiation belongs to the vendor.
Own, rent, refuse
None of this is an argument to build everything. It is an argument to build what the architecture needs to last without unmanageable risk.
Own the parts that decide and the parts that tell you whether the decisions are good:
· Decision logic, policies and escalation rules
· Orchestration and routing, the seams between components
· Your context and data layer
· Evaluations and test sets built from your own cases
· Observability: logs, traces, costs, error rates
Rent, and from more than one source, the parts that are commodities:
· Models, both frontier and specialized
· Speech-to-text, text-to-speech, telephony
· Cloud infrastructure
Refuse layers that wrap a model, hold your logic in their proprietary format, and add little beyond a dashboard.
The cost of owning it
Building has real costs, and they should be stated plainly. Someone has to maintain the platform, run evaluations, handle security and compliance, respond when something breaks at 2 a.m., and keep up as models change. There is key-person risk: a homegrown platform understood by two engineers is its own kind of lock-in.
But those costs are largely a consequence of architectural and component choices, not a fixed tax on building. A modular platform with clean seams, documented policies and automated evaluations is cheaper to own and easier to hand over than a sprawling one.
And the comparison is rarely "build versus free." It is the cost of owning what makes you stand out, versus the cost of renting it, on someone else's terms, from a vendor who may change it, reprice it, or disappear. Right now I would much rather know what I am running and control the pieces than wake up one day to a core platform that behaves differently, or breaks, because a vendor changed a component or went out of business.
Leaders have to become architects
This is the harder part of the argument, and the most important.
If reasoning is moving into software, then the people accountable for the business have to understand the software that reasons. Not every line of code. But enough to make the few architectural decisions that will carry the company for years, and enough to recognize when a vendor, a consultant or an internal team is leading them somewhere they should not go.
As we argued in The Most Important Role in AI Development May Not Be the AI Engineer, "AI does not eliminate the need for architecture. It makes architecture more important." The question is rarely "which model should do this?" It is "what is the most efficient and reliable architecture for each kind of decision?"
For executives, that means three things:
1. Learn enough to own the architecture decisions. Where does AI belong and where should deterministic logic stay? What gets delegated to a model, what can it touch, and how will we know when it is wrong?
2. Surround yourself with AI-native business architects, people who move fluently between the business, system design, and implementation, and give them real authority.
3. Choose partners who transfer capability, not dependency. A consultant who leaves you unable to change your own system is just another vendor lock-in with better slides.
The bottom line
Agentic AI is the most consequential shift in enterprise technology since the ERP era, and it asks for something more intimate than our processes. It asks for our judgment.
Use the best models available. Rent the commodities. Be ruthless with the middlemen.
But don't outsource your reasoning.
Zenteck helps leadership teams design and build agentic systems they own: modular architectures, in-house decision logic, and the capability to keep evolving them.
Sources: Latent Space on Jev · Gartner, June 2025 · TechCrunch on OpenAI Frontier