Vertical AI Products Are Connectors Plus Role Contracts
A vertical AI product becomes defensible when it connects to the systems where work lives and accepts a precise role contract. The model is only one replaceable layer.
Product
6 min
The short version: Build vertical AI around four assets: governed connections to systems of record, a narrow role contract, vertical evals, and procurement proof. Connectors let the product reach the work; the contract tells the buyer what it owns, what it refuses, and where a human remains accountable.
The legal-industry research note captured the shape clearly: more than twenty connectors into legal systems, a dozen practice-area packages, and credible design partners inside a regulated market. The lesson for a vertical founder is not to copy the legal bundle. It is to notice that “AI for an industry” becomes believable when the product can enter the industry’s real systems and behave like a bounded role.
Connectors create reach; role contracts create a product
A general model can draft, summarize, and reason about almost any domain. That breadth is not a vertical product. Buyers pay when the system can retrieve the right matter, observe the right event, follow the firm’s policy, create the expected artifact, and hand the result back into the system where the team already works.
Connectors and MCP explain the reach layer: permissions, transports, OAuth, review gates, and custom integrations. Vertical value begins after the connection succeeds. The product must know what a person in a specific role is trying to complete and which boundaries make the output safe enough to use.
Write the role contract before the feature list
I would write a one-page contract for the first role with six fields:
Role: one named operator, such as litigation associate, revenue operations analyst, or deliverability specialist.
Inputs: the authorized systems, records, policies, and triggers the product may read.
Outputs: the exact artifact or system change it produces, with format and destination.
Decisions: what it may decide, what needs approval, and what it must never infer.
Service level: expected latency, freshness, coverage, and escalation time.
Accountability: the human owner, audit trail, retention policy, and reversal path.
Consider a legal intake product. “Help lawyers with intake” is a category description. A role contract is sharper: read a new intake form and approved conflict data; extract named parties; draft a matter summary in the firm’s format; flag missing fields; never clear a conflict; wait for an attorney before creating the matter. Product, security, sales, and the buyer can now evaluate the same promise.
Reusable procedures become the implementation units behind that promise. Skills You Should Steal shows both the value and the fragility of packaged instructions. A vertical product should maintain its procedures as versioned contracts with inputs, refusal cases, tests, and owners—not as an invisible prompt collection.
The system-of-record map is part of positioning
List every system the role touches during a normal week. Mark each as read, write, approve, or evidence-only. Then decide which single connection makes the first outcome possible. A product with fifteen shallow connectors and no completed workflow is less vertical than a product with three deep connections and a reliable handoff.
This map also exposes who controls distribution. The system that holds the trigger can introduce the product at the moment of need. The system that receives the final artifact can make the product part of the record. Owning both sides of that handoff is more defensible than adding another chat surface.
The broader chapter on the seams between tools applies here. Models will improve and prices will move. The vertical advantage lives in knowing how the matter, account, claim, shipment, or campaign moves through those seams under real policy.
Vertical evals should look like Monday morning
Generic model benchmarks cannot tell a buyer whether the product performs the role. Build an eval set from real workflow cases, including the boring majority and the expensive edge cases. A useful first set might contain forty cases: twenty-five normal, ten incomplete or ambiguous, and five that must trigger refusal or escalation.
Score at least four dimensions: artifact correctness, policy compliance, evidence traceability, and escalation quality. If the product writes back to a system of record, add reversal success. Set launch gates per risk. For example, require 95% correct field extraction, 100% escalation on the five forbidden cases, and zero unlogged writes before a pilot can expand. The percentages are product commitments on a defined set, not claims that the model is universally accurate.
Refresh the set when a customer overrides the system for a reason the current cases do not cover. That turns service judgment and pilot exceptions into product capital rather than support debris—a direct continuation of the workflow-to-product roadmap.
Procurement proof is a product surface
Regulated and enterprise buyers need more than a polished demo. Assemble a live proof room containing the data-flow diagram, connector scopes, role contract, subprocessors, retention rules, audit-log sample, eval method, latest scorecard, incident process, and a named owner for exceptions. If the workflow changes a record, show the approval and rollback path with a real test case.
A concrete operating rule: no enterprise pilot starts until security, the business owner, and the product owner can all point to the same boundary diagram. If one team believes the product only drafts while another believes it can write, the pilot is already carrying hidden risk.
A 90-day build order
Days 1–15: choose one role and observe ten real instances of the job. Write the contract and the system map.
Days 16–35: connect the minimum systems required for one finished artifact. Keep writes behind approval.
Days 36–55: build the forty-case eval set and record baseline failure modes before polishing the demo.
Days 56–75: run a design-partner pilot, log every override, and update the contract when reality disagrees.
Days 76–90: publish the procurement proof room and sell the scored workflow, not access to a general model.
The AI Operator direction becomes concrete at this level: not an assistant for everybody, but an owned lane with permissions, deliverables, tests, and escalation. For agencies productizing expertise, the Agency to SaaS hub supplies the adjacent operating context. Connectors make the workflow possible. The role contract makes it purchasable, testable, and hard to replace with a generic chat window.
