This page is written for the person who has to explain the choice to a technical colleague. It covers how a model gets picked for your workflow, what fine-tuning actually needs from you, how the operator reaches the systems your staff already use, and how to decide between cloud AI and a server in your own building.
AutoServa is not a wrapper around one vendor. Model choice is a per-workflow engineering decision, made against six criteria and re-tested whenever a materially better model ships.
A contract that needs three clauses cross-checked against a playbook is a harder reasoning task than coding an invoice line. Harder queues get a stronger model even though it costs more per case, because a wrong answer costs more than the inference.
Some queues are mostly long-document comprehension. Others are short structured records. Models differ noticeably at long-context reading, and we test yours on your own documents before choosing.
An overnight reconciliation pack can use a slower, more thorough model. A service desk first response cannot. Latency is a real selection criterion, not an afterthought.
If policy says nothing leaves the building, the cloud models are off the table regardless of how well they score, and we select from open-weight models that run on your hardware instead.
A queue running two hundred cases a day has a very different economics profile from one running twenty. We size the model to the volume so the running cost stays proportional to the work.
Every deployment is built so the model underneath can be swapped. The decision framework, the precedent and the evidence trail belong to you and do not move when the model does.
Fine-tuning is often imagined as a data-science project that needs a clean labelled dataset. It is closer to onboarding a very fast new hire: it needs the real material, the real decisions and time with the person who knows why.
Past invoices, contracts, tickets, reports, memos. Whatever your team reads and writes on this queue. Not a curated sample, the real spread, including the awkward ones.
Cases where we can see both what arrived and what your team decided. This is what lets us test the operator against your own history rather than a generic benchmark.
Templates, standard terms, accounting treatments, service levels, tolerances. Whatever version is actually in force, even if it is out of date in places.
Read access first, during Observe and Capture. Write access only when the workflow moves to a supervised live run, and only to the systems that queue touches.
The single hardest input to get and the one that matters most. Roughly a few hours a week from the person who actually decides, across the first three weeks.
Who signs off on what, and at which threshold. If this only exists as an understanding rather than a document, writing it down is part of what we deliver.
There is no migration and no new database. The operator connects the same way a member of staff does, and where a proper interface exists we use it in preference to anything else.
If your ERP, CRM or accounting system exposes an interface, that is what the operator uses. It is faster, more reliable, and easier to permission precisely than any alternative.
Plenty of the systems real work depends on are portals nobody ever built an integration for. The operator signs in and works them the way your staff do, under its own named account.
The operator is provisioned like a new employee: a named account, permissions limited to the queue in scope, and an access log. It never shares a human colleague's login.
This is usually settled in the first working session, because it is a policy question rather than a technical preference. Here is the guidance we give.
| If this is true | What we deploy | Why |
|---|---|---|
| Data can leave your infrastructure | Cloud frontier model | Best reasoning available, no hardware to buy, and the model can be upgraded the moment a better one ships. |
| Data cannot leave your building | Local AI server, open-weight | Runs entirely on hardware you own. You trade some reasoning headroom for total physical control of the data. |
| Some queues sensitive, others not | Both, split by workflow | We deploy the sensitive queue locally and the rest on cloud models. Same operator design, same Workflow Guard, two runtimes. |
| Regulator requires data residency | Cloud in-region, or local | Several providers offer in-region hosting. Where that is not sufficient for your regulator, local is the answer. |
Whichever runtime you land on, the decision framework, the precedent library, the evidence trail and Workflow Guard are identical. Only the model underneath changes.
This list moves. It is a snapshot of what we currently reach for, not a commitment to any one vendor, and any deployment can be moved to a newer model without rebuilding the framework around it.
Used where policy allows data to leave your infrastructure and the queue benefits from the strongest available reasoning.
Used where data cannot leave the premises. You own the hardware and the weights, and nothing about the queue depends on an outside connection.
The questions on this page are the ones they will ask, and they are better answered in a room than in a document. We will go through model choice, access scope and data handling for your specific queue.