> **In short.** Work that repeats week after week is handed to an agent once — after that it runs on its own. The sign that it is time: you are copying the same request into the chat for the second time. There are three ways to lock the work down, and the choice depends only on who decides **when** it happens: the calendar decides — a scheduled task; you decide — a task with a manual run; and a skill comes later, once the same method has to be copied into a third task. The fastest route is not to write an instruction from scratch but to do the work once together with the agent and say "do this every Monday". Below: what the text of a task is made of, five rules that save a week, and why a task that still needs you is not temperamental automation but an access you never granted.

## The sign: you are explaining it for the second time

A one-off request and a task look identical — the difference is how many times you say it out loud.

"Calculate last week's revenue by product and compare it with the week before" is a request. The same text, sent on the third Monday in a row, is already a task that you are performing by hand: you remember it, you phrase it, you wait for it.

Cognition, the team behind the Devin agent, put it this way: **every team has a quiet backlog of things that should happen on a schedule but keep slipping.** Weekly release notes, flag cleanup, a staging check — nothing urgent, which is exactly why none of it gets done. In a business the backlog looks different but works the same: stock reconciliation, chasing debtors, a review digest, an ad-spend report. None of it is on fire, right up to the day it burns.

A task is an assignment the agent carries out by itself, at the appointed time, without you. The result arrives wherever suits you: the chat, email, Telegram, MAX or Pachca.

## Three ways to lock down repeating work

| When it happens | What to use | What you say afterwards |
|---|---|---|
| By the calendar: every Monday, every morning, the 1st of the month | **Scheduled task** | Nothing. The result arrives on its own |
| It repeats, but you pick the moment: "when the month is closed", "when the export lands" | **Task with a manual run** | "Run the stock report" |
| The same method is needed by several tasks and by live chats | **Skill** | A single line inside the tasks: "follow the ‘Call review' skill" |

Almost all weekly routine is the first row. The second is for work that has a rhythm but not a calendar one: a month closes when it closes, a delivery arrives when it arrives. The third is the rarest, and there is no reason to start there (more on that below).

Templates on the Tasks page are not a fourth thing — they are the same tasks, already phrased for you. Starting from a template and adjusting it is faster than starting from a blank line.

## The fastest route is to repeat, not to write

The standard advice — "describe your process in detail" — runs into the fact that nobody wants to describe anything in detail. So the short route is a different one: **do the work once together with the agent, get the result you want, and say: do this every Monday at 10:00.**

Cognition calls this the most natural way to create a recurring task: the system carries over the context of the successful run instead of starting from zero. In practice it looks like this: you got the report you wanted with an ordinary request — and right there you ask for it to be put on a schedule. The wording is assembled from what just worked, rather than from your recollection of how it ought to work.

The agent will **ask about the cadence rather than guess it**. That is deliberate: a schedule nobody read back is a schedule nobody can tell apart from a broken one.

Which gives the practical rule for your first task: do not put it on a schedule straight away. Run it by hand, look at the result, fix the wording — and only then hand it to the calendar. A crooked assignment is cheaper to catch on the first run than on the fourth Monday.

## What the text of a task is made of

The text of a task is read by an agent that sees neither your chat nor you — only what is written. Hence six lines, in a working order: where to take it from → what to do → what to hand back.

1. **A specific source, not "the system".** Name the service and the account: "in Ozon, the ‘Main' account", "in MoySklad", "in amoCRM".
2. **Period and breakdown.** "For the past week", "Monday through Sunday", "by product", "by rep", "by warehouse". Relative periods, not dates: the task will live for a year.
3. **What to do — in steps, with thresholds.** "Compare with the previous week", "flag products down more than 20%", "mark stock below 14 days of sales". A threshold is what turns "check whether everything is fine" into work that can be verified.
4. **The output format.** "A short message, up to 10 lines", "an Excel table, one row per product", "a Word file". And what you do not want: "no general recommendations", "figures only".
5. **What to do when it is empty or the service does not answer.** "If nothing changed, send nothing", "if the account did not respond, say so in one line and do not invent numbers".
6. **Where to send it.** Chat, email, Telegram, MAX, Pachca.

### The same task, before and after

| Before | After |
|---|---|
| "Every Monday send me a sales report" | "Every Monday at 10:00 take Ozon, the ‘Main' account, for the past week: revenue and margin by product, a comparison with the previous week, and the ten worst decliners. Return it as a table, one row per product, plus five lines of conclusions in the message. If the account did not respond, say so and do not invent numbers. Send it to Telegram" |
| The report will arrive. Every Monday a different one: which account, which period and which shape are decided anew each time | There is nothing left to clarify — so there is nothing to ask about, and week-to-week results are comparable |

The left column is not "bad" — it is merely incomplete, and the agent honestly fills the gaps its own way. The right column costs one extra minute, once in the life of the task.

## Five rules that save a week

**One account, one task.** Two Ozon accounts and one Wildberries make three tasks, not one with a list inside. Each has its own run history, and a failing one does not drag the others down. There is no account binding in the task's settings — the account lives in the text of the assignment. So "Ozon, the ‘Main' account" has to be written there in words rather than implied: an unnamed account with two connections is either a question back to you or a choice made on your behalf.

**Name the task the way you say it out loud.** "Monday sales", "Overdue invoices". The name is how you will launch it by hand: "Run overdue invoices".

**Thresholds instead of "if something looks off".** Numbers, not feelings: "under 14 days of stock", "a drop of more than 20%", "more than 5 days overdue". Without a threshold the agent sends everything and leaves the decision to you — that is, hands back the very work you delegated.

