Vertical agents should encode regulatory workflow, not domain vocabulary

Vertical agents should encode regulatory workflow, not domain vocabulary. I do not see specialised terminology as the product moat. A model can learn the language of contracts, clinical notes, finance, or software surprisingly quickly. The harder production problem is turning that fluency into bounded work—what the agent may do, what evidence it must retain, which tool it may call, how its output is checked, and where a human must take over.

I use a stricter definition of a vertical agent: a policy or model, memory, tools, a verifier, and an environment assembled around a specific job. Remove the surrounding machinery and the result is usually a domain-aware chatbot. It may sound credible in legal research or regulatory compliance, but it has not encoded the route from request to admissible action. Vocabulary improves the conversation; workflow determines whether the system survives production.

Legal work makes the distinction clear. Contract analysis is not merely recognising clauses, and legal research is not merely producing fluent summaries. The product has to preserve the task context, call the right retrieval or analysis tools, verify what comes back, and present uncertainty at the point where judgment is still required. I treat those controls as product behaviour—not an after-market governance layer. That is the practical argument behind designing vertical agents around constraints.

The same structure applies to financial agents and agents handling regulatory compliance. Their useful unit is not an answer; it is a traceable step inside a controlled process. Memory must carry the right state forward, tools must expose only the actions the step requires, and the verifier must test the result before the environment accepts it. The interface should make that sequence legible because liability follows authority when a product moves from advice toward action.

Healthcare raises the cost of getting this architecture wrong. Under HIPAA or MDR constraints, a clinical documentation agent or prior-authorization agent cannot be designed as generic intelligence wearing medical vocabulary. The product has to encode which information enters the workflow, what transformation is being attempted, what evidence accompanies the output, and who resolves a failed check. I am not inventing compliance by adding a disclaimer—the workflow itself must expose the controls its environment demands.

This also explains why code generation belongs in the same conversation. Code vocabulary is abundant; production acceptance is scarce. A useful coding agent operates inside an environment, invokes tools, remembers relevant state, and submits work to verification. Its verticality comes from the shape of the delivery loop, not from knowing framework names. Devtools and healthcare look distant as markets, yet both become dependable through explicit permissions, testable transitions, and visible failure paths.

That pattern scales across support, cybersecurity, education, government, marketing, operations, recruiting, and sales. Each category supplies nouns, but the product opportunity lies in its verbs and gates: retrieve, draft, compare, check, approve, escalate, record. I would map those transitions before tuning domain language. Regulation then becomes a design input—similar to the argument in treating the AI Act as a design input—rather than a document consulted after the core interaction is fixed.

The operational centre of this product is the exception path. Verifiers will reject outputs, tools will return incomplete results, memory will lack required context, and policies will block actions. Those events are not edge-case clutter; they are where authority changes hands. I design the human queue, evidence bundle, and resumption point as first-class product surfaces. If nobody owns the exception queue, the agent has no credible route from automation to accountable completion.

I make one precise concession: in low-authority tasks such as drafting educational or marketing material for human review, deep regulatory workflow may add more friction than value. Even there, the broader architecture still helps distinguish a useful vertical product from a fluent wrapper. My product test remains concrete—can I describe the policy, memory, tools, verifier, environment, and exception owner for the job? If I can only list domain terms, I have described a vocabulary pack, not a production agent.