A Domain Prompt Is Not a Vertical AI Product

Adding “You are an expert in this industry” to a system prompt can improve an AI demo. A real vertical AI product requires domain data, tools, workflows, evaluation, permissions, compliance, and a clear operating model around the model.

There is a very tempting way to build a vertical AI product.

Take a strong general-purpose model. Add a system prompt that says something like, “You are an expert HR advisor,” “You are an experienced financial analyst,” or “You are a world-class teacher.” Add a polished interface, a few example prompts, perhaps a retrieval layer containing some industry documents, and suddenly the product appears specialized.

For a prototype, this can work surprisingly well. Modern frontier models already know a great deal about most professional domains, and a carefully written prompt can make their output feel much more targeted. The result may look convincing enough that a team starts describing it as “AI for healthcare,” “AI for payroll,” “AI for lawyers,” or “AI for education.”

I think that is where many vertical AI products begin.

It is also where many of them stop.

A domain prompt can change how a model speaks and what knowledge it emphasizes. It does not automatically give the system access to authoritative domain information, allow it to perform real work, encode organizational policies, understand the workflow around a decision, enforce permissions, satisfy regulatory requirements, or prove that the output is reliable enough for production.

Those capabilities require a much larger product.

A real vertical AI product is not simply a general model that knows the vocabulary of an industry.

It is a system that knows how work in that industry actually gets done.

Domain language is not domain infrastructure

The difference becomes obvious when we compare two requests.

Imagine asking a general model:

“Act as an experienced financial analyst and prepare an investment analysis for this company.”

The model may produce an impressive response. It can discuss revenue growth, margins, valuation, competitive positioning, and risk. If supplied with a few financial statements, it may perform reasonable analysis and generate something that resembles professional research.

Now compare that with an analyst working inside a financial institution.

The analyst may rely on licensed market data, internal research, approved valuation methodologies, comparable-company databases, historical models, compliance constraints, CRM information, company filings, management transcripts, review standards, and a specific Excel workbook used by the organization. Their final output may need to flow into PowerPoint, pass internal review, retain citations to source material, and comply with rules about which information may be used for particular clients.

The vocabulary of the two workflows may look similar.

The operating environment is completely different.

Anthropic's current financial-services product illustrates this distinction well. Its finance agents are not simply Claude with a financial persona. The reference architectures combine domain skills, governed connectors to data providers, sub-agents for specialized tasks, firm-specific methodologies, approval flows, and integrations with tools such as Excel, PowerPoint, Word, and Outlook. Claude can connect to sources including FactSet, S&P Capital IQ, MSCI, PitchBook, Morningstar, LSEG, internal data warehouses, research repositories, and CRMs.

That is what verticalization increasingly looks like.

The model supplies reasoning.

The product supplies the domain operating environment.

Trusted data changes the quality of the product

One of the first differences between a vertical AI demo and a production product is the source of truth.

General-purpose models contain substantial domain knowledge, but professional workflows often depend on information that is proprietary, time-sensitive, institution-specific, or regulated. A financial analyst needs current filings and market data. A payroll agent needs the employer's actual policies, employee records, jurisdiction, payroll configuration, and historical transactions. A teacher may need the school's curriculum, state standards, class roster, assessment results, and learning progression.

Without access to that information, the AI may sound knowledgeable while operating on incomplete or generic assumptions.

Anthropic's July 2026 Claude for Teachers launch is a particularly good example. The product connects Claude to Learning Commons, which provides academic standards across all 50 US states as well as the smaller competencies and learning progressions beneath those standards. It also integrates trusted curricular sources such as OpenSciEd and Illustrative Mathematics, allowing lesson plans to be grounded in specific educational material rather than generated from generic model knowledge.

The product therefore does not merely tell Claude, “You are an expert teacher.”

It gives Claude access to the materials that teachers actually use to make instructional decisions.

That distinction matters because domain authority increasingly comes from provenance.

A useful vertical system should be able to answer not only, “What does the model think?” but also, “Which trusted source supports this conclusion?”

This is especially important in domains such as finance, healthcare, legal services, HR, payroll, education, and compliance, where a plausible answer and a defensible answer are not the same thing.

Domain tools turn advice into work

The next step is tools.

A general AI assistant can explain what someone should do. A vertical AI product increasingly needs to participate in the workflow itself.

An HR assistant may explain how to onboard an employee. A vertical HR agent should potentially be able to retrieve the employee record, determine which documents are missing, create tasks in the HRIS, check the appropriate policy, prepare required forms, and escalate exceptions.

A financial model assistant may explain discounted cash flow methodology. A production financial agent may need to read filings, pull market data, update a real Excel model, calculate comparables, create charts, and produce a review-ready deck.

