Last year I wrote a post explaining why vertical SaaS companies could win against the core foundation model providers. A few months later, that argument feels quaint. Anthropic has shipped Opus 4.5 and Claude Cowork with enterprise plugins for finance, engineering, and HR. OpenAI launched Codex. The foundation model providers are not just building models anymore — they are building products…and products that build products.

Arguing against them increasingly feels like shouting from the castle ramparts while the barbarian hordes storm the walls.

And yet. The argument that the foundation model providers will not win everywhere still holds for me. Focus and specialization still matter and are dispositive.

But that is no longer the right question.

The new central question is whether vertical AI vendors can win against the rest of the world armed with powerful, general-purpose agents. You can outrun three to five giants, but can you do the same against an army of weaponized customers and developers?

Nicolas Bustamante, the founder of Fintool and co-founder of Doctrine, recently made the case that LLMs are systematically dismantling the moats that once justified vertical software’s premium multiples. If you do not have proprietary data that cannot be scraped or synthesized, regulatory lock-in, or network effects, then general-purpose reasoning agents will eat your lunch. It’s a great synthesis, and every vertical player should take it to heart.

I agree that the best vertical startups will have those moats. But a lot of enterprise software will be bought from startups that do not fit neatly into that framework, and some will be enduring businesses.

Here is why — and the answer has everything to do with where the barbarians actually are.

The Threat Is Inside the Building

The conversation about AI disrupting software usually imagines the threat coming from outside. But the more immediate and chaotic threat comes from inside the enterprise itself. General-purpose agents are now powerful enough that anyone in an organization can build one. A marketing manager spins up an agent that pulls customer data. A junior analyst automates a reporting workflow without anyone reviewing the logic. Three departments independently build agents that interact with the same CRM, creating conflicts no one anticipated.

For an enterprise, this is both beautiful and frightening. For CISOs, CFOs, and Chief Risk Officers, it’s mostly frightening. They will not sign off on a world where hundreds of ungoverned agents run loose across the organization.

And that is exactly why enterprises will buy software — not just to do the work, but to impose the structure, governance, and coherence that makes AI-powered work safe and reliable at organizational scale. The barbarians are not just at the gates. They are inside the building. And that is the problem enterprise software has always existed to solve.

The Answer: Packaging Complexity

Enterprises do not buy features. They buy solutions — and solutions require design, orchestration, governance, security, and accountability. Capability alone is not a deployable enterprise solution.

#1 Design addresses how humans and agents interact. It is paramount yet uncharted territory. SaaS codified enterprise processes into software. But one of the most profound changes coming with AI is that enterprises will move from buying automation to buying outcomes. Those who argue that workflow is dead are directionally correct, but incomplete. In its place, we will need well-designed agentic workflows that manage the handoffs between agents and humans — and those workflows will be reimagined from scratch around outcomes.

It’s early. Most startups are still wedging in with discrete task automation tackling the jobs to be done. That is smart for now and an easier sale to enterprises, but ultimately not enough. The saying “your mess for less” was common in Business Process Outsourcing (BPO) because BPO firms rarely re-designed and improved enterprise processes. Inserting Agent X for this task and Agent Y for that one, but doing the job the same way, will not create long-term winners.

Instead, AI startups need to begin with an outcome-design mindset. Consider commercial lending. A startup thinking in terms of task replacement would first gather all the borrower data, then have an agent automate the financial spreading and wait for a human to review, and finally have an agent create an underwriting memo and wait for a human to edit. A design built around outcomes will take advantage of the 24×7, scalable agent capabilities and create a real-time, iterative conversation with the borrower. Agents could request data as needed to qualify borrowers, show the borrowers how the lender will model their credit worthiness and match them with loan products, and allow the borrower to change variables like loan rate, points, or term. At any point, the borrower could request to speak with a loan officer, and when they do, the agents would prepare the loan officer with notes, recommendations, best next steps, etc. If this saves the loan officer 10 hours per loan, all of that can be spent on relationship building, cross-selling, and ensuring the customer gets the most value from the lender relationship.

Design will be the most durable form of domain advantage. General-purpose agents will probably, eventually learn every domain. An agent can learn the rules of commercial lending or insurance underwriting. But knowing the domain is not the same as knowing how to redesign the work. Designing the right interaction between agents and humans — where to automate, where to hand off, where to keep a human in the loop not for compliance but because it genuinely produces a better outcome — requires the kind of judgment that only comes from deep, sustained focus on a problem space. That’s not a knowledge gap. It’s a design gap.