**A watchdog has the right to stay silent.** A task that merely watches ("check prices", "watch stock levels") should write only when something changed. A daily "all good" stops being read in the second week, and the real "not good" sinks along with it.

**Access before the assignment, not during it.** The connector is linked, the key has its permissions, the account is chosen. A task that lacks access will not fail quietly — it will hand the question back to you, and you are in the loop again.

## Why a task still needs you

Delegating to people has a well-known disease — **reverse delegation**: the work comes back to whoever handed it over. Zapier's piece on delegation names the cause plainly: the person was not given the authority, the access and the information, so they have to ask. With an agent it is exactly the same, only there are fewer causes and every one of them is checkable:

- **the account is not named** — with two connections the agent is obliged to ask;
- **access is missing** — the key exists but lacks the right permission;
- **no rule for emptiness** — the agent cannot tell whether silence is success or failure, so it asks just in case;
- **no threshold** — the "important / not important" call stayed with you;
- **no format** — something different arrives each time, and each time you finish it by hand.

If a task has been demanding your attention for a second month, what needs fixing is not the schedule but one of those five lines.

## Tasks grow up through edits, not rewrites

A good recurring task is almost never born finished — it matures over a few runs.

A telling example is described on Anthropic's blog: a marketer automated a weekly personalized digest for every sales rep. Early versions invented URLs that did not exist — a rule was added never to make up links. The source kept changing its table structure — a rule was added to read the headers before processing. Events went to the wrong audience — an audience check was added. **Nine rules in total, collected from the feedback of the people who read the digest.**

The practical conclusion: when you get the wrong thing, do not rewrite the task from scratch. Open it, add the one missing line — a threshold, a breakdown, a format, a ban on inventing — and leave the rest. The run history is preserved, so you can see which run got better. A rewrite costs more and loses what already worked.

The same piece carries a good note on tone: **explain the task the way you would explain it to a colleague, not to a technical specialist.** "Every rep should see their three priorities on Monday morning" works better than trying to spell out the algorithm on the agent's behalf.

## When it is time to create a skill

A skill is a method kept apart from the occasion: "how we review calls", "how we answer a negative review", "the criteria we judge a supplier by". After that, all a task needs is a single line pointing at it.

The boundary is simple, and it matches the practice of agent platform builders: as long as the instruction fits inside the task's text, it is the task's text. A skill is for knowledge that is bulky, reusable, and outlives any single occasion. The working sign: **you are copying the same method into a third task in a row** — now it is a skill.

The reverse order — create a skill first, then look for somewhere to use it — nearly always produces a handsome document nobody opens.

## What is most often put on a schedule

- [A daily cash summary](/use-cases/daily-cash-report) — what came in, what went out, what does not add up;
- [weekly sales results](/use-cases/weekly-sales-digest) — what was done, the key figures, next week's plan;
- [overdue receivables](/use-cases/overdue-receivables) and [debtor reminders](/use-cases/debtor-reminders);
- [new negative reviews](/use-cases/negative-reviews-alert) — right away, not at the end of the month;
- stock levels, deliveries and warehouse reconciliation;
- emails and enquiries left unanswered;
- a digest of industry news and competitor moves.

They are all built the same way: a constant source, a constant breakdown, a constant format — and changing numbers. Which is precisely why they should be the first to go.

## Frequently asked questions

**How is a task different from an ordinary chat request?**
By the moment it runs. A request runs while you watch; a task runs at the appointed time without you, and the result arrives in the channel you chose. That is why the wording has to be fuller: there will be nobody to clarify things with mid-run.

**Do I need to know cron or configure anything?**
No. The schedule is set in plain words — "every Monday at 10:00", "every day at 9am", "on the 1st of each month". There is no form to fill in: a task is created by a line in the chat.

**What happens if the service does not answer or there is no data?**
Whatever you wrote in the fifth line of the assignment. If you wrote nothing, the agent decides for itself and will most likely report the problem honestly — but it is better said explicitly: "if Ozon did not respond, say so in one line", "if there are no new reviews, stay quiet".

**Can I change the wording of a task that is already running?**
Yes, at any point, and the accumulated run history is preserved. The next run follows the new wording.

**Where does the result arrive?**
In the chat, by email, in Telegram, MAX or Pachca — the channel is picked at creation and can be changed later. The messenger has to be connected.

**What if I need a lot of tasks?**
Create them one at a time, one account each. Three tasks of 20 lines behave more predictably than one of 60: each has its own history, its own channel and its own fate when something fails.

**How is this different from a scenario in Make, Zapier or n8n?**
A scenario runs a rigid if-then chain and breaks on any deviation. An agent's task is an assignment in words: the agent decides where to look and answers on the facts. A detailed comparison is in [AI agent or Make, Zapier, n8n](/resources/ii-agent-ili-make-zapier-n8n).

**Where do I start if there is a lot of routine?**
With the single most annoying piece of it. Everyone who has written about automating repetitive work repeats this advice, and it holds for a boring reason: the first task teaches you how to phrase things, and the second one takes five minutes.

---

**Last updated:** 2 September 2026.

**Sources:** [Cognition — Devin can now schedule Devins](https://cognition.com/blog/devin-can-now-schedule-devins); [Anthropic — Introducing routines in Claude Code](https://claude.com/blog/introducing-routines-in-claude-code); [Anthropic — how a field marketer sends weekly personalized updates to every sales rep](https://claude.com/blog/how-an-anthropic-field-marketer-uses-claude-code-to-send-weekly-personalized-updates-to-every-sales-rep); [Cline — How I stopped repeating myself to Cline](https://cline.bot/blog/how-i-stopped-repeating-myself-to-cline); [Zapier — How to delegate](https://zapier.com/blog/how-to-delegate/).