AI work notes
Give a local worker a clear boundary before giving it work
What I learned from modular Jarvis design and local Qwen delegation: write the task contract first, then independently check what comes back.
Separate the whole loop
When building Jarvis, I separate wake-up, listening, reasoning, speaking, and execution. My approach is to get one part working before connecting the next. The time-consuming work is defining what each module receives and returns, rather than packing every tool into one long instruction.
Missing audio, an incorrect transcription, and an incorrect answer are different problems. I start with the smallest loop that hears one sentence and answers one sentence. Clear inputs, outputs, and failure signals make it easier to change the reasoning model while retaining other working parts.
Choose work with a checkable answer
Connecting a local model as a helper required the same thinking about responsibilities. File inventories, fixed-field conversions, and sourced summaries are easier to bound and check. I start with work I can rerun after failure and assess quickly.
On my first Qwen task, its response was detailed and convincing, but several claims did not match the source material. That showed me a successful connection is only the beginning. I keep ambiguous requirements, credentials, publishing, and hard-to-reverse operations within my own and the cloud reviewer’s judgment.
Write a short, explicit task packet
I then reduced the task packet to objective, essential context, readable and writable files, output format, acceptance method, and stop conditions. I provide only necessary material and ask for gaps to be reported rather than guessed away. Neither side should assume the other shares its conversation or permissions.
For a list, I might write: “Read only this directory. Return filename, path, and type. Do not read contents or change files. Reconcile the count with the actual inventory, list duplicates separately, and report inaccessible paths.” I can then review against the same packet instead of the confidence of the answer.
Check the result independently
My third gate is independent acceptance. I check scope first, then content and tests: diffs for code, sources for summaries, and counts for inventories. If it says a test passed, I look for execution results. Without a record, it remains unconfirmed.
The local worker makes a first version, the cloud reviewer and I check it, and I decide whether to accept, revise, or return it. After a failure I narrow scope or adjust verification. If it still does not match, I return to a verified workflow. These gates also make the review effort visible.
Account for the entire route
On 2026-07-25, I recorded almost fifteen thousand cloud tokens for delegation, task breakdown, and checking. My three-to-four-thousand figure for doing the work directly in the cloud was an estimate, not a matched comparison. This showed that delegation has a cost; it did not establish guaranteed savings.
Next I want to compare completion, returned work, waiting time, and actual usage across the same batch. I had not yet tested the end-to-end difference of letting the local worker read and write permitted files directly. I also check the data route: a local model or Jarvis component does not make speech, search, or transfer services offline.