How the pieces of the AI landscape fit together

Any working AI system has already answered 4 questions. Which layer it sits at: a finished product, a model called directly, a platform serving that model. Whose model, and which tier. Whether that model is open or closed. Which kinds of media it handles.

Each question has a clean answer on its own. What a business chooses is all 4 at once, and two proposals for the same job can differ on every one of them. The combination is what gets chosen, which is why “picking a model” is rarely the decision being made.

The same job, 4 ways

Most business tasks have more than one working answer, and the answers are different kinds of purchase.

A button inside software already in place. The system a team already uses adds the feature. A closed model from a major lab does the work, on the vendor’s account, and the team never sees which one. Nothing to build, nothing to run, and the price is a line on a subscription the company already pays. What it does is what the vendor decided it does.

A product built for the job. Software for that one process, with the whole workflow around the model: matching, routing, approvals, records, a queue for the exceptions. The model underneath is probably a cheaper tier, and it is not what the company is buying. It is buying the packaged workflow and the fact that someone else has already met a few thousand strange cases. Usually priced per seat with a volume charge on top. This is the industry-tool tier, and quality varies more here than anywhere else.

A build on a hosted model. Engineering points the company’s own data at a model’s API and writes the wrapper: read this, return these fields, write them there, flag anything the model was unsure about. The model is whichever one does that job best this quarter, and swapping it is a configuration change. Costs start at zero and grow with use, on top of a build that happens once. Next to it sits assembly: the same wiring done on an automation platform by whoever owns the process, in days rather than weeks.

A model the company runs itself. The same wrapper, with an open-weight file running on machines the company controls, or on capacity reserved inside its own cloud account. Nothing leaves a boundary the business already governs, which is usually the reason this one is on the list at all. The cost is the capacity, paid whether or not anything is going through it. Somebody has to keep it running, and somebody has to decide when to move to a newer file.

Those 4 walk down the stack. The first two are products. The last two run on platform access or the company’s own machines, with the company’s own code on top. The same model families sit underneath all 4.

On ordinary work the output of all 4 is hard to tell apart. What differs is the cost shape (a line on an existing subscription, per seat plus volume, per page from zero, fixed capacity), what it takes to run, where the material sits while it is being read, and what leaving costs. That last one is worth more attention than it usually gets. Moving off either product strands the tuned rules, the approval routing and years of exception history. Moving between the two builds is mostly a configuration change, because the part that took the work is the company’s own.

Example

Let’s say a finance team of 6 keys supplier invoices in by hand: supplier, invoice number, dates, line items, totals, then a match against the purchase order and a decision on anything that does not line up. 4,000 invoices a month, most of them dull, some of them photographs of a crumpled page. Four proposals come back, one of each kind. The accounting system’s own invoice capture is live the afternoon it is switched on and is a coin toss on the crumpled photograph. Accounts-payable software adds purchase-order matching, approval routing and an exceptions queue, per seat plus volume. Engineering can point the document store at a model’s API in a fortnight and swap the model later in an afternoon. An open-weight model on reserved capacity keeps every invoice inside a boundary the company already governs and hands it the job of running the model. On clean invoices all 4 read the same.

Why the combination is what gets chosen

Each of the 4 questions carries one trade-off.

• Layer. Speed against control. A button inside software already in place works the afternoon it is switched on and does what the vendor decided. A build takes a fortnight and does exactly what the job needs.
• Family and tier. Capability against cost. The top tier from a major lab is better on the hard ones, the crumpled photograph and the handwritten annotation, and costs a multiple per page of the workhorse tier that handles the clean ones perfectly well. At a few thousand documents a month that multiple is noise. At a few hundred thousand it decides the answer.
• Open or closed. Simplicity against where the data sits. Closed access is easier to consume and harder to inspect. Running the file yourself keeps every document inside systems the company already runs, and hands it the job of running the model.
• Media. What a model reads is ahead of what it makes. Reading a photographed invoice is reliable enough to trust, with a check on the ones the model marks as uncertain. Making things is the weaker direction: an image model is fine for a mood board and wrong on the specifics of a logo, and video is younger still.

The combination that fits a piece of work is the one whose 4 trade-offs match what that work can tolerate. That is the fit question asked of the landscape rather than of the task.

