The model maker moved into your market. Platform, plugin or data?

Since ChatGPT went public in 2022, a vertical AI product has had a simple story. The model makers built general intelligence, and you wrapped it in the knowledge, workflow and trust your industry needed. The model was a supplier. The product was yours.

Last week, OpenAI stepped into one of those verticals itself.

What shipped

OpenAI launched Astra for Law, a legal setup built on GPT-6 Astra. According to the launch text quoted by Artificial Lawyer, it pairs the model with instructions for legal analysis and writing, settings for thorough work, and a new legal search index covering more than 230 million URLs.

Three details matter for anyone who runs a product in a specialized industry:

• Partners arrive as plugins. OpenAI launched 26 partner-built plugins, with Thomson Reuters, Harvey, Legora and iManage among the partners, plus community plugins built by lawyers and legal engineers. (The two write-ups count the community plugins differently, so we leave that number out.)
• The public data layer got absorbed. Case law comes partly from CourtListener, run by the nonprofit Free Law Project. OpenAI says that collection covers more than 99.9% of published US precedential case law.
• The model maker publishes its own scorecard. OpenAI reports that Astra for Law passed an overall correctness check on 54.0% of 200 questions from a legal research benchmark, against 38.7% for its general model with web search. Those are company-reported numbers.

OpenAI described its role plainly: “We’ll maintain the legal configuration so builders can focus on their own products and workflows.”

Thomson Reuters, one of the launch partners, put its own position in its CTO’s words: “As AI becomes more open and interoperable, the value is not in connectivity alone.”

Both sentences are strategy. One says the model maker will own the base layer. The other says the incumbent will own what sits above it. If you build for law, healthcare, finance, insurance or any other specialty, expect the same conversation soon.

Three positions, one decision

When a model maker enters your vertical, your product ends up in one of three places, whether or not you choose:

1. Platform. Users start their work in your product. The model maker is one supplier among several, and you can swap it.
2. Plugin. Users start their work in the assistant. Your product is something the assistant calls. You get distribution, and you give up the first screen.
3. Data owner. You hold something the assistant cannot index: licensed content, customer history, workflow context, or a record of decisions. Whether you are a platform or a plugin, that is what they pay for.

Most products will end up as a mix. The mistake is drifting into the plugin position while your roadmap still assumes you are the platform.

A decision rule

Answer three questions with evidence, not opinion:

1. Is the general version good enough for your users’ core job? Take your 20 most common user tasks and run them in the general assistant with its new industry setup. Score each one as good enough, close, or not close. If more than half come back good enough, the platform story is at risk for that job.

2. Where does the work start? Watch five users begin a real task. Do they open your product, or an assistant, a chat tool or an email thread? If they start somewhere else, a connector is not a side project. It is how you get used.

3. What do you hold that is not in a public index? List every data source your product uses and mark it public, licensed or proprietary. Public sources are now table stakes, as CourtListener’s inclusion shows. Only the other two count as a moat.

Then read the answers together:

Good enough?	Work starts elsewhere?	Private data?	Lean toward
No	No	Any	Platform. Keep the first screen, and make the model swappable.
No	Yes	Any	Platform with a connector. Meet users where they start.
Yes or close	Yes	Yes	Plugin with a data moat. Ship the connector, and charge for the data and actions behind it.
Yes or close	No	Yes	Platform built on your data. Put the private data where users can see it.
Yes	Yes	No	Rethink the product. Find the proprietary layer before you build more features.

A worked example

Here is a made-up product: a lease-review tool for small property managers.

• Of its 20 top tasks, the general assistant does 11 well enough, such as summarizing a clause or flagging a missing date. It struggles with the 9 that depend on local rent rules and the manager’s own portfolio.
• Users start in email, because leases arrive as attachments.
• The tool holds each customer’s portfolio, its past renewals and the notes managers left on disputes. None of that is public.

That is the second row. The tool should expose “check this lease against my portfolio” as an action an assistant can call from the inbox. It should stop investing in generic summaries and put the roadmap into the portfolio-aware checks nobody else can run.

This is product strategy, not legal advice. Products that touch regulated work still need qualified people to review what the product says.

What to do this week

• Run your top 20 tasks in the general assistant. Save the outputs, because they are your baseline for the next model release too.
• Watch five users start a task, and write down the first app they open.
• Put every data source in a list marked public, licensed or proprietary.
• Draft one page on the connector: which three actions an outside assistant could take, and which one must always come back to your screen for a person to confirm.