Why VAO

Vertical SaaS

Vertical SaaS platforms are built for industry specific workflows — how one industry actually gets things done, sequencing and exceptions included. Their edge is a deep understanding of industry rules and workflows that took years to build, but AI is requiring a redesign of the Vertical SaaS model.

Four pressures, at once

  • The screen. Agents want the data, not the interface — and the SaaS roadmap is painfully adding onto a UI that an NLP interface could serve directly.
  • The use cases. Features product teams once ignored, or that needed custom workflows, are now within reach of AI plus automation.
  • The delivery model. Software can ship faster but LLM vendors and SIs are prototyping similar features for enterprise buyers.
  • Build vs. buy. Buyers are testing hosted and sovereign AI, and rethinking build vs. buy to avoid lock-in.
Vertical SaaS under pressureA hub labelled Vertical SaaS, under pressure, with four spokes: The screen, The use cases, The delivery model, Build vs. buy.VERTICALSAASUNDER PRESSUREThe screenThe use casesThe delivery modelBuild vs. buy

Fig. 01 — Four independent pressures converging on the incumbent at once.

What it is

Not an architecture. A go-to-market, a product, a customer-success model, a governance model, and an ecosystem play.

Solving the four pressures above takes more than a chat window and an MCP server bolted onto your data.

Turning on MCP makes your data reachable by somebody else’s agent. That’s useful — but what an outside agent can actually do with read access is limited: look something up, summarise it, compare it, run a what-if, write up what it found. Detect, suggest, simulate. Real value, and also the ceiling.

DetectSuggestSimulate
reading data
EscalateCommitEnforceVerify
changing things

Becoming the system your customers actually run the business on means going further — pulling the right playbook for the situation, deciding what to do, doing it, and checking that it worked.

00 · Qualification gate

Run before pillar 01. VAO isn’t the right fit for every SaaS company, or for every use case inside one that qualifies. Rule out three things first:

  • Horizontal SaaS. This is built around industry-specific workflows, not general-purpose tools.
  • Use cases where every expert already agrees on the right call. If competent people, given the same inputs, land on the same answer every time, that's a calculation — not a decision an agent needs to make.
  • Use cases where all you actually need is a query and a report. Looking things up and summarising them is real value. It isn't a system of action.

What’s left is the target: a decision that recurs, on data the system already holds, where good judgement can reasonably go more than one way — and where someone needs a system of action not just a system of record.

01

Value proposition and competitive landscape

  • What the buyer wants the product to do: answer, decide, or act
  • Defining limitations and identifying non-covered use cases
  • Understanding where value compounds for Vertical SaaS once models and connectors are commodities
  • Mapping and scoring use cases to either Agentic Orchestration (drawing on the qualitative decisioning of agents) or Optimisation (calculation of a cost-effective solution based on predictions)
  • Defining VAO's coverage across a portfolio of AI agents, models, studio including schedulers and builders
  • Sizing the pricing and value of agentic products and Solution Consulting Methodology: what products are deployed, and what strategies are learned from humans and taught to agents
02

Agentic product and multi-agent architecture

What you ship
  • What the customer opens: the work queue, the studio, the library, the chat
  • What their own agents may read through MCP, and what only your controlled write path may change
  • Fine-tuned open-weight models based on aggregated and anonymised datasets. Released under a licence TBD
What runs underneath
  • The domain graph, and the arithmetic no model is allowed to touch
  • The agent roster, the families of models required and the evaluation framework
  • Fusion gateway: one path to every model (open-weight or closed), so no agent names a provider
03

Customer success and delivery

  • Defining the discovery method to record the situations log (what people handle, how often, and what each costs)
  • Defining structured capture of the domain graph during interview sessions with operators (how experienced people decide, and when each option wins)
  • Mapping required integrations based on the model graph including API/MCP integrations through existing or to-be-built connectors
  • Matching to the delivery topologies (multi-tenant, single-tenant, on-prem, air-gapped)
  • Defining agent roll-out: watch, then recommend, then act unsupervised — one situation type at a time
  • Defining calibration reviews: compare what was predicted with what happened, and move trust on the evidence
04

Governance, sovereignty and IP

  • Defining who owns which asset: the schema, the customer's own graph, and the judgement taught during delivery
  • Building the legal framework to grant VAO the right to generalise insights feeding a shared asset, not a customer-specific model
  • Documenting data flows across all deployment topologies; which customer data may leave the customer's systems, and which never does
  • Specific case of fine-tuned model distribution. Licensing and openness frameworks. Where it runs, whose model weights
  • EU AI Act classification of an agentic system of action. Export control and works-council consultation processes
  • Aligning data aggregation and anonymisation process with Terms of Use
05

Ecosystem and partners

  • System integration: which systems of record must be connected (especially ERPs), and which to wrap rather than build
  • Integrating with the customer's own orchestrator, AEA and with competing knowledge graphs
  • SI mapping into tiers: customer-authorised SIs, vertical specialists, ERP integrators
  • Defining system-integration partner boundaries: they deploy, they never teach
  • Harness engineering and agent infrastructure (observability, open-weight models and compute partners, dataset-building, fine-tuning and evaluation)
  • Open model and agent benchmarking, and independent audit

The same five pillars, instantiated twice

AMO — agentic manufacturing orchestration

The unit of value is the taught situation type in short-term execution. Sovereign deployment and export control are load-bearing.

ATO — agentic treasury orchestration

The unit of value is the policy-constrained cash decision. The moat moves to the write path that enforces the customer's own rules.

Pillar 02 builds the instrument · Pillar 03 holds it