Anthropic's Claude Co-work Is the Safer OpenClaw You Can Actually Use

The agency tracked every hour it spent on one client's monthly reporting, the kind of documentation task that everyone on the team knew was expensive and nobody had quantified until someone actually did. The number was twelve hours per month: pulling exports, renaming files, routing them to the right folders, formatting the summary, and confirming everything was in the right place before the client call. Twelve hours of work that required no judgment, no creativity, and no skill that took years to develop.

Chapter One: The Repetitive Task That Was Costing the Agency More Than Anyone Had Calculated

The monthly reporting task had expanded gradually over three years. It started as a two-hour process when the agency had four clients. As the client list grew to eleven, the process had grown to twelve hours without anyone making a deliberate decision to add that time. It just accumulated, each new client bringing its own variation of the same underlying structure: download the exports from four platforms, rename each file to the agency's naming convention, sort them into the correct client folder, pull the key metrics into a summary template, and confirm that all eleven client folders were in the expected state before the first of the month reporting calls began.

Nobody on the team enjoyed this task. It was not the kind of work that built skills or relationships. It was the kind of work that produced errors when done quickly and produced delays when done carefully. Two months before the computer-use experiment, a file had been sorted into the wrong client folder, the error had not been caught before the call, and the resulting thirty minutes of confusion in front of the client had been the most embarrassing moment of that quarter. The agency had no automated checks. The process depended entirely on the person doing it being careful every single time. That dependency was a problem with one clean solution: remove the person from the mechanical steps entirely and keep them only for the review that required judgment.

The lead project manager ran a rough calculation before proposing the experiment. Twelve hours per month on one task, across a team where everyone's billable time had a real opportunity cost, was roughly the equivalent of one and a half full project days every month spent on filing. That number, made explicit and set next to what those hours could produce in actual client strategy work, was the business case. The experiment did not need to save all twelve hours to justify itself. Saving half would return three quarters of a day per month in capacity, compounding as long as the agent ran. The backup habit was the safety requirement before the experiment could begin, not a nice-to-have added afterward.

Chapter Two: The First Week With a Computer-Use Agent

The team chose Claude Co-work as the first computer-use agent to test, because the access model felt manageable from a safety standpoint. The agent was given access to one folder only: the client deliverables intake directory where raw exports landed after download. Nothing outside that directory was in scope. The agent could read, rename, and move files within that directory. It could not access email, browser, billing records, or any other system. The scope was a single folder.

The instructions were written specifically rather than vaguely. Each file naming convention was described with an example: ClientCode-Platform-ReportType-YYYY-MM.csv, with the acceptable values for each field listed explicitly alongside the instruction. The sorting logic was described as a rule set: if the ClientCode matches one of the eleven listed values and the Platform matches one of the six listed values, move the file to the path matching ClientCode-slash-monthly-slash-year. Any file not matching these rules should be placed in a review queue rather than sorted.

Before the agent's first real run, the team made a full backup of the intake folder. This was treated as the prerequisite for the experiment, not an optional precaution. The agent then ran on a test set of twenty-two files covering every standard case and five deliberate edge cases. Nineteen of the twenty-two were handled correctly. Two were flagged correctly because the file names did not match any client code in the list. One was sorted to the wrong client folder because the file name contained an abbreviation the instruction set had not explicitly covered.

The error rate on the first test run was approximately five percent. At real monthly volume of roughly three hundred files across all clients, five percent would mean fifteen misfiled documents per month. That was not acceptable for a production reporting process. The team did not treat this as a failure. They treated it as the data needed to improve the instructions before moving to real files.

Chapter Three: The Failure Mode That Almost Ended the Experiment

The adjustment period between the first test and the second was two weeks of instruction refinement. The team added explicit handling for every edge case the first run had encountered: every known file name abbreviation, every platform naming variation, every client code format they had used across three years of client history. The second test produced zero errors across forty files, and the team felt confident enough to run the agent on a partial set of real files for the first time.

This is where the failure mode emerged. On the third day of the partial real-file run, the agent encountered a file type it had not been instructed about: a PDF summary report that one platform had begun generating that quarter alongside the usual CSV exports. The instruction set did not mention PDF files. The agent, following its instructions exactly, sorted the PDF into a folder based on a partial match to the file name pattern rather than flagging it. The file landed in a folder belonging to a different client.

The error was caught during the daily spot-check review, not by the client, and the file was moved immediately. But it revealed a pattern the team had not fully anticipated: the agent was not failing when the instructions were wrong. It was failing when a new input type appeared that the instructions had not covered. The instruction set had described what to do with every file type the team knew about at the time of writing. The agent had no mechanism to recognize that an unknown file type was something to flag rather than attempt to process by partial match.

