Every hour. Every night. Monday at eight. The minute before a meeting. After every call. All day, on a loop. And four of them do nothing until somebody asks.
That is fourteen things three people at Anthropic built for their own work, sorted by when they start. Five sit on a fixed clock. Four wait for an event. Four wait for a human. One just keeps looking.
That sort finds no pattern. There is no shared rhythm, no shared frequency, not even agreement on whether a machine should start itself. If you are looking for the recipe in when things run, there is no recipe.
The next sort finds one immediately. It is not about when anything runs. It is about what got written before anything could run at all.
Who built these, and how big their week was
Three names and three very different weeks. Have them straight before we use their numbers for anything.
John Albert is a business development rep. He has around a hundred active accounts at any time, and he writes that he was spending five hours a day answering inbound by hand. That is his own figure about his own work.
Jared Sires joined Anthropic in 2024 as an account executive with no coding experience. He carried 600 to 700 accounts, took ten to fifteen customer calls a day, and worked until nine or ten at night. He built an application of roughly 4,300 lines.
Adam Ward is a field marketer. He has no book of accounts at all. His job was to collect the week's marketing news and get the right piece in front of the right sales rep, and he was spending Sunday evening on it.
Notice the spread. Sires has six times Albert's accounts and Ward has none. Three different jobs, which is why their numbers cannot be averaged into anything that describes you. Every figure in this article is Anthropic's own number about Anthropic's own staff, published by the company that sells the model. They can show that a moment repeated and that the person standing in it had measured it. They cannot predict what you will save.
And notice one more thing, true of all fourteen: there is a human at the end of each one. Albert writes that the rep reviews, edits and sends. All fourteen are built that way from the start, rather than having it added afterwards.
Do the arithmetic before you build internal AI tools
Before we look at any of them, there is a calculation that decides whether a fixed schedule makes sense at your size. It is three numbers, and you can get all three yourself:
How many times a week it happens. Times how many minutes it takes each time. Times how much of it is identical every time.
The first two decide whether a schedule is worth building. The third decides something else and more important, which we get to in the section on what all three of them wrote first.
The reason this belongs here rather than at the end is that it changes how you read the rest. Albert runs his inbox every hour. That is 40 runs in a working week. With a hundred active accounts there is something in the inbox almost every time. With forty accounts there is not, and most of those 40 runs come back empty.
None of the three sources runs that calculation. They never needed it, because their volumes made the answer obvious. That is exactly why it is your job and not theirs. AI workflow automation starts with those three numbers. The choice of tool comes much later.
Monday morning cost somebody their Sunday
Ward collected the week's marketing news and wrote a briefing for each individual sales rep. Sunday evening, every week, by hand.
What he built connects Claude to the company's data, pulls the rep's territory from the CRM and account updates from Slack, and writes a personal briefing for every rep on Monday morning. He reads it and sends it. Every send is archived.
This is the moment that translates directly. Every company has a Monday, and in most of them somebody spends Sunday evening or seven o'clock Monday pulling together what everyone else should know. The frequency is once a week, the volume is irrelevant, and there is no lower limit on how big the company has to be before the job makes sense.
At your size: if somebody does the same round-up every Monday, whether it goes to sales, to production or to the whole company, that is the cheapest candidate in your week. One fixed point a week is the easiest schedule to get right, and the person who writes it today can tell instantly whether the draft is good enough.
Use the night
Albert's prospecting task runs overnight across his whole book. It researches, checks each account against their criteria for a good customer, and returns a short brief, a score and a suggested way in. He reads them in the morning and decides who to write to.
The night is the most overlooked asset in this whole story, and it is the one place a ten-person company and Anthropic stand level. You both have eight to ten hours where nobody is working and nobody is waiting on a reply. There is no volume you have to clear, and no licence gives Anthropic more hours in the day than you.
At your size: forty accounts read properly once a week overnight is a better proposition than 600 skimmed. It is a different job from theirs, and the sources could not set it, because their volumes never forced them to ask. And here too the human reads the result before anyone is contacted.
The minute before the meeting
Sires built a task that reads the calendar, looks up the people he is about to meet, and writes a few talking points before he walks in. The reverse exists too: a draft of the follow-up email from the meeting notes afterwards.
It is the cheapest thing in this article to build. It needs a calendar and the ability to search. No CRM, no data warehouse, no integrations. A twelve-person company already has both.
At your size: this is the candidate if you want to see it work before building anything larger. If you have five meetings a week, spend ten minutes preparing for each, and prepare the same way every time, the arithmetic is already done. The talking points are read by the person who needs them a minute before they are used, and the path from draft to human does not get shorter than that.
Here the rule stops paying
Then there is Albert's inbox, and it is here because it is the one of the four that does not translate.
His task runs every hour, finds every thread that needs an answer, and drafts a reply. The five hours a day is what he says the work cost him before he built it; he reports less time on manual work afterwards and puts no number on it, so neither will I. Put his figures into the calculation from earlier: a hundred active accounts, an inbox filling all day, and every run has something to do.
Now put your own in. Forty accounts and six emails a day that need a real answer. Forty runs a week, most of them coming back empty. The problem is frequency measured against volume, and a different CRM moves nothing.
Here the rule shows its own boundary, and a rule with no boundary is merely encouragement. If you take one thing from the four examples, it is that the frequency has to be chosen against your volume and not against what worked for somebody with six times the accounts.
All three wrote the same thing first
And here is the sort that finds a pattern.
Albert wrote a document of the questions that come back and the answers to them. It was written before anything was automated, and his hourly task begins every single run by checking whether that document is still accurate.
Sires wrote roughly 4,300 lines of code and tested several hundred versions of the instruction his application works from. He also built a tone layer that tells the difference between writing to a customer and writing to a colleague, and tested it on his own angry emails.
Ward put his instructions in GitHub under version control and archives every send.
Three people, three completely different technical setups, fourteen different starting triggers, and the same asset underneath all of it: something written down that says what a good answer is. That is the part that took the time. The schedule on top of it took an afternoon.
If you have tried this and got mediocre drafts back, the problem sat somewhere other than the model and the schedule. Nothing had written down what a good answer looks like. A model that has not been told guesses your register from nothing, and it guesses average.
The third number in the calculation therefore carries the most weight. How much is identical every time decides whether there is a document to write at all. A ten-person company has far less repetition in the calendar than Albert, and roughly the same repetition in the content: the same eight questions from prospects, the same three objections, the same onboarding email. The document pays on repetition of content. The schedule pays on repetition of clock. They are two different questions, and most small companies pass the first and fail the second. That order is what AI workflow automation stands or falls on.
The cost sits in the same place. 4,300 lines and several hundred rewrites is not a weekend. Sires had no coding experience, which is the encouraging half. He also sat inside the company that makes the model, with its data warehouse and its internal access, which is the other half. I have an interest in you believing this is buildable, because internal AI tools for small companies are what I build for a living. The objection stands anyway, because it is correct. If you want to know what having it built costs, I wrote recently about what an AI consultant costs.
Notice last of all who did the building. A seller with no coding experience, a marketer with version control, and a business development rep who set a task to run every hour. In none of the three was it the IT department, and that says more about what this takes than any of the hours figures do.
Work through your own week
Here is the tool. Take a week, your own, and write down the moments that come back. Put two numbers on each that you can genuinely produce, and an estimate on the third.
Multiply them, and hold the result against the setup cost the section above describes. I am not setting a threshold for you. I do not have a number that would hold for anyone but me, and an invented one would be worse than none.
Two things strike a row out regardless of how good the arithmetic looks.
The output goes to a customer with nobody reading it first. None of the fourteen workflows does that. In all three accounts the human reviews and sends, and it is the one detail that holds from end to end.
The input is a recording of a person, or the output is a judgement about a named employee. Albert's last task grades his own sales calls from recordings and issues a pass or fail. In a Danish company that is a staffing decision and a conversation with the people involved long before it is a choice of tool. What the law requires here I do not know, and the three sources say nothing about it either. The decision simply has to be made deliberately, rather than arriving as a by-product of the arithmetic looking good.
Then there is the one fixed schedule that pays at any size, and which none of the three sources mentions. Albert's hourly task starts by checking whether the document is still accurate. Who does that in a company with no machine for the job is written down nowhere. A document that has gone stale is worse than no document, because everything underneath it now repeats last quarter's answer with full confidence.
So put the fixed schedule on the document. That is the one that pays at your size, whatever the other numbers say.
If you want help with it. As an AI consultant in Copenhagen I set up AI agents for Danish and Nordic companies: agents that do the work, start on a clock or on an event, and always have a person at the end. An AI implementation that starts with the tool almost always ends up writing the document afterwards anyway.
I start with the document and the arithmetic, long before anything gets picked as a tool, because that order decides whether the rest holds. A company of twenty to two hundred people rarely has enough repetition in the calendar to copy Anthropic's schedules, and almost always has enough repetition in the content for the first document to pay. This is AI implementation without replacing staff: the person who did the work still decides what goes out.
If you want your own week worked through, write to me or read how I build internal AI tools.
FAQ
Frequently asked questions
The moment that repeats most often and where most of the content is identical each time. Multiply times per week by minutes each time, and hold that against how much is identical. The first two numbers decide whether a schedule pays; the third decides whether there is a document to write first.
Longer than the schedule suggests. Jared Sires at Anthropic built his on roughly 4,300 lines of code and several hundred rewrites of the instruction. Setting something to run every Monday takes an afternoon, and it is the preparatory work of describing what a good result looks like that takes the time.
It can write the draft. In all fourteen workflows from Anthropic a human reviews, edits and sends, and none of them sends anything out of the building on its own. That is the most obvious row to strike off your own list.
Write down a week, find the moment that repeats with the most consistent content, and write the document describing a good answer before you schedule anything. The document decides the quality. The schedule on top is the easy part.
Yes. The tool list is the least transferable part of these three stories. They used Salesforce, Gong, Apollo and an internal data warehouse, but what carried the work was a written document, and that can live in a shared folder.
In all three cases at Anthropic the person who had the work built it, and none of them sat in IT. The person sitting in the work is also the only one who can tell when the draft is good enough.
The person sitting in the work usually builds the first one themselves. All three examples here were built by sellers and marketers with no IT department behind them. If you want more of them, or want it to go faster, I set the agents up as an AI consultant and write the document with you, starting with the arithmetic so you can see whether it pays before anything gets built.
Sources
- How Anthropic's business development team uses Claude to run inbound and outbound at scale, Anthropic, 7 August 2026
- How one Anthropic seller rebuilt his team's workflows with Claude Code, Anthropic, 5 June 2026
- How an Anthropic field marketer uses Claude Code to send weekly personalized updates to every sales rep, Anthropic, 24 August 2026
Every figure on time spent, account numbers and lines of code is Anthropic's own number about its own staff.
