An AI employee's first job: pulling seven dead links out of a release package

On October 23, Anthropic published the Claude Duet safety and privacy documentation, officially marked as a 12-minute read. Claude Duet is a proactive agent in research preview; it runs on a cloud computer, keeps working after you close the app, and can read the inbox, draft replies, and run routines. The most worthwhile part of the doc is how it is confined within boundaries.

Important actions stop first. Before sending sensitive messages, making payments, or deleting things, an approval card shows the action, destination, content, and every recipient. The approval card and independent checks sit outside the model; instructions hidden in a page cannot change the result. Actions such as securities trading, bank transfers, and accessing other people's accounts are not performed even if you approve them. Payments use single-use cards; the card number is not given to the agent or to the merchant.

Sensitive information has a separate classifier. Login credentials, full card numbers, and government ID numbers are classified as never share; health, financial, and similar information requires your explicit consent before it is sent. The official doc also acknowledges that during the research preview the classifier will miss some reports and also falsely flag harmless messages, so it is used together with the approval mechanism, and approval frequency is still being tuned.

Credential isolation is the quietest part of this design. Passwords are entered in forms inside the Claude app, encrypted with a single-use key that exists only on the secure cloud browser machine; the model cannot see it and cannot store it. Login tokens for connected apps do not go onto the agent's work machine; a proxy replaces placeholders when requests are sent. The browser runs in a separate virtual machine, and the agent can only send fixed commands: open page, click, type. Website code, cookies, and downloads stay on the browser machine; only page text and downloaded content come back.

The official doc talks about boundaries. To actually make the agent deliver, you also need a working framework. beamnxw broke this 12-minute doc into a harness guide: brief → context → tools → observations → verification → repair → delivery. Each segment must define what comes in and what must be returned; tool results, artifact paths, and errors must all be recorded; checkpoints are kept so unfinished work can resume; actual output is verified against acceptance checks; failures are sent only back to the failure point for focused repair; missing evidence is marked UNVERIFIED; finally, files, installation instructions, and check results are returned.

He also added five runtime decisions: if a tool reports an error, retry within a limited number of times; if a standard check fails, fix the faulty part and rerun the corresponding check; if evidence is missing, go get the evidence or report the verification gap; if input is missing, save progress and ask one precise question; if checks pass, return files and evidence, and the task is done. The example is concrete too: a CSV goes in and becomes a comparison board that can be searched, compared, annotated, and exported; then checks are run, and finally it is packed as a delivery package.

This sounds like process perfectionism. In real delivery, it is worth more than writing a few more pretty pages of documentation.

beamnxw assigned the first job to AI employee Viktor. motion→studio is his product film workflow; the harness ZIP contains 8 Markdown files and 4 supporting text files, 12 files in total. He sent 9 source files into Slack and asked Viktor to create a quick start, a handoff checklist, a reader explanation under 71 words, and a session report. The source files cannot be changed; new guidance is placed alongside them, and he reviews it before giving it to readers. The acceptance stop point is clear: return the files and wait for feedback.

Viktor confirmed the task in Slack and returned 4 drafts. The first checklist version was 43 lines. The problem also surfaced: 7 QA and provenance records referenced by the README were not among the received files. These records cover visual checks, package checks, and asset provenance. They originally existed in beamnxw's project but were simply not included in the sent package. For readers, those 7 references were 7 dead links; they would hit them before the first prompt.

beamnxw added the 7 records, designated LAUNCH-PROMPT.txt as the primary route, and demoted FULL-PROMPT.txt to an optional detailed reference. He required the reader explanation to be under 80 words and to make clear that the 16-second video is a promo and the 20-second product film is practice content that has not yet been run in a production session. Viktor returned 4 revised files, the reader explanation was 71 words, the checklist went from 43 lines to 47 lines, and all 7 added records were checked and accounted for. The 9 source files were untouched. The report retained two open items: inconsistent wording in the original README, and asset reuse permission had not yet been obtained.

In the tweet replies, someone summarized: catching seven dead links is the real QA. That judgment is not exaggerated. The most expensive errors in a release package are often not that there is not enough content, but that readers follow the map and find the road cut off. Generating a document is fast; proving that the document can be read, used, and that all references open is another kind of work.

There is a reusable judgment here: an agent's value is not only in generation, but also in checking, recording, repairing, and delivering evidence. Model capability is a variable; the harness is a multiplier. Only when you give it clear inputs, observable acceptance checks, and independent verification steps can it turn 'done' into 'here are the files, here are the check results, and here is the part not yet verified.' Otherwise, even a beautiful summary just packages the problem more presentably.

Claude Duet is still in research preview, and the safety doc acknowledges that some things will continue to change: approval frequency, login methods, and the accuracy of the sensitive-information classifier. Harness engineering is the same. Run it once, leave checkpoints and UNVERIFIED, then fix the failures. Next time you ask an agent to deliver, don't just accept a summary. Ask it to return files, acceptance check results, and an unverified list. Something like seven dead links is far cheaper to find in the first round than to have readers find for you.

Reference sources: Anthropic official documentation, beamnxw's post, his hands-on article, Viktor product page.