The lead on the project considered ending the experiment here. A tool that fails unpredictably on new inputs was not safe to run on real client data without constant supervision. If constant supervision was required, the efficiency case collapsed. One more adjustment was worth attempting before concluding the experiment had failed.

Chapter Four: The Adjustment That Made It Work

The adjustment was a single addition to the instruction set: a default rule covering every file type not explicitly mentioned in the instructions. Any file whose format was not specifically described should be moved to a review queue rather than sorted by partial match. Unknown inputs become flagged items, not items to process with partial logic.

This one change resolved the underlying failure mode. The agent no longer attempted to apply partial pattern matching to inputs it had not been told how to handle. Any new file type, any unusual naming pattern, any input that did not match a defined rule landed in a review queue that a person checked each morning. The review queue was typically empty or contained one to two items on any given day. When something appeared, the review took two to three minutes and the outcome was either a correction to the instruction set for recurring cases or a one-time manual sort for anomalies.

The second adjustment was to the backup schedule. Instead of a single backup taken before the experiment began, the team implemented an automatic nightly backup of the entire client deliverables directory to a separate location. The backup ran overnight before the agent's morning processing cycle. This meant the maximum exposure from any single agent error was one day of work in the review folder, recoverable from the previous night's backup. With that safety condition in place, the team was comfortable enough to expand the agent's running time to cover the full monthly reporting cycle without manual oversight at each step.

Month two's monthly reporting cycle was the first time the process ran without a team member actively watching each file move. The agent processed two hundred and eighty-seven files over four days, sorted all of them correctly, and flagged fourteen files for the review queue: eleven new file types from a platform that had changed its export format, and three files with unusual naming from a new client added that month. The fourteen flagged files were reviewed in about thirty minutes spread across four days. Total human time on the monthly reporting process for month two: forty-five minutes.

Chapter Five: The Monthly Time Audit After Thirty Days

At the end of the first full production month, the agency ran a formal time audit across every task the computer-use agent was handling. Three categories were included: the monthly reporting process, a weekly file organization task added to the agent's schedule in week three, and the daily intake review that replaced the previous manual morning check.

Monthly reporting time: down from twelve hours to forty-five minutes per month. The weekly file organization task, previously taking about two hours per week across two people, dropped to a fifteen-minute weekly review of the agent's sorted output. The daily intake review, previously taking about thirty minutes each morning to manually confirm the previous day's files were in the right place, dropped to a two-minute check of the review queue.

Total monthly time on these three categories before the agent: approximately twenty-two hours. Total monthly time after thirty days of production operation: approximately three hours. Nineteen hours per month recovered from file management work and redirected to client strategy, account development, and the kind of proactive communication that differentiates good agencies from adequate ones.

The error rate in month two, measured across all files processed: zero misfiled documents in the sorted categories. Fourteen correctly flagged files handled through the review queue. The backup had not needed to be used. The agent had not required supervision beyond the morning queue check.

Two lessons from the experiment applied beyond this specific use case. First, the failure mode was always at the boundary of the instruction set, not within it. The agent was reliable on inputs it had been explicitly told how to handle and unreliable on inputs that fell outside the described cases. Writing tight, complete instructions was the real work of the experiment. The agent's underlying capability was not the constraint. The quality of the human thinking that went into the instruction set determined the quality of the results. Second, the backup was not a precaution that happened to be unnecessary. It was the safety condition that made the experiment possible at all. Without it, the risk of running an agent on real client data was unacceptable. With it, the maximum downside of any error was one recoverable day. That framing made the decision to proceed straightforward and made the experiment worth attempting in the first place.

What the agency would do differently on the next computer-use experiment

Looking back at the full thirty days, the team identified three things they would do differently on the next experiment. First, write the default-rule for unknown inputs before the first test run, not after the first failure. The failure that almost ended the experiment was entirely predictable from the structure of the instruction set: any set of rules that covers known cases but provides no default for unknown cases will eventually encounter an unknown case and behave unpredictably. The default rule should be the first line of any instruction set, written before any specific case rules, not the last thing added after a problem surfaces.

Second, build the nightly backup automation before the first test run, not before the first production run. The team built it before moving to real files, which was the right timing, but the right timing would have been before the test files too. A backup that covers only production runs misses the learning period when most errors actually occur. Third, define what constitutes a successful month before starting, so the decision about whether to expand the experiment's scope is based on a pre-agreed standard rather than judgment made after seeing results. The standard the team used, zero misfiled documents in sorted categories plus a manageable review queue, was the right standard. Having it written down before the first run would have made the decision faster and the communication of results to the rest of the team cleaner.

These adjustments are small and obvious in retrospect. They are the kind of things that only become obvious after running the experiment once, which is precisely why running the experiment is worth the setup cost even when the first run is imperfect.