I Gave Claude Cowork One Real Job. Here's What Happened.

Published August 29, 2026

Editorial illustration of a robot arm assembling newspaper pages on a conveyor

Most demos of AI work agents show the same things: clean up a Downloads folder, summarize a PDF, draft an email. Useful, but safe. I wanted to know what happens when you hand an agent a job that ships to a public website, has hard format rules, and has a quality bar that fails loudly if you miss it.

So on August 28, 2026, I gave Claude Cowork exactly that: produce tomorrow's issue of my daily gaming-news page, end to end. Research the news, pick the stories, write the editorial, source an image for every single card, pass the validation scripts, regenerate the sitemap, and build the full site. One rule on top: touch nothing in version control — I review before anything ships.

It finished in 45 minutes. I spent about five of those minutes actually doing anything. What follows is the full timeline, the warts included, because the interesting part of this technology is not the highlight reel — it is where it needed help and what it did about it.

The Job: Produce Tomorrow's News Page

Before the timeline, you need to understand why this task is a fair test — because not all "real work" is equal.

I run a gaming site with a daily news page called Game Daily. Each issue is a single page with 10 to 15 story cards, a short summary, and an editorial section of 180-280 words that has to stake out an actual thesis, not just describe the news. Every card carries its source link and its own image, and the image rules are strict: capture the publisher's own hero image, and if a site blocks that, fall back to a branded source card. Full-page screenshots are banned. AI-generated images are banned.

That combination is what makes the task a good test:

It has a quality gate that does not negotiate. Validation scripts check every image against the rules. If something is wrong, the build fails. There is nowhere to hide a sloppy step.
It punishes laziness in research. The previous day's issue is already published. Re-running yesterday's stories is an instant fail, so the agent has to actively deduplicate against prior work.
It requires editorial judgment, not just summarization. The viewpoint section needs a point of view that connects a dozen separate stories.
It ends in a real deliverable. Not a draft in a chat window — a page that slots into a live website.

This was also a recurring job with an established format, which matters. A one-off task lets an agent improvise. A recurring one has a spec, and the spec was written down in a skill file: roughly 14 KB of instructions plus five reference documents covering structure, image-capture policy, categories, and SEO rules. If Cowork could absorb that spec and execute it, that would tell me something real about using it for ongoing production work.

The Setup: One Prompt, Two Minutes of Permissions

The setup took one prompt and a couple of permission approvals. The prompt stated the outcome, pointed at the skill file that governs the format, and added four hard rules on top of it: this issue is English-only; the editorial section must be 180-280 words; every card needs a properly sourced image; and no commits, no pushes — leave the finished files in the working folder for human review.

When a cloud session asks for folder access, the desktop app shows an approval dialog. I granted the project folder and Desktop. One request got refused — a hidden configuration folder that the folder picker would not grant — and I will come back to that, because how Cowork handled the refusal turned out to be one of the more telling moments of the run.

Total human effort to kick things off: one paragraph of prompt, three permission clicks. After that I was free to do something else, which is the entire point.

The Run, Minute by Minute

Cowork kept a timestamped log of its own work the whole way through, which is how I can reconstruct this accurately. Everything below comes from that log, cross-checked against what actually landed in the folder.

Claude Cowork working on the news page with a live preview visible

Minutes 0-6: Read the manual, find the catch

First move: it read the governing skill file and all five reference documents. Then it did something I did not expect — it checked its own instructions against reality and found a discrepancy. The skill copy it could reach was 10.7 KB; the real one I described was 14.4 KB. Instead of shrugging and proceeding with the stale version, it stopped and told me the file it could see was probably outdated.

It was right. I had two copies of the spec, and the older one was in the folder the cloud session could reach. Two minutes of fixing on my end — syncing the fresh copy to a folder the session could read — and the run continued. The hidden folder it could not get access to? No longer relevant: the synced copy made it unnecessary.

The lesson I did not expect to learn on day one: the agent auditing its own inputs beat me auditing them. I had been running on the stale copy without noticing.

Minutes 6-6.5: The research sprint

About six minutes in, the research phase completed: roughly two dozen web searches covering industry business, engines, platforms, VR, esports, regulation, and the big event recaps of the week.