Get the agent-human interaction design right, and you will have an early advantage that compounds. Reflecting on the birth of ecommerce, Amazon nailed the checkout flow while countless merchants had obtuse, high-friction checkouts. The underlying capability was the same, but Amazon’s design of the end-to-end experience created an early competitive advantage that compounded. Seems obvious now, but it was not at the time.

#2 Orchestration is about how agents work with each other. Any meaningful enterprise process involves multiple agents — one that extracts data, another that analyzes it, another that drafts a communication, another that checks compliance. Someone must decide the architecture: which agents manage the workflow, when to use specialized agents, and when to invoke a skill versus spinning up a separate agent. Think of it like staffing an investment team — you need a leader who knows when to pull in the tax expert, the industry analyst, or outside counsel, in what order, with what context passed along. Knowing the industry vertical and the function is critical to optimizing specialist agents vs. general-purpose agents, pre-built integrations vs. as-needed API calls, and agents vs. humans. All of this will affect cost, reliability, and speed.

#3 Governance means the policies, approvals, and controls that determine who can deploy an agent, what it is allowed to do, what happens when they are duplicative, how decisions are reviewed, and the imposition of security and data requirements. In financial services, a model that generates investment recommendations may need to be validated, documented, and approved before it goes live. Some payments may be initiated by agents; others require human approval. In healthcare, an agent might read the radiology report, and even provide the results, yet not have authority to order prescriptions.

#4 Security in the enterprise is table stakes. It means data isolation, access controls, audit trails, and compliance with industry-specific regulations like HIPAA, SOX, or GDPR. A general-purpose agent can be powerful, but an enterprise buyer needs to know exactly what data it can access, who can see its outputs, and how to prove that to a regulator. Security may not strongly favor vertical software over foundation model providers in all industries, but it can in industries with industry-specific regulations like healthcare, financial services, and public sector.

#5 Accountability means having a throat to choke. When an agent makes an error that costs money or creates risk, enterprises need a vendor who owns the outcome. They need SLAs, incident response, and a product team that understands the domain well enough to diagnose what went wrong. A general-purpose agent does not come with a customer success team that knows your industry.

The companies that package all this together — the design, orchestration, security, governance, and accountability — are building something that a general-purpose agent with plugins simply does not replicate. Packaging complexity is a real and enduring source of value.

Vertical Software Players Can Succeed, But the Race Is On

This case for packaging complexity IS the defense of software, and especially of vertical software that brings domain knowledge to every decision. However, it’s not yet clear how enterprises will buy and deploy all this needed governance, security, and accountability.

Three categories of players are competing for the enterprise AI stack.

Foundation model providers. Anthropic, OpenAI, Google are solidly individual productivity tools today, but the trajectory makes clear they are moving towards this orchestration layer. Anthropic shipped Cowork in January, added plugins two weeks later, then added enterprise connectors, private plugin marketplaces, and admin controls two weeks after that. And the February launch explicitly featured orchestration across Excel and PowerPoint — context flowing between tools, not just a human chatting with an agent. The pace is extraordinary and moving toward the orchestration layer. What keeps them from being the default orchestration layer – risk of model lock-in for one. But some buyers will accept that.

Purpose-built horizontal orchestration platforms. Stack AI, Thread AI, Copilot Studio posit the enterprise wants a single neutral orchestration layer across all business functions: visual workflow builders, multi-agent coordination, governance dashboards, deployment infrastructure. This looks a lot like how enterprises have bought for decades, and frankly it is hard to imagine not having some layer like this because enterprises need to manage complexity across all their functions.

Vertical software vendors — Harvey in legal, Fazeshift in accounts receivable, Abridge in healthcare — these kinds of players own the domain expertise, workflow design, and customer relationship for a specific function. This is the category that needs to change the most and get the packaging right to survive. The best will absorb security, governance, and orchestration into their own products because their customers will demand it.

Realistically, all three will find buyers in the enterprise along lines of size/scale and technical sophistication. JPMorgan will build a lot more software in-house than it did before because the cost of doing so will fall. They will absolutely have their own horizontal orchestration platform. Small and midsize companies like a community bank or domestic manufacturer will buy a lot of individual vertical software products and need orchestration built in.

These are genuinely open architectural questions. What I believe is that vertical vendors are best positioned to solve the hardest part: designing and packaging the domain-specific work that produces outcomes. Whether they build, buy, or integrate the horizontal infrastructure is a strategic question each will answer differently. But domain expertise comes first, and that is not something a horizontal platform or foundation model can easily replicate.

Conclusion