A teaching assistant may suggest a differentiated lesson. A vertical education system can potentially inspect assessment results, align material to a particular standard, generate different versions for different proficiency levels, and push those materials into the tools teachers already use.

Anthropic's financial-services agents make this transition explicit. Their templates cover concrete jobs such as building pitchbooks, reviewing earnings, reconciling general-ledger accounts, checking valuations, preparing month-end close, and auditing statements. Each agent combines instructions with data connectors and task-specific sub-agents so that it can operate inside actual finance workflows rather than merely discuss them.

The product boundary therefore moves from:

Ask domain questions

to:

Perform domain work

That is a much more meaningful definition of vertical AI.

The workflow is often the real intellectual property

This leads to another important point: the most defensible part of a vertical AI product may not be the model or even the prompt.

It may be the workflow.

Every professional domain contains routines that are obvious to experienced practitioners but difficult for outsiders to reproduce. A payroll specialist knows which changes require retroactive recalculation, which jurisdictional rules matter, when a discrepancy requires human investigation, and what evidence must be retained. An underwriter knows which data points deserve additional verification. A teacher knows that producing a worksheet is not the same as designing instruction around a learning progression.

These decisions form an implicit process architecture.

Turning them into an AI product means identifying the sequence of work, the information required at each stage, the allowed actions, the decision boundaries, the exception paths, and the conditions under which a human needs to intervene.

That work is much harder than writing a domain persona.

OpenAI's current Workspace Agent guidance reflects the same shift. OpenAI describes agents as reusable systems for repeatable work that depend on shared systems, standard handoffs, consistent outputs, timing, accuracy, and real-world constraints rather than one-off prompting.

This is why I believe domain workflow design will become a major source of product differentiation.

Two companies may use exactly the same frontier model.

One has a prompt.

The other understands the job.

The second company has the stronger product.

Domain evaluation is different from general model evaluation

A domain product also needs a domain definition of correctness.

Suppose a model performs well on broad reasoning benchmarks. That tells us almost nothing about whether it correctly handles a particular payroll adjustment, follows an investment firm's valuation methodology, or produces classroom material aligned to a specific educational standard.

Vertical AI therefore needs evaluations that represent the real work.

Claude for Teachers is again instructive. Anthropic says its teaching skills were co-developed around tasks teachers identified as important and were evaluated for pedagogical rigor, standards alignment, and classroom usability before being refined through educator feedback.

Those criteria are domain-specific.

A generic language-quality score would not be enough.

In financial services, evaluation may include whether the agent uses the correct comparables, preserves formulas, cites the right sources, applies the firm's methodology, follows approval requirements, and produces numbers that reconcile with the system of record. Anthropic explicitly positions its financial templates as adaptable to firm-specific modeling conventions, risk policies, and approval flows.

That means the eval suite itself becomes part of the vertical product.

It encodes what experts in the domain consider acceptable work.

This is strategically important because models will change. A product that depends primarily on “Model X is very good at finance” can lose differentiation when another provider releases a stronger model. A product with a sophisticated set of domain workflows and evals can adopt the stronger model while preserving the operating knowledge around it.

The model is replaceable.

The definition of good work is much more durable.

Permissions are part of domain knowledge

Permissions may appear to be a horizontal platform concern rather than a vertical product concern.

In practice, domain-specific permissions often encode domain logic.

Consider payroll. A payroll administrator may see information that a line manager cannot. A manager may approve certain employee changes but not alter banking information. Some actions may require dual approval. Different countries may have different roles, data-access rules, or retention requirements.

A generic permission system can enforce access controls, but the vertical product needs to know which access patterns make sense for the domain.

Finance provides similar examples. Research access, investment-banking information barriers, client confidentiality, compliance controls, and approval paths can determine which sources and actions are appropriate for a particular user.

Anthropic's current financial-services architecture emphasizes governed access to external and internal data, while its deployment guidance explicitly calls out access, controls, oversight, and the point at which an agent hands work back to a human.

This means vertical AI design cannot separate “what the agent knows how to do” from “who is allowed to let it do it.”

Authority is part of the workflow.

Compliance cannot be added as a footer

Regulated domains expose the limitations of prompt-level verticalization particularly quickly.

An application can tell a model to “comply with relevant regulations.” That sentence may improve its reasoning, but it does not create a compliant system.

Compliance involves data handling, retention, access controls, consent, auditability, geographic requirements, organizational policy, contractual commitments, incident response, and sometimes mandatory human oversight.

Claude for Teachers, for example, includes specific K-12 privacy terms, states that data supplied through the product is not used for model training, and provides a K-12 Data Processing Addendum designed around FERPA requirements.

That is not a prompt instruction.

