Routines and agents: from “let me ask” to “it just runs”

Most people work with AI in question-and-answer mode. You remember, you open a window, you type, you get a reply, you close it. It's useful, and it's also a ceiling you'll eventually hit: everything only happens when you remember to make it happen. In the week you're swamped, you won't remember even once — and that's exactly the week you'd need the help most.

A routine breaks through that ceiling. You describe the work once, and from then on it does itself, at a time you set, or the moment an event you tied it to occurs. At seven in the morning, email is sorted and draft replies are waiting in a folder. At five on Friday, an email is sitting there with a summary of what moved this week and who you promised what. After every meeting, action items get pulled out of the notes on their own. You're not launching anything. You're approving.

The overview chapter AI and automation shows four such routines, ready-made and ready to build. This chapter is about what has to shift in your head before you build them, and what to do so they don't end up, a month later, like most automations in companies — quietly switched off because “it didn't work.” The key idea: a routine isn't a setting you flip on once. It's a small operation with an owner, a break-in period, and a date when it gets reassessed.

Where asking ends and operating begins

The difference between a conversation and a routine isn't technological — it's about who owns the initiative. In a conversation, you hold it: nothing happens until you start. In a routine, the system takes it over, and your role shifts to the end of the process.

This shift has a consequence that catches people off guard. When you remember to ask AI something, the result is always relevant — you were responding to a real need in the moment. A routine, by contrast, runs even on days when nothing interesting happened, and produces a summary where there's nothing interesting in it. That's not a malfunction — it's the price of reliability. Unreliable help that only shows up when you remember to ask for it is worse than regular help that's sometimes empty — because you never learn to trust the first kind enough to stop thinking about it.

The second consequence is psychological, and it decides whether you'll switch the routine off within a month. You stop being the author and become the editor. Editing someone else's draft is a different kind of work than writing: faster, but less satisfying, because it's missing the pleasant feeling that the whole thing came out of your own head. Anyone who doesn't admit this to themselves starts rewriting the routine's drafts from the ground up, burns more time than before, and concludes that the automation doesn't work. It worked. You were just using it as a template to rewrite instead of a finished draft to approve.

Routine vs. agent: where the line is

The two words get used interchangeably, and yet there's a difference between them with practical consequences for how much oversight you need.

A routine is a prescribed procedure. You set the steps: take the emails from the last twenty-four hours, sort them into these three categories by these rules, and for the “needs a reply” category, draft a response, and save the result in this folder. The model still makes decisions inside each step — exactly how the draft will read — but the sequence is yours, and it's the same every time. That's exactly why a routine behaves predictably, and why its mistakes are reproducible, and therefore fixable.

An agent gets a goal, not a procedure. “Prepare briefing materials for tomorrow's meeting with this client.” The agent decides on its own to check email, dig up older notes, check whether there are unpaid invoices, and depending on what it finds, decides where to look next. The path is different every time, because it depends on what it found along the way.

So the line falls in exactly one place: who decides what the next step is. Everything else follows from that. You can run a routine a thousand times and treat it like an assembly line — tune it once, and it runs. You run an agent on tasks where you need that variability, and you pay for it by having to evaluate the result every single time, not just at the start.

In practice, the two get combined most often: a routine is the clockwork, and an agent is a step inside it that gets given some latitude. “Kick off every Friday at 4pm, and then figure out on your own what changed across the projects.” The tips Routines in Claude and MCP connectors show the practical shape of both — without connectors, a routine has nowhere to reach for data.

Designing a routine: four questions

Before you set anything up, answer four questions. If you can't answer any one of them in a single sentence, the routine isn't actually finished in your head yet — and what isn't finished in your head has no business being set up in a tool.

Trigger. A time-based trigger is more predictable and easier to tune; an event-based one is more responsive, but can flood you. Start with time-based, and prefer once a day over once an hour — a routine that runs often is harder to observe, and mistakes hide inside it more easily.

Inputs. This is where the safety of the whole thing gets decided. The principle of least privilege applies: access only where it's genuinely needed, a folder rather than the whole drive, read-only wherever possible. This isn't paranoia — access scope tends to accumulate over time, and a year in, nobody remembers everything the routine can see. The chapter AI, ethically and safely covers the surrounding data considerations.

Output. One artifact, not three. A routine that drafts replies, creates tasks, and also sends a summary is hard to tune, because when something breaks, you don't know which part failed. And above all: the output has to land somewhere you already are. A summary that requires opening yet another tool won't get opened three weeks from now.

Approver. The most commonly skipped question. A routine with no named person and no defined moment when the result gets looked at is a generator of unread files. For personal routines the answer is trivial, but even there, a moment has to exist in your daily rhythm when approving actually happens. On a team, the approver has to be named — “whoever has time will look at it” means nobody will.

What an agent may decide alone, and what it never may

The principle “AI proposes, a person approves” is easy to say and harder to apply, because in a specific situation it isn't obvious exactly where to draw the line. A simple decision framework built on two questions helps: is the action reversible, and is it visible to someone outside?

What an agent can do alone, without asking, are actions that are reversible and invisible externally. Reading — email, documents, calendar, systems. Sorting and labeling — tags, categories, priorities. Searching and gathering — research, tracking down context, collecting source material. Preparing — drafts, proposed notes, spreadsheets, summaries, outlines. Flagging — that something's missing, that a deadline is approaching, that two things don't match. All of this you can delete at any time, and nothing happened to anyone.