Making the case for vertical startups may look crazy right now. That’s fine. The foundation model providers are building governance, orchestration, and enterprise packaging at remarkable speed, and the window for startups is not infinite. But the high-probability scenario is that the greatest problem to be solved is the hard, domain-specific work of designing how agents and humans should interact, how agents work with each other, and how all of it operates safely within the constraints of a real enterprise. That work favors the focused over the general. The opportunity is decades long, but the window to establish yourself is right now.

Forward-deployed engineers (FDEs) are having a moment. Whether called “agent engineering” at Sierra, “customer engineering” at Shield, solution and sales engineering elsewhere, or their original name, “Delta”, they sit at the intersection of sales, engineering, and customer success, translating real-world complexity into product insight.

As AI products collide with messy enterprise reality – legacy systems, ambiguous workflows, and proprietary data – companies are rediscovering a Palantir-era tactic: embed engineers directly with customers to make the product actually work.

The appeal is obvious. FDEs compress sales cycles and bridge the gap between elegant demos and operational reality (hence their original name “Delta”), but they are a double-edged sword. At best, they create a tight feedback loop between the customer and product, but if done wrong, they can quietly transform software companies into bespoke service firms with bloated CAC, fragile margins, and roadmaps dictated by their loudest customers.

The question is not whether to build an FDE team, but how to design one without undermining the very economics that make software valuable.

When FDEs Make Sense, And When They Don’t

FDEs are most effective when the product is powerful but the “last mile” is highly contextual. This describes the industry standard in AI and data infrastructure, where value depends on wiring into proprietary workflows and compliance constraints that no roadmap can fully anticipate.

They are also vital in design-partner markets. When early customers effectively co-create the product, FDEs become the fastest feedback loop between reality and code. In competitive markets, the second-best product with strong FDE support often outperforms the technically superior product that customers cannot operationalize.

• The Danger Zone: FDEs become toxic when custom work becomes the default. If every deal requires bespoke engineering, you don’t have a product; you have a consultancy with a logo. When “we’ll just throw an FDE at it” becomes an organizational reflex, product debt accumulates silently. Customers outsource their thinking to your engineers, and you inherit their complexity.
• Rule of Thumb: If more than 30-40% of deployments require significant FDE effort, the problem is no longer go-to-market. It’s product design.

Pricing: Don’t Hide The Cost

The central tension here is economic. FDEs create real cost, but professional services revenue hurts valuation multiples.

• The Services Model: Billing time-and-materials keeps margins clean but dilutes valuation. What’s worse is that customers anchor on hourly rates rather than product value.
• The Bundled Model: Bundle FDE costs into the subscription price. It preserves “software-only” optics and simplifies procurement. It’s the pragmatic choice in early stages. However, it inflates subscription pricing and obscures the true drivers of CAC and gross margin.

The Solution: A milestone-based embedded model. FDE support is included in the deal but tied to defined milestones (e.g., “successful deployment”) rather than open-ended engagement. Embedding must be time-bound — usually three to six months. If customers cannot graduate from FDEs, the product is not ready.

The Metrics Trap: ARR, CAC, And Margins

For companies offering FDEs, financial planning and analysis are usually more troublesome than the actual engineering.

The uncomfortable truth is that FDEs often make metrics look better externally, but worse internally.

• Revenue: Only software counts as ARR. FDE revenue should be internally unbundled, even if external reporting lumps it together.
• CAC vs. COGS: Pre-sales FDE work is CAC. If you don’t track this, you will drastically overestimate your GTM efficiency. Post-sales work is Services COGS.

Finance teams must enforce an honest distinction between software margins and deployment margins. If FDEs are essential to closing every deal, your product is not yet self-serve at the enterprise level, and your P&L should reflect that.

Code Ownership And Org Design

The legal stance must be absolute: The company retains full IP ownership of all FDE work. Customers get a royalty-free license, but reusable components must flow back into the core product, not remain trapped in customer-specific forks.

Where FDEs actually sit is equally consequential:

• Reporting to Engineering: Better code quality, weaker revenue alignment.
• Reporting to Sales: Higher responsiveness, but a high risk of “short-term hacks” that create technical debt.

Best Practice: A dual-reporting model where FDEs sit within a Customer Engineering org but maintain a dotted line to Product. Crucially, rotate FDEs between customer sites and core development. This prevents “maintenance mode” burnout and ensures the FDE team doesn’t drift into a consulting mindset.

Compensation: Incentives Shape Architecture

Forward-deployed engineers embody your product strategy, and your comp plan will dictate their behavior.