It is product architecture, legal architecture, and operational architecture.

Anthropic's 2026 partnership with TCS makes the same requirement explicit in other regulated sectors. The companies are targeting financial services, healthcare, and the public sector, with Anthropic noting that these industries require highly accurate and auditable systems and that implementation must satisfy regulatory requirements.

A vertical product therefore has to understand the constraints of the market in which it operates.

Sometimes those constraints are part of what creates the product opportunity.

A generic AI system may be capable of doing the intellectual task, but enterprises will not adopt it until someone builds the controls required to make that capability operationally acceptable.

Human review is a domain design decision

Another characteristic of real vertical AI is that human involvement is deliberately designed rather than treated as an unfortunate limitation of the model.

Different domains have very different tolerance for autonomous decisions.

A marketing assistant may be able to generate internal campaign ideas without approval. A payroll agent changing a bank account should probably operate under a much stricter policy. A teacher may want AI to prepare materials while retaining control over what actually reaches students. A financial institution may allow an agent to assemble research while requiring an analyst to approve investment conclusions.

The important question is not whether the model is “accurate enough” in general.

It is which parts of the workflow the organization is willing to delegate.

Anthropic's financial-agent materials explicitly describe choosing a specific role for an agent, connecting the appropriate tools and data, and defining where the agent hands work back to the user.

This handoff is part of the product.

A good vertical AI system should know when it has enough authority and evidence to proceed, when it needs approval, and when it should stop because human judgment is required.

In that sense, verticalization involves understanding not only domain knowledge but the division of responsibility inside the domain.

Integration into the existing toolchain matters

Professional users rarely perform their entire job inside one AI chat interface.

Finance professionals live in spreadsheets, market-data terminals, email, document systems, and internal databases. Teachers work across learning-management systems, curriculum resources, assessment platforms, presentation tools, and school records. Engineers use repositories, issue trackers, CI systems, terminals, documentation, and cloud platforms.

A vertical product that requires users to abandon their existing working environment and manually copy information into a chatbot is still missing part of the workflow.

Anthropic's current industry products demonstrate how important this integration layer is becoming. Claude for Financial Services connects directly with Excel and other Microsoft 365 applications and integrates with a broad ecosystem of market-data and research providers. Claude for Teachers connects to curriculum sources and an ecosystem of tools including ASSISTments, Canva Education, Diffit, MagicSchool, Snorkl, TeachFX, and others.

The model may be the same Claude underneath both products.

The value is created by putting that intelligence inside different working environments.

That is a useful way to think about vertical AI more broadly.

The model provides general intelligence.

The vertical product provides situated intelligence.

It understands where the professional works, what information exists there, what tools are available, what the user is trying to accomplish, and what happens next.

Vertical AI is increasingly a systems-integration problem

This also explains why better foundation models will not automatically eliminate vertical AI companies.

If models continue improving, many tasks that once required domain-specific fine-tuning or elaborate prompting may indeed become easier. Generic models will understand more professional terminology, reason better about specialized problems, and require less custom orchestration.

That reduces the value of superficial specialization.

It does not necessarily reduce the value of deep integration.

OpenAI's Frontier announcement makes a similar observation from the enterprise perspective: the bottleneck for leading organizations is increasingly not raw model intelligence but how agents are built and operated inside the organization.

A model can understand what a payroll adjustment means.

It still needs access to the payroll system.

It needs the correct employee data.

It needs jurisdiction-specific rules.

It needs authorization.

It needs to know which actions require approval.

It needs auditability.

It needs an evaluation suite proving that its decisions remain acceptable after the model changes.

Those are implementation problems.

The stronger general models become, the more vertical differentiation may migrate away from basic intelligence and toward the systems surrounding it.

The moat is moving upward

This has important consequences for vertical AI startups.

A few years ago, having access to a model that performed unusually well on a specialized task could itself create meaningful differentiation. As frontier capabilities improve and become widely available through APIs, that advantage becomes harder to defend.

Prompt engineering is also difficult to protect as a long-term moat. Competitors can often reproduce a persona, formatting style, or simple workflow quickly.

The more durable assets are likely to sit above the model.

Proprietary or licensed domain data can matter. Deep integrations with systems of record can matter. A large collection of real workflow traces can matter. Domain-specific eval suites can matter. Carefully designed permission models, compliance architecture, and operational workflows can matter. Distribution and trust inside a professional community can matter enormously.

Most importantly, accumulated understanding of where the difficult exceptions live can become valuable intellectual property.

The easy path through a workflow is usually straightforward.

Vertical expertise is often hidden in the exceptions.

Which cases require escalation? Which documents conflict? Which numbers require verification? Which decisions are legally sensitive? Which user roles may perform which actions? Which apparently minor condition changes the entire workflow?

