VOX: I asked for two support replies. Then I turned the server off.

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

What I Built

Give VOX the queue. Approve the plan. Come back to two decisions.

I built VOX because a few small unfinished tasks can keep me from sleeping. I wanted to delegate the preparation, know what had finished, and return when something needed my judgment.

Support is the first working workflow. Give VOX this instruction by voice or text:

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

It proposes a plan. After approval, VOX prioritizes the queue, retrieves guidance, saves internal labels and prepares two replies. Each reply waits for its own approve-or-reject decision. The human work is concentrated at three gates: one plan approval and two reply decisions.

Then I stopped the hosted server with both replies waiting.

When it came back, VOX resumed the same execution. The replies were still waiting, and completed provider requests were not repeated. That was the test I needed before calling this work I could step away from. Restart evidence.

The public preview uses 24 fictional tickets and simulated sends. It has no connection to a customer inbox. Its model requests, saved workspace changes and workflow history are real.

Try VOX · Source code · Judge guide

Why Does Open Innovation Matter?

Open weights let me run the core workflow on my own machine and adapt one model to a narrower job.

With VOX_MODEL_MODE=local, Gemma 3 4B handles intent normalization, planning and reply drafting through Ollama and the Vercel AI SDK. Deterministic rules calculate SLA priority; the model does the language work. The same server-side approval checks still apply.

Local research uses checked-in playbooks. External search, voice, browser automation and the other cloud integrations leave explicit “skipped in local mode” receipts. VOX does not load its hosted credentials or silently switch to cloud inference when a local request fails. Local implementation and setup.

I also used Tinker to train a Qwen3-8B LoRA for hosted intent extraction: 53 synthetic training examples, a rank-8 adapter and 12 epochs. On 16 held-out commands:

The adapter improved this small test and used fewer output tokens. It also took more than three times as long. That tradeoff belongs next to the accuracy result. This is a narrow intent experiment, separate from the local Gemma planner evaluation below. Training and evaluation receipt.

The cloud path makes the connected workflow available from a browser without asking each evaluator to install models or provide API keys. The local path lets a developer inspect and run the core with their own model. Both stop at the same human gates.

The Lazy Payoff

On a MacBook Air M4 with 16 GB of memory, the local Gemma workflow produced:

Preparation includes intent normalization, planning and work up to the two pending drafts. Application startup and human reading, corrections and decisions are excluded. The ten-run report uses nearest-rank percentiles; with ten samples, its p95 is the slowest observed run.

In the initially unloaded run, understanding and planning took 20.99 seconds and drafting took 3.86 seconds. The application recorded only loopback HTTP destinations. This measures VOX's application requests, not all traffic on the computer.

Single-run receipt · Ten-run measurements

One local draft was generic and needed editing. I have measured preparation, not total human time saved. The demonstrated payoff is a prepared queue and two reviewable replies waiting together; the full benefit still depends on the work needed to correct them.

Demo

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

Open the judge workspace. No account or API key is required.

1. Choose Start live evaluation for the connected AI workflow, or Try rules-only demo to explore without reserving a live pass. The page shows current availability.
2. In live mode, say, upload or type the instruction above. In rules-only mode, type it. Use fictional inputs only.
3. Read and approve the plan. Inspect both replies, approve one and reject the other.
4. Open the briefing and Evidence export to inspect the saved actions and provider receipts.

A live pass lasts 24 hours. Within an active pass, plans, voice uploads and briefings can be repeated, subject to provider quotas. The shared pool remains capped at eight passes. An expired pass retains saved work; use Switch to rules-only demo to continue exploring without providers. If no new passes remain, use Try rules-only demo.

The October 21 hosted verification used a recorded voice file, public HTTP endpoints and scripted decisions. It completed 24 triages, 7 labels, 2 drafts, 1 simulated send and 1 rejection, with 16 successful receipts across nine providers. Mastra succeeded and Temporal completed with 21 events. Replaying the briefing returned identical cached audio without another generation.

That provider test ran on commit 22fcfa4; browser checks were separate. It establishes the recorded-audio pipeline, not a physical microphone or speaker test. Full hosted receipt and method.

On October 22, I rechecked the deployed browser journey in the rules-only demo. A saved plan survived reload; after approval, VOX triaged 24 tickets and prepared two template replies. I approved one simulated send and rejected the other. Both decisions persisted, with zero pending approvals, Mastra success and Temporal COMPLETED. No new labels were needed because the earlier labels were retained.

The downloaded evidence agreed with the on-screen briefing. Existing provider receipts stayed at 16, with none added by this run. Three live passes remained before and after the check. This recheck used no live pass or new model, search, browser-automation or voice-provider request. The live-provider proof above remains a separate October 21 observation.

How I Built It

A valid plan still needs a human

The Vercel AI SDK streams structured output into fixed React action cards. Partial output cannot execute work, and the model never supplies executable tool code. The server checks reply ownership, status and expiry, and rejects duplicate decisions.

Local Gemma produced valid JSON in 30/30 cases, but selected the exact requested actions in 19/30. A prompt change improved that action score from 11/30 on the same fixed regression set. Valid structure clearly did not establish correct interpretation. The plan remains visible for approval. Planner evaluation.

