Choosing AI: companies, products and models

Identify the system before deciding whether to pilot, hold or proceed. Your firm needs to know the contracting supplier, the product and account people will use, the exact model or model-selection policy where disclosed, the disclosed hosting provider, and the route through which the work will run. A familiar brand is not enough.

This distinction matters because a demonstration, subscription and proposed integration may involve different systems. An application may change its underlying model. The same model family may appear through providers with different tools, controls and terms.

The decision is not “Which AI company is best?” It is:

What exactly are we evaluating or buying, for which task, and what does the evidence permit us to do next?

This guide provides historical identity examples and a system-level decision framework. It does not rank vendors, establish current Australian access or recommend a universal winner.

Start here: choose your next question

• Identifying an offer? What does the quote actually commit us to? separates the contracting entity, product, account and delivery relationships.
• Checking access? Can our intended Australian account use this exact capability? separates announcements, documented eligibility and authorised account checks.
• Comparing task fit? Which candidate meets our task acceptance rules? provides the shared testing procedure and evidence record.

Separate the identities behind the name

An AI purchase can involve several organisations and technical layers. Start with five distinctions.

The supplier is the legal entity with which the firm would contract. It may be the model developer, a platform provider or another business supplying an application. A developer’s reputation does not identify the party responsible under your proposed agreement.

The product is the application or service being offered. Its edition and account plan matter: a demonstration does not establish the controls included in the proposed subscription.

The model generates or transforms content within that system. Record its exact identifier and revision when disclosed. Where a product selects models dynamically, record the selection and change policy instead of inventing a fixed identity.

The delivery or hosting provider is the disclosed organisation or organisations operating the service through which work would pass. Record their relationship to the contracting supplier and model developer; mark an undisclosed relationship as unknown.

The actual account and plan identify the proposed account, subscription tier and administrator. Record the included controls still to verify in that account. A demonstration or product description does not confirm its settings.

These distinctions make comparisons useful. They also prevent a purchase decision from silently becoming permission for a wider deployment.

Historical examples: separate the names and routes

These primary announcements illustrate the distinctions. They are historical examples, checked 5 October 2026, not a current model catalogue or an account entitlement record.

Dated source	What the source distinguishes	Procurement question
OpenAI API, 11 June 2020	API access to models, launched in a private beta	Does the offer identify the API service, account and model separately?
ChatGPT, 30 November 2022	A conversational research release	Is the proposed purchase a chat product or a separately configured integration?
Mistral Large, 26 February 2024	A named model offered through la Plateforme and Azure	Who supplies and operates the route in this particular offer?

The model developer, named product, delivery provider and contracting entity must be recorded separately. These sources do not identify your proposed legal supplier. Copy it from the actual agreement. If a model identifier or hosting relationship is undisclosed, write not disclosed and assign the question to an owner.

A historical launch or distribution partnership does not establish that a named model remains offered today. Recheck the exact product, account, identifier and route before evaluation.

Record the delivery route and configured workflow

Record how the firm reaches the capability: for example, a hosted application, provider API or separately operated runtime. The interface alone does not establish who hosts the model. A model that drafts text without tools is a different operational proposition from a system permitted to edit records or send messages.

Alongside the offer, record instructions, input sources, any retrieval, connected tools, permissions and review boundaries. Mark each unconfirmed layer as unknown. If a supplier says selection varies by task, preserve that statement and its dated source instead of guessing a fixed revision.

A browser, command line or API label is not evidence of execution location or privacy. Ask for the relevant provider and processing evidence. For actions that read or change records, use the canonical agent tool-authority guide.

Turn labels into acceptance questions

When an offer says flagship, frontier, small or budget, ask what the label means for the proposed task. Record disclosed limits and price assumptions as evidence to check, then set observable acceptance rules. A label is not a task-fit result.

For an internal action register, ask whether each action is traceable to the note, whether conflicting deadlines remain unresolved and how much checking the draft needs. The task-fitness scorecard owns that procedure. No candidate score or performance advantage is established here.

Take rights and operating arrangements to Weights

Use Weights for rights and permissions, hosted access versus operating weights for operating responsibilities, and output reuse and distillation for training-material provenance and applicable terms. Those guides own these topics. Selection records which offer or artefact needs the check.

Worked example: one demonstration, two different decisions

This is a fictional, unexecuted example. No supplier, client engagement or test result is represented.

A professional-services firm sees a browser demonstration that turns invented policy notes into a summary. Staff like the interface. The firm then considers using an API to produce draft summaries inside its document workflow.

It would be easy to describe both proposals as “using the same AI”. That description leaves important questions unanswered.

The browser demonstration identifies an application experience. It does not establish the model revision, API entitlement, proposed contracting party or configuration of the integrated workflow. Even a matching model-family name would not prove that the demonstration and integration use the same instructions, retrieval or tools.

The firm therefore separates the decisions:

• A browser pilot could be considered for invented material, human-reviewed drafts and no connected actions, subject to identified terms, access and approval.
• The API integration remains on hold until its supplier, account, model or selection policy, delivery route and operational responsibilities are sufficiently identified.

These are possible decision boundaries, not approvals or performance findings. If the browser pilot later succeeds, it supplies evidence about that pilot—not automatic clearance for the API workflow.

The useful outcome is a clear object of evaluation. Use the task-fit procedure to test each configured candidate without turning an attractive demonstration into evidence for a different system.

Conclude with a bounded decision

Keep a short decision statement rather than duplicating the procurement and test worksheets:

We are evaluating [product and account], supplied by [contracting entity], using [model/revision or disclosed selection policy], through [delivery route], for [bounded task]. Remaining uncertainties are [gaps]. [Decision owner] authorises [next step and limits], subject to [review trigger].

Choose the outcome that the evidence supports:

Outcome	Meaning
Pilot	A specifically authorised, limited evaluation can proceed with defined inputs, review and stop conditions. Production permission does not follow automatically.
Hold	A material identity, rights, access, handling or control gap prevents the proposed next step. State the evidence needed to reconsider.
Proceed	Evidence and organisational approval support the stated operational use, with defined controls and ownership—not an unrestricted endorsement.

An undisclosed model identifier is not automatically a universal rejection. It is a limitation for the decision owner to assess against the proposed use. Where reproducibility or change control is essential, that uncertainty may be decisive.

Reopen the decision when a material dependency changes: model revision, selection policy, plan, provider, tools or permitted task. Preserve the earlier evidence so the firm can see what changed.

The goal is not to buy the most impressive name. It is to make an identifiable, supportable commitment—and to keep the next action within what the evidence and authority actually allow.

Continue with the right owner

Use the published Hermes guide for Hermes product detail. For coding work, use repository preflight and longer-running coding evaluation. Organisation-wide rollout belongs to the AI workforce orchestration guide.

Sources and boundaries

The three linked historical announcements above support only their named model, product and route distinctions at the stated dates. The eight Selection milestones on the timeline retain individual source passages and access limits. Primary passages checked 5 October 2026. Worksheets and examples are an original decision method; no supplier agreement, Australian account, model performance, privacy or portability has been verified by this guide.