What an agent must never do alone are actions that are irreversible, or that act on your behalf. Sending — emails, messages, anything that leaves your organization. Paying and ordering. Deleting — data, files, records. Signing and committing — confirming dates, accepting orders, making promises. And one extra category that doesn't fit either criterion above and is still off-limits: evaluating people. Deciding on a candidate's hire, an employee's review, a student's grade. Not because AI can't generate text that looks like an evaluation, but because judging a person has to be something a person can be held accountable for.

In between lies a gray zone: actions that are reversible but visible — creating a task for a colleague, adding an event to someone else's calendar, a comment on a shared document. The sensible rule here is to let them happen automatically, but clearly labeled — a tag reading “AI draft,” a status of “pending approval,” a draft rather than a published version. That way a colleague knows exactly where they stand, and nobody finds out weeks later that they'd been corresponding with a bot all along.

One thing deserves emphasis, because it's easy to forget in the excitement: the approval step must not become a formality. If you're clicking through twenty proposals every Friday without reading them, you don't have oversight — you have the theater of oversight. When that happens, it's a signal the routine is producing more than you can actually evaluate — and the fix is narrowing its scope, not clicking faster.

Why the first two weeks don't work

Almost every routine goes through a period where it costs more time than it saves. It's not a malfunction, it's a phase — and anyone who doesn't expect it will shut the routine off at exactly the moment it would have started paying off.

The reason is simple: the brief is missing exceptions that live in your head but that you've never actually stated out loud. That you always reply to emails from this one colleague personally. That orders above a certain amount don't go into the regular queue. That the Friday summary shouldn't include internal projects. None of this occurs to you when you're designing it, because you don't experience it as a rule — you experience it as obvious. It only surfaces the first time the routine trips over it.

That's exactly why tuning is the main work of the first two weeks, and it's worth approaching systematically. The best mechanism is very simple: turn every correction you make to the routine's output into a rule, and add it to the brief. Deleted three items from the summary because they didn't belong? That's a rule. Rewrote the greeting in a draft? A rule. Without that conversion, you keep fixing the same thing over and over, and the routine never learns anything — and this is exactly the point where it either becomes a real operation, or turns into a disappointment.

One more recommendation that pays off: build your first routine on work you know well and that isn't critical. Not communication with your biggest client — sorted email, a weekly summary, or prepping materials. You need to be able to reliably recognize a bad output, and for work you've done for ten years, you can spot that at a glance.

When to shut a routine down

Automations are easy to set up and almost never get retired. A year in, a typical company has a set of routines, half of which nobody reads and a quarter of which run against a process that's since changed. A routine doesn't disappear on its own and doesn't announce that it's no longer needed — it just quietly keeps consuming attention, data access, and trust.

It's worth having a few unambiguous signals for shutting one down. You're not reading the output. Two weeks in a row you haven't opened the summary — you don't need it, no matter how useful it sounds in theory. You're approving blindly. Review has turned into rubber-stamping, which means the routine is either doing pointless work, or too much work for you to keep up with. You're correcting more than it would take to just write it yourself. After a month of tuning, that's a verdict, not a phase. The process changed. The routine was built for a procedure that no longer applies, and now it produces output that's formally fine and substantively dead. And finally: nobody knows why it exists. It has no owner, and nobody can say what would happen if it were switched off.

Shutting down a routine isn't admitting defeat — it's ordinary maintenance, and it doesn't have to be total. Plenty of routines shouldn't die, just lose weight: a summary with fifteen sections that you only read two of should get trimmed down to those two. A useful habit is a quarterly review: go through the list of running routines, ask of each one “if it didn't exist today, would I build it again?”, and act on the answer. The same review should include a check of access — what each routine can see, and whether it still needs to. At company scale, this review belongs in the broader rollout framework covered in the tip AI at your company; the chapter Processes and automation also helps with deciding what's even worth automating in the first place.

One last note that applies to the whole operation: a routine amplifies whatever you put into it. Well-described work repeats well; poorly described work repeats poorly — just more regularly, and without anyone noticing right away. That's why the skill of writing a clear brief, covered in the chapter Briefing AI is a skill, is a prerequisite for every routine, and verifying output, per the tip AI makes things up with total confidence, is a necessary part of it. Automated nonsense is still nonsense.

What to take away

• A routine is a prescribed procedure with the same sequence of steps every time; an agent gets a goal and chooses its own path. The line is about who decides the next step — and that decides how much oversight you need.
• Designing a routine takes four questions: trigger, inputs, one specific output, and a named approver. If you can't answer one in a single sentence, don't start setting it up yet.
• Decision framework for an agent: reversible and externally invisible — yes: read, sort, search, prepare, flag. Irreversible or binding — never: send, pay, delete, sign, evaluate people.
• The gray zone belongs in clearly labeled drafts: a “pending approval” tag, a draft instead of a sent version.
• The first two weeks, a routine doesn't run well because the brief is missing exceptions you never actually stated. Turn every correction into a rule, or it never learns anything.
• Routines need to be retired too. An unread output, blind approval, and a changed process are all signals to shut one down; a quarterly review, including an access check, keeps the whole set healthy.