Himanshu Kumar 開發 VOX，協助處理 24 張支援工單

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

It's 11:52 on a Sunday night. The laptop is closed. Then the phone lights up.

Locked out after enabling SSO. "We enabled SSO this morning and the entire team is now locked out. Our launch starts in two hours."

Then another.

Production deploy fails with exit code 137. "Customers cannot access the new release."

Database connection pool exhausted. "The production service is returning intermittent 500 responses."

Invoice has a duplicate line item. "Could you explain the two line items before our finance team pays it?"

Twenty-four tickets in the queue. Four are on fire. The rest are "how do I rotate an API key?" and "where do I change the billing contact?". You tell yourself the line everyone in support has said at least once:

Bas do minute ka kaam hai. It's a two-minute job.

It never is. Reading 24 tickets, sorting them by deadline, finding the right playbook for each, tagging the urgent ones and writing two careful first replies is an hour of work, and none of it needs you. Only the last step does: deciding what actually gets sent.

A few small unfinished tasks can keep me from sleeping. So I built VOX: give it the queue, approve its plan, and come back to two decisions.

Kaam VOX karega. Faisla aap.
VOX does the work. You make the call.

The 2:25 walkthrough uses edited captures of the real hosted workflow and a local run, with AI-generated narration. Waiting time is trimmed; the receipts carry the measurements.

The pain nobody puts in the runbook

• The urgent ticket is buried. "Locked out, launch in two hours" sits between a pagination question and an invoice PDF request. Response deadlines aren't sorted for you.
• Context lives somewhere else. The fix for exit code 137 is in a playbook, the docs or last month's thread. Finding it takes longer than writing the reply.
• First drafts are the part we dread. Polite, specific, correct, and not promising a refund nobody approved.
• Agents are scary to walk away from. If the server restarts halfway, does it send the reply twice? Does it charge the provider twice? Most demos never turn the server off.
• "Valid JSON" isn't "right." A model can return a perfectly shaped plan that picks the wrong actions.

None of this is hard because of code. It's hard because it's tedious, and because nobody wants to trust a bot with the one step that matters.

What I built

Say or type one instruction:

Triage all support tickets, research fixes, tag urgent ones, and draft two replies. Ask me before sending anything.

Here's what VOX does with it.

01 The plan: nothing runs until you say yes

VOX turns the instruction into a bounded plan: inspect the queue, prioritize with evidence, find guidance, update internal labels, prepare reply drafts, prepare your briefing. Each step says whether it only reads, writes internal labels, or needs your approval. Execution starts only when you approve the plan.

02 The prep: the slow, boring part, done without you

VOX prioritizes all 24 tickets by response deadline and reported impact, pulls in guidance (checked-in playbooks locally, plus fresh web references when hosted), saves 7 internal labels and drafts 2 replies. Locally, on my MacBook Air M4, that takes 17.19 seconds (median of 10 runs).

03 The decisions: approve one, reject one

Each draft waits for your approve-or-reject. The server checks each reply's ownership, status and expiry, and rejects duplicate decisions. That's the whole human job: one plan approval and two reply decisions.

04 The briefing: what changed while you were away

The briefing counts every saved change and shows what still needs you. Evidence → Export JSON gives every saved action and provider receipt.

Then I turned the server off

With both replies still waiting, I turned the hosted server off.

When it came back, VOX picked up the same execution. Both replies were still waiting, and no finished provider request ran twice. That's the test I needed before trusting it with work I walk away from. Restart evidence.

The Lazy Payoff

On a MacBook Air M4 (16 GB), fully local:

The part I dread now takes about 17 seconds, and my job shrinks to three clicks plus reading two drafts. The app only talked to localhost during the run. Single-run receipt · Ten-run measurements.

Slow and steady, but the slow part is VOX's, not mine.

Demo

Open the judge workspace. No account or API key needed.

1. Choose Start live evaluation, or Start rules-only demo if no live pass is free.
2. Choose Full workflow and keep or edit the instruction. Live mode also takes voice.
3. Select Create a plan, check its scope, then Approve & start run. When the replies are ready, approve one and reject the other.
4. Read the updated briefing, then open Evidence → Export JSON.

The October 21 hosted run went from a recorded voice command to 24 triages, 7 labels, 2 drafts, 1 simulated send and 1 rejection, with 16 successful receipts across nine providers. On October 23 I ran the deployed journey again on desktop and a 390px phone layout: it finished with zero pending approvals and survived a reload. Hosted receipt.