Then the step that separates a diligent agent from a bull in a china shop: it pulled up yesterday's already-published issue and excluded every story that appeared in it — thirteen stories, including some big headlines it would have been tempting to reuse. What remained was 13 fresh candidates, each tagged by category.

And then it stopped. Not "stopped because it was stuck" — stopped because the workflow's own first checkpoint says: present the candidate list, get human approval before writing anything. That is the spec working as designed, and the agent honoring it without being reminded is exactly the behavior you want from something with write access to your website's folder.

One reply from me, then minutes 7-20: Writing day

I scanned the 13 candidates for about a minute and replied with a single line: approved, all of them; target 12 cards, keep the spares as backups in case image sourcing fails on any story.

Fourteen minutes later the full issue existed in the project folder: header, summary, a 257-word editorial under the headline "Everyone Quietly Walks Something Back" — a genuinely defensible thesis connecting the platform holders pulling back on multiplatform messaging, a debt-driven ownership change at a major publisher, and one engine maker betting in the opposite direction — plus 12 written cards, each with its source link.

One detail worth calling out: the candidate list had included a story about a rumored next engine version. Cowork dropped it on its own — stale after the week's bigger engine news — and swapped in a fresher, better-connected story about the Stop Killing Games campaign. That is an editor's judgment call, not a transcription service, and it was the right call.

Minutes 20-36: The image gauntlet

Images are where this workflow usually bleeds time, and where this run got interesting — first in a bad way, then in a good way.

The bad way: the site's own image-pipeline script needs a headless browser, and Cowork's cloud machine could not download one (network restrictions on large browser binaries). A lesser response would be to skip images, or worse, quietly generate placeholders. What the log shows instead is a decision note: it could not run the exact script in this environment, so it reimplemented the same fault-tolerant policy directly — fetch each source page, prefer the publisher's own hero image, apply the same rejection checks, and if everything fails, render a branded text card with the source's name and link. The note explicitly ruled out the two forbidden shortcuts: no full-page screenshots, no AI-generated images.

The good way is the outcome: 7 of 12 cards got real publisher images, pulled live and cropped to spec. The other 5 sources — Kotaku, Unreal Engine's site, GameSpot, GamesRadar+, Pure Xbox — threw bot-protection walls at the session, so those five cards got the compliant fallback cards instead. Every image landed in a manifest recording where it came from, how it was captured, and why any fallback happened.

Comparison of real captured publisher images and branded provenance fallback cards

Top: real hero images captured from publisher pages. Bottom: the compliant fallback cards used when a site's bot protection blocks automated capture. Both are allowed by the image policy; only the top row is preferred.

Minutes 36-45: Prove it, then stop

The last stretch was all verification, and this is the part I would copy into any agentic workflow:

Image validation passed — zero errors, five warnings, each warning being exactly the expected "this card used the fallback" note.
Metadata was curated, not just generated. The site's metadata script produced a title that truncated mid-word; Cowork noticed, kept the file the site actually uses, wrote the entry by hand within the length limits, and flagged the leftover scratch file for me to delete. That is judgment plus tidiness.
The sitemap regenerated — the new issue slotted in as report number 116.
The full site built — all 427 pages rendered, exit code zero. It then checked its own output directory to confirm the new page and the sitemap entry really existed in the build.
It verified it had obeyed the red line — confirming nothing was committed, and telling me the working folder was mine to review.

Final log entry, 45 minutes after start. Then it wrote its own self-check report: what was produced, what the validation said, and what was not done — the git step, deliberately.

Cowork's final self-check report listing produced files and validation results

What Cowork Did Well

It treated the spec as law. Every hard rule — English-only, word range, image policy, no commits — was still intact at the end. Nobody is impressed when an agent follows rules while you watch; this run happened while I was half-attending to something else, and the rules still held.

It stopped when it was supposed to stop. The approval gate before writing is the single most important checkpoint in this workflow, because everything downstream — an hour of writing and image work — builds on the story selection. It did not sail past the gate to be helpful. That restraint is rare and valuable.