My earlier projects, ToolTrap and EmbodiWeave, led me to put permission checks in the executor. VOX's model can propose a reply; it cannot grant permission to send it.

Recovery needs a record of the request

Mastra coordinates named steps and pauses for review. Temporal preserves hosted execution across restarts. VOX adds a reservation before a provider request because a server can die after the provider finishes but before the result is saved.

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.",
  );

VOX persists the reservation before calling the provider and the result before moving on. A completed request reuses its saved result. An uncertain request stops for intervention. This sacrifices automatic recovery in an ambiguous case rather than risking a duplicate billable effect; it provides no general exactly-once guarantee for external APIs. Implementation.

The restart test exercised completed-result reuse. The two pending decisions and the completed request records survived in the same execution.

Fixing the retry that looked like broken voice

An earlier judge session allowed only one voice upload. After it was used, the interface could show “This live pass has used its voice upload,” preventing another attempt.

The current release removes per-pass ceilings for plans, transcription and briefings. Usage counters, pass expiry, provider reservations, per-run bounds and reply approvals remain. A new intentional request and automatic replay of an uncertain request are handled separately.

The regression check exercised an injected transcription success, a deliberate failure and a successful recovery, plus reload, keyboard controls and a 390px layout. It made zero external HTTP attempts. Those are local regression results, separate from the real hosted provider test. Regression evidence.

Slow responses must still reach the screen

The final judge check found a loading bug: each 1.5-second poll invalidated the previous request. If every response took longer, the workspace could keep spinning while successful responses arrived. Polling now schedules its next request after the current one settles. The rebuilt UI loaded with every state response delayed by 2.1 seconds, including at a 390px mobile width.

The evidence export had a separate error: its saved briefing could still say two replies awaited approval after both decisions were made. The export now recomputes the current briefing and counts from the saved work, and asks Temporal for its current status. If that lookup fails, it marks the current status unknown. The original timeline event keeps the briefing as it was before the decisions.

Both fixes are deployed in release 98f721d. 65 tests, typecheck and the production build passed. Regression coverage checks slow responses, retry cleanup, both reply decisions, and unavailable Temporal status. Merged fix and implementation · Release CI.

Retrieval and a second reviewer provide evidence to inspect

Tiger Data combines vector and full-text retrieval; SerpApi retrieves fresh references. Backboard supplies reply-style memory, TabPFN estimates escalation risk, and Browserbase's Stagehand files a bounded internal note. These outputs support preparation; none authorizes a reply.

An earlier search returned irrelevant material and the resulting draft was rejected. A Gemma internal error also stopped a hosted attempt. Sentry exposed the failing span; explicit recovery reused completed work instead of substituting a template.

Ultramarine adds an advisory review through the official OpenAI Node SDK. In the verified run it flagged a specific omission: a draft had not addressed the customer's intermittent 500 responses and request for root-cause confirmation. I still had to judge that criticism and the reply.

Its first SDK response failed VOX's review contract. I sent the same strict schema used by server validation, kept automatic SDK retries off and verified a new run. Validation stayed in place.

The two successful reviews consumed $0.00034095 in settled promotional credit. The provider's usage deltas matched two requests, 1,313 input tokens and 288 output tokens. The rejected attempt consumed another $0.00020585. These are measured review charges, not the full workflow price; no purchase or top-up was made. Cost reconciliation · Rejected attempt.

Code

github.com/himanshu748/vox-zero-touch-os · MIT license · Started October 20

Install Node.js 22.18+, Ollama and the Temporal CLI first. On macOS, Temporal is available through brew install temporal. Then:

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 development server and keeps local data separate from the hosted workspace. That server is for development. Full setup and model constraints.

My Agent Session

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

For related engineering approaches, see NextCTL's Building an AI Agent with Human Approval Gates and kongkong's Put AI Agent Actions Behind an Approval Gate From API to Worker. These are further reading, separate from VOX's implementation evidence.

Prize Categories

I am entering 18 categories: 15 runtime or infrastructure integrations, two development tools and the domain.

• Best Use of Temporal: the same execution and pending approvals survive a restart.
• Best Use of Tinker: Qwen3-8B LoRA improves a 16-command test from 12/16 to 16/16, with slower latency disclosed.
• Best Use of Mastra: named steps suspend and resume around individual reply decisions.
• Best Use of Gemma: real local intent, planning and drafting on the M4 laptop, plus hosted inference.

Other 14 entries: what each does and where to verify it

The integration ledger records each integration's scope. DigitalOcean and Arduino are excluded.

What comes next

VOX is a working prototype with no customer users or revenue. The next product step is one read-only helpdesk connector and a consented pilot to test draft usefulness, correction work and repeat use.

The local Qwen fallback and llama.cpp path remain transport-tested rather than verified with real inference. Production accuracy, total multi-provider cost and continuous uptime are unproven. Free hosting can sleep, and provider quotas and resource expiry still apply.

AI disclosure and credits

VOX and this article were built with AI coding and writing assistance. The walkthrough uses AI-generated Deepgram narration over edited real browser captures; in-app voice uses ElevenLabs. All tickets and identities are synthetic. ToolTrap and EmbodiWeave are earlier projects; VOX is new for this challenge. Asset provenance.