Code

github.com/himanshu748/vox-zero-touch-os · MIT licensed, started October 20. With Node.js 22.18+, Ollama and the Temporal CLI installed:

git clone https://github.com/himanshu748/vox-zero-touch-os.git
cd vox-zero-touch-os
npm ci
ollama pull gemma3:4b
VOX_MODEL_MODE=local npm run dev

Open http://127.0.0.1:4320/app. VOX starts a loopback-only Temporal dev server and keeps local data apart from the hosted workspace. Full local setup · Judge guide.

Why Does Open Innovation Matter?

Support tickets are private. They hold customer names, outages and invoices. With VOX_MODEL_MODE=local, Gemma 3 4B handles intent, planning and reply drafting through Ollama, while deterministic rules set SLA priority. The same server-side approval checks apply. Cloud integrations leave explicit "skipped in local mode" receipts, and VOX never quietly switches to cloud inference when a local request fails. Tickets stay on the machine.

Open weights let me shape a model to one narrow job. With Tinker, I trained a rank-8 Qwen3-8B LoRA on 53 synthetic examples for hosted intent extraction:

Accuracy went up and tokens went down; it's slower, which is the tradeoff to tune next. A closed API wouldn't let me do either: run it offline, or retrain it for my one command format. Training receipt.

Trust doesn't depend on the model being perfect. VOX's model can propose a reply; it can't grant permission to send it. Permission lives in the executor, not the prompt.

How I Built It

The model proposes. The server decides.

The Vercel AI SDK streams structured output into fixed React action cards. Partial output can't execute anything, and the model never writes tool code. The server checks each reply's ownership, status and expiry, and rejects duplicate decisions.

Every sponsor in VOX, and exactly what it does

All the evidence tools feed preparation; none of them can approve a reply.

Ultramarine caught a real gap. It adds a second reviewer through the official OpenAI Node SDK. In the verified run it flagged a draft that ignored the customer's intermittent 500 errors and their request for a root cause. Two reviews cost $0.00034095 in credit, matching 1,313 input and 288 output tokens. Cost reconciliation.

Sentry showed exactly what broke. When a hosted Gemma call failed, the trace pointed at the span, and recovery reused the completed work instead of falling back to a template.

The parts that fought back

• Gemma returned perfect JSON with the wrong plan. Valid output in 30/30 planner cases, but exactly the requested actions in only 11/30. One prompt change got it to 19/30. That's why the plan always stays visible for approval. Planner evaluation.
• A server can die at the worst moment: after a provider finishes, before the result is saved. So VOX writes a reservation before every provider call. The guard in server/provider-task.mjs is small:

const saved = current()?.providerTasks?.[key];
if (saved?.status === "completed") return saved.result;
if (saved)
  throw new Error(
    "This provider request already started without a saved result. Automatic replay is blocked.",
  );

A finished request reuses its saved result. An uncertain one stops and asks for a human instead of risking a duplicate charge. Implementation.

• Polling ate itself. Each poll cancelled the one before it, so a slow server could leave the workspace spinning forever. Polling now waits for each response to settle, and the UI loads even with every response delayed 2.1 seconds.
• The evidence export lied. It said two replies were waiting after both were decided. It now rebuilds counts from saved work and asks Temporal for live status. PR #8 · PR #9 · PR #10.
• The fine-tune got smarter and slower. 16/16 intents, but 7,870 ms median versus 2,385 ms. Still to tune.

The deployed release, 2202631, passed 68 tests, typecheck and the production build, and getvox.tech serves byte-for-byte the build CI tested. Release CI.

My Agent Session

GitHub Copilot CLI reviewed the research module: review transcript · usage receipt. Entire captured the development session: checkpoint · session export.

Limits and what's next

All 24 tickets and identities are fictional, and sends are simulated; VOX isn't connected to a real inbox yet.

• One read-only helpdesk connector, so VOX reads a real queue without being able to change it.
• A small consented pilot with a real support team.
• A faster adapter, keeping the 16/16 accuracy without the extra latency.

Prize Categories

I'm entering 18 categories.

The integration ledger records each integration's scope.

Every support queue will wake you up sooner or later. VOX just makes sure the only thing waiting for you is the decision.

Kaam VOX karega. Faisla aap.
VOX does the work. You make the call.

VOX and this article were built with AI coding and writing help. The video uses AI-generated Deepgram narration over real browser captures. Asset provenance.