GuluStock and AutoServa · GuluStock and AutoServa: User Guide
AutoServa is VYROX's workflow automation service: VYROX consults, designs, deploys and runs an agentic AI "operator" trained on a business's own experience, standards, precedent and decision-making framework, working inside that business's existing systems. It is used by organisations with repeatable, judgement-heavy queues in finance, legal, procurement, service desk, reporting and operations, where humans keep approval on anything irreversible.
Your people keep the objective, the judgement calls and the approval of anything that leaves the business.
| Department | Typical Work |
|---|---|
| Finance | Invoice coding, journal entry testing, overnight reconciliation packs, chasing missing documents, variance commentary drafts |
| Legal and Contracts | Playbook-based contract review, redline drafting, fallback-position tracking, summary memos |
| Procurement | Requisition checks against budget, policy and suppliers, exception routing, rate-card comparison, PO drafting |
| Service Desk | First-response drafts from the knowledge base and precedent, routine diagnostics, escalation with the diagnosis attached |
| Reporting | Recurring packs rebuilt from source, variance commentary, definition-drift flags, audit-ready schedules |
| Operations | Exception queue clearing, evidence-attached tickets, recurring-pattern alerts, shift handoff summaries |
The deciding factor is the workflow, not the industry label or headcount. AutoServa fits any organisation with a repetitive, reviewable, decision-heavy queue, most often mid-size to large organisations.
Before anything is automated, the operator absorbs how your business actually decides:
| Item | What It Covers |
|---|---|
| Experience | How the work is really done, including exceptions nobody wrote down |
| Decision Framework | Inputs, thresholds, constraints, approvals and escalation paths, made explicit |
| Standards | Templates, standard terms, accounting treatments, tolerances and service levels |
| Precedent | What was decided last time and why, kept searchable |
| Vocabulary | Entity names, cost centres, product codes, project references and internal shorthand |
AutoServa works your existing stack. There is no migration and no new screen for your staff to learn. It uses four connection methods, in order of preference:
| Method | When It Is Used |
|---|---|
| Direct API | Wherever one exists, with scoped credentials and rate limits |
| The Browser | Where no API exists, such as regulator, bank and insurer portals or supplier extranets, using its own named account |
| Mail and File Stores | A dedicated mailbox or scoped folder, never a person's own inbox |
| Scoped Database Access | Read-mostly, with queries reviewed with your database administrator first |
Access widens slowly: read-only through the first three delivery stages, tested against past cases, and write access only under supervision.
AutoServa runs on frontier cloud AI models or on a local AI server inside your own infrastructure. If data cannot leave your building, it can run on open-weight models on premises, air-gapped if required. Some clients split workflows between the two. Where a regulator requires data residency, it runs in-region in the cloud, or locally where in-region is not enough.
The model is chosen per workflow against six criteria: the reasoning depth the queue needs, how much long-document reading is involved, how fast the answer must arrive, where your policy allows data to go, cost per case at your volume, and how easily the model can later be replaced. Candidates are tested on your own documents first, and every deployment is built so the model can be swapped without rebuilding the decision framework, precedent library or evidence trail.
Before any action executes, the Workflow Guard checks six things: approval chains, spending ceilings, access scope, segregation of duties, retention rules and regulatory obligations. The operator never releases anything irreversible on its own judgement, and you keep an off switch that returns the queue to how it ran before.
Every decision carries its evidence: what was read, which rule applied, which threshold was crossed, which precedent it followed and who approved it.
| Option | Good At | Where AutoServa Differs |
|---|---|---|
| RPA and Rule Engines | High-volume, stable, zero-judgement data entry | Reasons from your decision framework and handles cases it has not seen in exactly that shape |
| Generic AI Assistants | Drafting, summarising and general questions | Tuned on your own material and acts inside your systems, not only in a chat window |
| Building In-House | Logic that is genuinely proprietary | Typically reaches a supervised live run in five to eight weeks, against six to twelve months commonly needed in-house |
These are not mutually exclusive. Keep the RPA that works; AutoServa often takes the exception queue a bot keeps failing on.
No. It is a consulting and delivery service. VYROX builds and runs the operator for your specific workflow.
RPA repeats a fixed script and breaks when a case does not match. AutoServa reasons from your decision framework and handles cases it has not seen in that exact shape. The two can work side by side.
No. Anything irreversible stays behind human approval.
No. It works inside your existing ERP, CRM, accounting, mail, document stores and browser-based portals, with no migration or rebuild.
No. The operator is tuned only on your material, stays inside your chosen boundary and is never pooled with another client's data or used to improve a shared model.
Yes, immediately, and your team controls the switch. Pausing the operator returns the queue to exactly how it ran before.
Only for a local deployment, when data cannot leave your premises. A cloud deployment needs no hardware.