A workstation that teaches its own use
The research on this site keeps arriving at the same place. A large company prepares before anyone types a question: the model gets the firm's own documents, it is wired into the software staff already use, and someone has decided what a person checks before an answer is acted on. A small organisation gets the chat window and none of that preparation. Meanwhile the national training answer is counted in courses completed, and the number of people who can actually do something afterwards is not published.
So this is what I am building in response. An AI workstation that sits on a small organisation's own premises. It runs models on its own hardware, or splits the work between that hardware and a paid service where the split makes sense. It carries workflows built around the jobs that organisation actually has. And it carries a tutor layer, which is the part I think matters most.
What it is built on
Three claims, and deliberately not a fourth. A machine like this will not out-think a frontier model running in somebody else's data centre, and I am not going to argue that it does. What it can offer is different.
The work stays in the building
Client records, quotes, drawings, correspondence. When the model runs on a machine in the office, none of it has to leave to be useful.
The cost is known in advance
Hardware is bought once and the running cost is electricity. There is no per-question meter, which makes a small budget easier to plan against.
People get better at using it
The machine is meant to teach as it works, so the organisation ends up more capable rather than more dependent. That is the tutor layer below.
The tutor layer
A workstation that only serves models is a faster way to do what people already half know how to do. It does not make anyone better at the work. The tutor layer is the part meant to change that.
It is the machine's own front end, and it holds the guidance on using the thing properly rather than leaving that in a course somebody took once. The intention is that it builds a picture of each person over time, so what it offers fits who is asking. Someone learns by logging on and asking, and the answer they get is shaped by what they have already worked through. That is a different shape from completing a course and returning to the job unchanged.
I have not found anything else that bundles this with the hardware. That is a statement about what I have looked at so far, not a finding about the market.
Where it has actually got to
Before any of this goes in front of an organisation, it has to run. The project's own desktop is the testbed, and it answers three questions in order. The rule I work to is that a step stays marked planned until it has been run on the machine, so the statuses below are the real ones.
Phase 1 — does owned hardware serve a useful model?
An eight-core desktop with a 20 GB graphics card, running a model natively. The question is whether hardware I already own answers at a speed someone would tolerate. A fixed set of three prompts is written so every future run and every future card can be compared against the same measure.
Phase 2 — does it work as a deployable shape?
The same capability, but as Linux containers that could be stood up on a customer's machine rather than hand-installed application by application. A thing that only works because I set it up by hand is not a product.
Phase 3 — is it good enough for real work?
Capability is task-specific, so the honest test is a set of jobs a small organisation would actually hand over. This phase also carries the tutor layer, and it is deliberately held back until phases one and two produce numbers.
The measurements, once the machine has actually run them
When phase one runs, this is where the numbers land: the models tried, the speed each returned at, memory used, and where it stopped being usable. The same three prompts every time, so a later run on different hardware is a fair comparison rather than a fresh anecdote. The Intel Arc Pro card described below gets the same treatment when it goes in, and both sets of results are published whichever way they fall.
The hardware question
How much graphics memory a card has decides which models will run on it at all, and that single number drives most of the cost of a machine like this. I researched the options at length before spending anything, and the working document is in the repository with every price dated and sourced.
The desktop currently holds an AMD card, so the first phases exercise the AMD side of the open software stack. An Intel Arc Pro B70 with 32 GB is the card chosen to go in alongside it, which is why the AMD phases are sequenced first: the two cards share one usable slot. Intel's own software route for these cards can only be tested on Intel hardware, so that question stays open until the card is in and running.
What is not settled
Four things are genuinely open, and I would rather state them here than have someone find them later.
It is untested end to end. No part of the deployment has been run on the target machine yet. The plan is written and verified against the manufacturers' own documentation; that is not the same as it working.
The cost case has a threshold in it. My own research on this found that below a certain level of use, paying a cloud provider per question stays cheaper than buying and running a machine. Owning the hardware wins on data locality and on predictability well before it wins on price, and an honest version of this offer has to say which of the three a given organisation is actually buying.
Nobody has shown that small organisations want this. The gap in provision is evidenced and the pages on this site set out that evidence. Whether firms would adopt an on-premises machine, and what they would pay for it, is not evidenced at all. It is recorded as an open question in the project log rather than quietly assumed.
The tutor layer is the least proven part of it. It is also the part I think the whole idea rests on, which is an uncomfortable combination and the reason phase three exists.