Sometimes the 4 answers pull against each other. Then what the work cannot afford to get wrong settles all 4 at once.

Example

Let’s say a clinic wants its consultation notes written up automatically. A wrong medication name in a note is not a typo. The recordings also cannot leave the country the clinic operates in, and the model that summarises best is closed and served from somewhere else. The data question is the one that cannot give. The notes run on reserved capacity inside a cloud region the clinic is allowed to use, on whatever model that region carries, with a clinician confirming every note before it reaches the record. The combination is weaker on capability than the clinic would like, and it is the only one the rules allow.

Example

Now say a marketing team wants campaign images: it generates 20 and keeps 2. Being wrong costs nothing, nothing sensitive goes in, and there is nothing to build. A consumer subscription on a product, image generation, done that afternoon.

Those two differ in almost nothing except what they can afford to be wrong about, and that difference alone sets all 4 answers.

How operating companies actually look

Most operations with AI working at any scale are running several combinations at once, not one.

Example

Let’s say a company of 300 people is 2 years into this. Individual accounts hold consumer subscriptions for drafting, summarising, research and code. The teams whose material should not sit on a personal account have enterprise seats of the same product family. An industry tool or two has AI inside the workflow where the team already works: the CRM, the helpdesk, the marketing suite. A handful of automations run on an automation platform, wired up by the people who own those processes. One or two custom tools run on a platform API, where the workflow was specific enough that nothing off the shelf fitted. And there may be an open-weight model on reserved capacity for the one use case where data residency or sheer volume demanded it. That is 6 combinations, some chosen deliberately and some by accident.

Which is why the question of what could go wrong (the 4 risks) is not a question about “the AI vendor”. It is a portfolio, and each combination in it answers separately for where the material goes and what happens when the answer is wrong.

Where agents changed the picture

An agent is a model running in a loop with tools: it takes a step, reads the result, decides the next step, and keeps going until the job is done or it is stuck.

An agent is not a fifth thing to buy instead of the 4. It is a way of wiring a model up, so all 4 questions are still answered underneath it: the loop runs at some layer, on some model at some tier, open or closed, over some kinds of media. What changed is that the wiring stopped being bespoke. There is now a common standard for connecting a model to business systems, the Model Context Protocol, and the labs and the large cloud platforms have all adopted it. Connecting to company systems covers how it works.

Example

Staying with those invoices, say the build on a hosted model returns the fields for something else to route. An agent instead reads the invoice, pulls up the purchase order, finds the quantity does not match, checks the delivery note, and puts the invoice in a queue with the discrepancy written out.

A connection built once is no longer tied to the assistant it was built for, which removes one of the older reasons to stay where you are. And agent behaviour now ships inside ordinary products at every layer, so a business can be running agents in the helpdesk and the sales tool without having decided to.

Agents do add one question of their own on top of the 4: how far the system gets to go before a person sees it. That is a question about permissions and about how much a single wrong step can touch, and it belongs with the controls that make a system trustworthy. It multiplies the 4 questions rather than replacing them.

What moves underneath a combination

A combination stops fitting on its own, because 3 things keep moving underneath it.

Capability moves down the cost curve. What needed the top tier in one generation usually runs fine on the next generation’s workhorse tier, at a fraction of the price per call. A tool built against the best model available a year ago is often being served by something cheaper today, and the team running it changed nothing.

Open weights caught up on the ordinary work. For everyday business text, drafting, summarising, extraction, classification, the choice stopped being about quality some time ago. What survives is at the harder end: long multi-step work, and the strongest work across media. That distance has narrowed with each release cycle rather than widened, which is worth holding before treating a self-hosting decision as a quality decision.

Drift does not announce itself. A combination stops fitting quietly, and the signals are ordinary. The bill grows faster than the volume going through it. A cheaper tier turns out to match quality on the work being sent to it, the first time anybody tries. A product changes the model underneath without notice and the outputs move with it. None of that reads as a failure, which is the difficulty: the system keeps working while it fits less and less well. It is one of the things worth watching once AI is in production.

Which combination, not which AI

The interesting question is rarely which AI. It is which combination, for this work, on the trade-offs the operation can actually tolerate.

Capability is where what AI can and can’t do goes deeper. Where the material ends up is its own chapter. And a combination becomes a project only once there is a candidate worth doing, which is where the search for one starts.