VYROX AI turns a private local LLM into systems your team uses daily, on hardware you own.
A local model isn't a chatbot toy - it's the engine behind real systems your team uses daily. Filter by function; each shows the model + tool stack we'd deploy.
The same private model on the same hardware runs in three modes - along a spectrum of autonomy. Start with a chatbot for quick wins, add workflows for high-volume operations, then deploy agents for complex 24/7 work.
Swipe to see all columns
| At a glance | 💬 Chatbot | 🔀 Workflow | 🤖 Agentic |
|---|---|---|---|
| Autonomy | Low - human every turn | Medium - runs unattended | High - decides its own steps |
| Path | Free conversation | Fixed pipeline (DAG) | Planned at runtime |
| Determinism | n/a | High - repeatable | Lower - reasoned each run |
| Human oversight | Reads every answer | Reviews exceptions | Approves irreversible actions |
| Build effort | Days | 1-3 weeks | 3-8 weeks |
| Run cost (local) | Lowest | Low | Higher (many calls/run) |
| Best local models | Qwen3.6, Gemma 4, Llama | Qwen3.6, Qwen3-VL, Mistral | Kimi K2.6, GLM-5.1, DeepSeek V4, Qwen3.6 |
| Frameworks | Open WebUI, LibreChat | n8n, LangGraph, Flowise, Dify | LangGraph, CrewAI, AutoGen, OpenHands, MCP |
| Best for | Q&A, support, knowledge | High-volume repetitive ops | Complex multi-step, 24/7 automation |
The mature path: most clients start with a chatbot (value in days), automate their highest-volume process as a workflow, then add agents where the work is genuinely multi-step. All three run on the same local box - and VYROX engineers tool-calling, MCP connectors, guardrails and an eval harness so agents are reliable, not just impressive.
These three professions handle data that is legally confidential - patient records, privileged files, financial accounts. For them, local AI isn't just cheaper; it's often the only compliant option. Each is a co-pilot that keeps the licensed professional firmly in the loop.
⚕️ Decision-support only. A registered medical practitioner makes every clinical decision; the system does not diagnose or treat and is not a registered medical device. It assists documentation and retrieval, with the clinician reviewing all output.
📊 Assists; does not replace professional judgment. A qualified accountant reviews and signs off all output. Not tax or audit advice - it supports the work your licensed professional remains responsible for.
⚖️ Assists qualified legal professionals; it does not provide legal advice. The advocate & solicitor retains full professional responsibility and reviews all output before use.
Success isn't measured by how many AI licences you buy - it's measured by the business value AI creates. Here's how to deploy it strategically instead of universally.
The right starting point depends on who you are and what already eats your time, not on how advanced the technology sounds. Here is how six common roles typically map onto the patterns and co-pilots on this page.
Ambient scribe for consultations, SOAP note drafting and history summaries first, air-gapped for patient privacy. Coding assist and patient leaflets come next.
Document capture and reconciliation first, since that is the highest-volume, most repetitive task. Financial statement drafting and tax/e-invoice support follow.
Contract review and clause flagging first, then drafting from the firm's own precedent bank. Legal research over your matter files (RAG) usually follows within the same build.
A staff knowledge assistant or customer-support chatbot over existing SOPs and product docs. Lowest run-cost, days to deploy, and a human reads every answer.
A fixed, auditable pipeline for invoice processing or QA report analysis: high determinism, exceptions reviewed by a human, everything else runs unattended.
An IT helpdesk agent or procurement/quote-comparison agent, with human-in-loop approval gates on anything irreversible. Highest build effort, but runs 24/7 once live.
A general model knows the public internet. It does not know your contracts, SOPs, pricing or customer history. RAG (Retrieval-Augmented Generation) grounds every answer in your own documents - with citations - and on a local deployment that data never leaves the building.
The co-pilots above cover clinics, accounting firms and law firms. These five industries start somewhere different. In each case the first task is the one that is already document-heavy, repetitive and slow, not the one that sounds the most advanced.
Swipe to see all columns
| Industry | Start with | Pattern | Typical stack | Build effort |
|---|---|---|---|---|
| Manufacturing | QA and inspection report analysis: defect trends, recurring root causes | Workflow AI | Qwen3 + nomic-embed + Qdrant | 1-3 weeks |
| Retail and distribution | Supplier invoice and delivery order extraction into the accounting system | Workflow AI | Qwen3-VL + schema validation + MCP connector | 1-3 weeks |
| Education | Staff and student handbook Q&A over your own policies and circulars | Chatbot AI | Gemma 3 / Qwen3 + bge + Open WebUI | Days |
| Property management | Tenancy agreement and house-rule Q&A, plus complaint and work-order triage | Chatbot AI, then Workflow | Qwen3 + nomic-embed + pgvector | Days to 3 weeks |
| Logistics | Shipping document extraction: delivery orders, packing lists, customs paperwork | Workflow AI | Qwen3-VL + Qwen3 + validation on vLLM | 1-3 weeks |
Build effort is the same scale used in the pattern comparison above: days for a chatbot, 1 to 3 weeks for a workflow, 3 to 8 weeks for an agent. It is engineering time, not calendar time waiting on hardware.
A local model is far more useful when it can read the systems you already run. We connect it over MCP (Model Context Protocol, a standard way for an AI model to call external tools) so it reads and assists rather than replacing anything. Every integration is scoped per project: what follows is the category, not a promise that your specific product version works out of the box.
Swipe to see all columns
| System category | What the model does with it | Usual access | Scoping note |
|---|---|---|---|
| Accounting and ledgers | Answers plain-language questions over the general ledger, drafts commentary, writes extracted entries back for review | Read-only database view, or the product's own API | Write-back is added only after read-only has run cleanly |
| ERP and inventory | Looks up stock, orders and supplier records to ground an answer | Read-only view or API | Depends entirely on what your ERP exposes |
| HR systems | Answers leave, claims and policy questions against real entitlements | API, with role-based access control | Access is scoped per user, not per company |
| Document stores | Indexes shared drives, intranets and folders for retrieval with citations | File share or connector, indexed locally | Folder permissions must be mirrored in the index |
| Classifies, routes, summarises and drafts replies for a human to send | IMAP or the mail platform's API | Sending stays behind a human approval step by default | |
| Messaging and chat | Puts the assistant where staff already work instead of a separate window | Platform bot API | Message content routes through your server, not a vendor cloud |
| Legacy apps with no API | Drives the interface directly when there is no other way in | Computer Use or Browser Use, sandboxed | Slower and more brittle, so it is a last resort |
Adoption fails when a system is switched on for everyone at once with no owner and no measurement. This is the phased plan we run instead: a small pilot group, two use cases, a real baseline, then widening only on evidence.
Swipe to see all columns
| Phase | Focus | Who is involved | What done looks like |
|---|---|---|---|
| Days 1 to 5 | Install, connect the first document set, set access rules | VYROX engineer plus your IT contact | Model answering over real internal documents with citations |
| Days 6 to 12 | Pilot group starts, first use case only, daily use expected | 3 to 8 pilot users and one internal owner | Every pilot user has asked it something real in their own work |
| Days 13 to 20 | Fix what the pilot exposed: missing documents, wrong permissions, weak prompts | Internal owner plus VYROX | The top complaints from week one no longer happen |
| Days 21 to 26 | Add the second use case, usually the highest-volume repetitive one | The team that owns that process | Second use case running with a human reviewing exceptions |
| Days 27 to 30 | Review against the baseline, decide who gets it next | Management plus the internal owner | A written go or no-go with numbers, not impressions |
After day 30 the pattern repeats: one new use case at a time, each with a named owner and a measurable before-and-after. Widening happens because the last one worked, not because the licence covers more seats.
Usage counts are the easiest number to collect and the least useful. These are the measures worth putting in front of management at the 30-day review, and the ones we help you instrument.
Swipe to see all columns
| Measure | How to capture it | Why it matters |
|---|---|---|
| Time on the target task | Same simple timing method before the pilot and at day 30 | This is the number the business case rests on |
| Rework rate | Share of outputs a human had to substantially redo | Distinguishes a helpful draft from extra work |
| Exception rate | For workflows: items the pipeline could not handle alone | Tells you how much human review is still required |
| Repeat use by pilot users | How many of the pilot group are still using it in week four | Honest adoption signal, unlike total query count |
| Answer traceability | Share of answers carrying a citation staff could open | Verifiable answers are what make it trusted |
| Escalations avoided | Questions answered without pulling in a senior colleague | Captures value that never appears in a timesheet |
Illustrative, using placeholder numbers you would replace with your own measurements. Suppose two staff each spend 8 hours a week keying in supplier invoices, so the baseline is 16 hours a week. At day 30 the workflow handles most items and the same two staff spend 5 hours a week reviewing exceptions instead. The saving is 11 hours a week, and the exception rate tells you whether that number is likely to improve further or has settled. Multiply the recovered hours by your own fully loaded hourly cost to get the figure a finance lead will ask for, and compare it against the one-time build cost on the Pricing page.
We do not publish saved-hours claims as if they were yours. The only numbers worth quoting internally are the ones you measured on your own baseline.
Short, plain-language answers about picking a starting point. For the wider glossary and general FAQ, see the Resources page.
Book a free 45-minute Local-AI Audit. We measure your current cloud spend, spec the exact build, and give you the costed break-even date - in writing, no obligation.
No deck pitch. Just engineers sizing your build.
Free Local-AI audit