• The Sales Model: Paying FDEs commissions on closed deals encourages them to optimize for immediacy. Custom solutions multiply, and the company scales exceptions rather than a platform.
• The Core Model: Paying high base salaries with no variable component produces clean code but low urgency. Architectural purity takes precedence over customer timelines.

The companies that win must reject both extremes. They pay FDEs at engineering levels (read: equity-heavy) but introduce a restrained variable component tied to outcomes that signal maturity: successful deployment, retention, and the conversion of custom work into core product capabilities.

Three FDE Archetypes In Practice

1. The Activator (e.g., Sierra): In AI platforms, FDEs act as “agent product managers,” translating enterprise complexity into deployable systems. This is powerful but fragile, and must therefore be temporary.
2. The Integrator (e.g., Ramp): In fintech, FDEs bridge the gap between modern software and legacy ERPs, banks, and internal tech stacks. They are the difference between a mid-market deal and a multi-million-dollar enterprise contract, provided they don’t let big customers hijack the roadmap.
3. The Infrastructure (e.g., Palantir): When every customer requires embedded engineers forever, product velocity dies. Palantir built a giant business this way, but they operate in a market with extreme switching costs and existential stakes. Most startups do not have that luxury.

The Ideal End State: Scaffolding, Not Architecture

Many startups today use FDEs to compensate for immature products, unclear positioning, weak onboarding, missing integrations, and unrealistic enterprise promises.

In the ideal model, FDEs feed R&D. Each deployment generates insight into data schemas, workflows, edge cases, and constraints. Those insights become reusable features. If three FDEs solve the same problem, the solution becomes a native capability.

The real question is not whether to build an FDE team. It is how long you plan to depend on one.

FDEs are a mirror. They reveal the gap between what your product promises and what customers actually need. The companies that win treat FDEs as scaffolding – never as architecture.

Originally published on Forbes.

A core tenet has emerged that the AI opportunity is much larger than SaaS because it is going after labor spend which is 10-30x larger. At the headline level, this is undeniably true in almost every industry.

However, over the last three years we have started to see how much labor spend AI can actually capture. TLDR: It’s a lot less than the headlines, but still a large expansion from SaaS. I anticipate software spend will increase 2-3x with the addition of agentic workflows.

The answer will vary a lot by industry, but I am using this framework for sizing the AI market opportunity. I will illustrate it with customer support data, one of the earliest adopters of AI in the enterprise.

There are three main drivers.

#1 Fixed vs. variable costs. Call centers will continue to have management teams that hire and manage employees, procure technology, analyze data, and make decisions. Of a total customer support budget, it is typical to see 40% fixed costs, leaving 60% variable human costs doing the actual work of customer support.

% of jobs that AI can handle. This number will steadily rise as AI gets better and enterprises customize agentic workflows to their specific needs; however, it’s not going to be 100% of all customer support interactions for many reasons – one-off or highly complex support needs, enterprise unwillingness to integrate AI agents with high-risk systems like payments or prescription ordering, etc. However, out of the gate, we have seen AI handle 50% of chats and emails (less of voice calls), encouraging enterprises to target 75% deflection of support from live humans. It’s impossible to know where this settles, but 75% is possible, if optimistic. Over a long enough horizon, I will bet on AI’s inexorable improvement.

AI cost vs. humans. It is fascinating to see AI vendors pricing AI agents at 10-20% of their comparable unit of labor replacement. For example, it costs many companies $5-10 per customer support interaction (variable only), but AI vendors like Sierra, Decagon, and Maven often charge ~$1. That is 80-90% variable spend reduction for enterprises…and reduced market size for AI vendors. To be sure, as companies grow, their customer support interactions gr ow, and so will the AI market opportunity, but all things equal, aggressive AI pricing deflates the market size.

In summary, there might be 10-30x more labor spend than SaaS today, but it is probable that only 10-20% of that is accessible to AI. That is better news for people worried about losing jobs to AI, but worse news for investors hoping for a larger market opportunity. In the end, there are many ways AI could capture more labor spend, and even take spend from SaaS, so this framework will evolve. We will all learn together.

Updating our annual report.

We had the opportunity to provide a mid-year update on our State of Robotics report at RoboBusiness 2025.  The buzz at the conference was palpable, as this year is proving to be an incredible year for robotics.  The market is hitting an inflection point with investment on pace to hit record highs, public and private market valuations growing rapidly, exits accelerating, and innovation continuing to offer transformative opportunity.  The future of robotics is more exciting than ever!

We invite you to download the report here, and reach out to authors Sanjay Aggarwal and Betsy Mulé.