It escalated with evidence instead of hiding problems. The stale skill file, the blocked browser download, the five bot-walled sources, even a library version it had to nudge to run in its environment — each one shows up in the log with what happened, what it did about it, and what side effects to check. The bot-walls meant 5 of 12 cards carry fallback cards instead of real photos. It did not bury that; the validation warnings and the final report both surface it.

It audited its own work product. Rejecting a truncated auto-generated title, verifying the build output actually contained the new page, confirming the platform binaries it touched did not break anything for my machine — these are small acts of skepticism that separate a colleague from a slot machine.

Where It Needed Help

An honest case study needs this section more than the last one.

The environment bit it twice. The cloud session could not mount a hidden configuration folder (the desktop picker refused it), and it could not download a headless browser. Both were environment limits, not reasoning failures — but they cost time, and the browser one forced the image-method substitution. If your workflow depends on specific local tooling, expect friction, and write your specs so there is a compliant fallback path.

Five of twelve images are the boring-but-legal option. Big gaming outlets run aggressive bot protection. The fallback cards are clean and policy-compliant, and they honestly disclose their source — but they are visibly less appealing than a real photo. A human with a normal browser can grab some of those images where the terms allow; the agent cannot. That gap is real.

It left two small messes. A scratch metadata file it used mid-run was left in place (flagged, but still there), and the library version bump it made for its own environment ended up in my project manifest — verified harmless, and flagged — but it is exactly the kind of side effect you should look for in any shared folder an agent writes into.

The desktop UI froze mid-run. For about ten minutes the window showed a stale "working" state while the files kept updating underneath. Cosmetic, self-corrected, and the run log never stopped — but if you monitor your agents by staring at the window rather than checking outputs, this will confuse you. Watch the artifacts, not the spinner.

The Verdict, With Numbers

Here is the same job, two ways. The "me alone" column is my honest estimate from having done this workflow by hand many times; the Cowork column is what the log actually shows.

Step	Me alone	With Cowork
Read the format spec and references	5 min	~6 min
Research + deduplicate vs. prior issues	40-60 min	~6 min
Human story approval	5-10 min	1 min (me)
Write 12 cards + editorial	60-90 min	~14 min
Source and process 12 images	30-45 min	~16 min
Validation, sitemap, full build	10-15 min	~9 min
Total	2.5-3.5 hours of my day	45 min, ~5 min of it mine

The compressed time is not even the headline. The headline is what the 45 minutes bought: a consistent issue. Every card sourced, every image policy-compliant, every gate passed, every deviation logged. On my best day, working alone, I skip the dedup pass when I am in a hurry. It does not.

Would I ship its output untouched? For this issue, yes after my five-minute review — and I have enough repetition with this format to say the review, not the production, is now the scarce resource. That is the actual change Cowork made to this workflow: it moved the human from the assembly line to the quality gate.

Should You Run a Real Job Through Cowork?

Do this if your work has: a written-down format, unambiguous quality gates (scripts, build steps, checklists), and a review point before anything ships publicly. Daily content, recurring reports, structured research digests, pipeline-driven publishing — these are the sweet spot, because the spec does the managing for you.

Think twice if your work is: mostly taste with no measurable bar, dependent on tools the cloud environment cannot reach, or requires logging into sites that block automation. The agent will be honest about these limits — but honest limits still limit.

And regardless: give it a red line. "Prepare everything, change nothing permanent without me" costs you nothing and buys you the ability to check the work before it matters. This run ended with a clean folder of finished files and a report — exactly what a review step needs.

How to Run Your Own Real-Job Test

Pick a recurring task with a quality gate. Something that fails loudly — a build, a validator, a checklist — not something where only taste can judge the result.
Write the spec down. If your format lives in your head, put it in a skill file or a reference document first. The agent can only honor what it can read.
State the outcome, the constraints, and the red line in one prompt. Outcome first, hard rules explicitly, and what must never happen (in my case: no commits).
Watch the checkpoints, not the whole run. Approve the plan-level choices (like story lists); let the execution happen; review the self-report at the end.
Verify independently before shipping. Run the gates yourself on the finished files. Trust the log, but confirm the artifacts — the same way you would with a new human hire.

Then come back and compare notes. If your real job produces a different failure mode than mine, that is exactly the data worth sharing.