How to give a Claude agent a weekly job it can do without you

A weekly job is the easiest way to find out what an agent is good for. Once a week, without a reminder from you, it does one useful thing and leaves you a short report. This guide takes you from "I should automate that" to a job that runs on its own, in four steps: pick the job, write the brief, set the schedule, and decide what it may do without asking.

Pick a job that is worth a week

A good first job is one you already do by hand, on a rhythm, and dislike a little. It has a clear input, a clear result and a day nobody argues about. For example:

• Every Monday, read last week's support emails and list the questions that came up more than once.
• Every Friday, check every page of your website and list anything broken.
• Every Monday, put last week's numbers from two dashboards into one short summary.

Leave out jobs where a wrong answer costs money or reaches a customer before you see it. Those can come later, once you trust the routine.

Write the brief

The brief is a short file the agent reads every time the job runs. Claude Code reads a file called CLAUDE.md in the folder it starts in, so one folder per job, each with its own CLAUDE.md, keeps the jobs apart.

Keep it short. Five to fifteen lines do more than two pages. Say what the job is, where the input is, what the result looks like, where it goes, and what to do when something is unclear.

## Your weekly job: check the website
- Open every page listed in https://example.com/sitemap.xml.
- Check that the sign-up page loads and shows its form.
- List anything broken: the page, what you saw, what you expected.
- Write the report to reports/ with today's date as the file name, with a three-line summary at the top.
- Never change the site. If you are not sure something is broken, list it under "Check by hand".

The last line matters most. An agent working alone will meet a case the brief did not cover. Tell it what to do then, and the answer is almost always the same: write it down and leave it for you.

Set the schedule

On a Linux server the scheduler is already there. A cron line can start Claude Code in its non-interactive mode, in the job's folder, at the same time every week:

# Every Friday at 07:00: the weekly website check
0 7 * * 5  cd ~/jobs/weekly-site-check && claude -p "Do your weekly job, as CLAUDE.md describes." >> run.log 2>&1

claude -p runs one task and exits, so nothing stays open between weeks. The log keeps what it printed, so a run that failed leaves a trace. If cron can't find claude, use its full path, which which claude shows.

Pick a time when you will see the result soon after. A report that lands at 07:00 on Friday gets read with coffee. One that lands at 23:00 on Sunday gets read on Tuesday.

On HostNest you don't write this line yourself. Tell your main agent in Telegram what to run and when, and it sets up the job on its server, including a job that runs as one of your teammates.

Decide what it may do on its own

A job that runs while you are away can't stop and ask you. So decide its limits before the first run, and write them down in two places.

• In the brief: what it must never do, in plain words. "Never change the site." "Draft replies, never send them."
• In the command: the tools it may use. Claude Code's --allowedTools option lists what the job can do without asking, and leaves everything else out.

claude -p "Do your weekly job, as CLAUDE.md describes." --allowedTools "Read" "Write" "WebFetch"

Start narrower than you think you need. It is easy to add a tool after a few clean reports. It is hard to undo something a job did at 07:00 while you slept.

A first week to copy

• Monday: pick the job and write the brief. Run it once by hand with claude -p and read every line of the result.
• Tuesday: fix the brief where the result surprised you, and run it again.
• Wednesday: add the schedule, set to run ten minutes from now. Check that it ran and left both its report and its log.
• Thursday: set the real weekly time.
• Friday: the first real run. Read the report and the log, and change one line of the brief if you need to.

After the first few runs, read less: the summary at the top, and the full report only when something looks off.

When it goes wrong

A weekly job fails quietly. Nobody notices a report that never arrived. So make a missing report easy to see: the file name is the date it ran, and you look for this week's file every week. If it is missing, run.log usually says why, most often a login that expired or a path that moved.

When a report is wrong rather than missing, fix the brief, not the report. Next week's run starts from the brief, not from the corrections you made by hand.

Start with one job. When it has run cleanly for a month, give it a second one, or give the second job to a new agent with a brief of its own.