A company that has encoded thousands of those decisions into its product has something more defensible than a system prompt.

A useful vertical AI stack

I find it useful to think of a mature vertical AI product as a stack.

At the bottom is the foundation model, which provides general reasoning, language, multimodal understanding, and tool use.

Above it sits domain context: trusted internal data, licensed datasets, policies, standards, and proprietary knowledge.

Then comes the domain tool layer: systems of record, external APIs, workflow software, databases, calculators, and actions through which the agent can actually perform work.

Above that sits workflow logic: the sequence of tasks, decision points, handoffs, business rules, and exception paths that define how the job operates.

Next comes domain evaluation: test cases, expected outcomes, quality criteria, edge cases, and historical failures that determine whether the system performs the job correctly.

Then we need authority and governance: permissions, approval boundaries, compliance, auditing, data controls, and escalation.

Finally there is the human operating model: who owns the workflow, where professionals remain in the loop, who reviews exceptions, and who remains accountable for the result.

That entire stack is the product.

The prompt is one configuration inside it.

Domain UX matters too

There is another layer that technical architectures sometimes overlook: the interface itself needs to fit the profession.

A generic chat box is remarkably flexible, but flexibility can create cognitive overhead. Professionals often work more effectively through interfaces that reflect the artifacts and decisions of their domain.

A financial analyst may want the AI working directly inside a spreadsheet where formulas, source cells, assumptions, and model changes remain visible. A teacher may want lesson objectives, standards alignment, differentiation levels, and student materials organized into structures they already recognize. An HR operator may want an agent embedded inside the employee case rather than in a separate chatbot window.

Anthropic's direction again provides evidence here. Claude for Financial Services increasingly puts AI directly into Excel, PowerPoint, Word, and connected financial-data environments rather than asking financial professionals to move all of their work into a generic chat experience.

This suggests that vertical UX may become another source of differentiation.

The ideal interface is often not “ChatGPT, but for this profession.”

It is the profession's existing workspace made intelligent.

A domain prompt can still be useful

None of this means domain prompts are useless.

They are often an excellent starting point.

A strong prompt can help teams explore whether a model understands the domain, identify useful workflows, prototype expected behavior, and test whether users find AI assistance valuable. For narrow internal tasks, a prompt plus retrieval may even be completely sufficient.

The mistake is confusing that prototype with a complete product.

If the system only generates advice that a knowledgeable human independently reviews and acts upon, the risk may be low enough that a lightweight architecture is rational.

But as soon as the product claims to automate meaningful professional work, the bar changes.

The system needs stronger sources of truth.

It needs workflow awareness.

It needs tools.

It needs an explicit authority model.

It needs domain evaluation.

And in regulated or consequential environments, it needs governance and accountability.

The architecture should grow with the amount of responsibility being delegated.

The test for a real vertical AI product

A simple test is to remove the domain prompt mentally.

If the only reason the product feels specialized is that the model speaks like a lawyer, teacher, recruiter, doctor, accountant, or HR professional, the product probably has very little vertical depth.

Instead, ask what else remains.

Does the system connect to authoritative domain data? Does it operate inside the actual professional workflow? Can it use the tools professionals need? Does it understand organization-specific policies? Are domain experts involved in defining acceptance criteria? Can permissions and approval paths reflect real roles? Does the system satisfy relevant compliance and privacy requirements? Does it know when to involve a human? Can it prove where important information came from?

The more of these questions the product can answer well, the deeper its verticalization becomes.

That depth matters far more than whether the first line of the prompt says:

“You are an expert.”

The model is horizontal. The product is vertical.

Foundation models are becoming extraordinarily capable horizontal platforms.

That is good news for vertical AI builders.

They no longer need to create intelligence from scratch. They can increasingly purchase world-class reasoning, language understanding, coding capability, vision, and tool use as infrastructure.

But buying intelligence is not the same as building a product.

A real vertical product takes that horizontal intelligence and embeds it inside a domain's sources of truth, tools, workflows, authority structures, regulatory constraints, evaluation criteria, and human operating model.

Claude for Teachers is compelling not because Claude suddenly received a teacher persona, but because it is connected to educational standards, trusted curricula, teacher workflows, classroom tools, pedagogical evaluation, and K-12 privacy requirements. Claude's finance agents are compelling not because Claude learned financial vocabulary, but because they connect reasoning to market data, spreadsheets, financial workflows, review standards, risk policies, and approval paths.

The model is horizontal infrastructure.

The vertical value is everything that makes that intelligence useful, trustworthy, and operational inside a particular profession.

That is why a domain prompt is not a vertical AI product.

It is only the beginning of one.