Sixty-five tasks, forty-one tools

We published a library of 65 task recipes — one page per thing a team can get done across their connected tools. Writing them was a design exercise; counting them afterwards turned out to be more interesting.

One caveat first, because it changes how to read everything below. This is a count of what we wrote, not a measurement of what anyone runs. It describes which tasks were legible enough to specify and publish, which is related to but not the same as which tasks matter most. We have no usage data here and are not implying any.

With that said: every figure comes from reading the 65 committed recipe modules that generate the use-case pages, so all of it is reproducible from pages you can open.

The library uses under a quarter of the catalog

Between them, 65 tasks draw on 41 distinct integrations. The catalog carries more than 175.

So a library deliberately built for breadth — seven audience groups, from marketing to finance to engineering — still touched under a quarter of what was available. That is not a criticism of the catalog; the long tail exists precisely so that the one tool your team depends on is there. But it does undercut a common instinct, which is to evaluate a platform by counting connectors.

The number that predicted whether a task was writable was never how many integrations existed. It was whether the two or three specific tools that task crosses were among them.

Three tools carry most of it

Of the 65 recipes, 51 touch Notion, Slack, or Gmail — nearly four in five.

That concentration is worth sitting with. Notion appears in 26 recipes, Slack in 23, Gmail in 15. Everything else drops off fast: Linear in 8, Stripe in 7, then a tail of tools appearing once or twice.

The pattern is that these three are not really domain tools at all. They are where context lives and where output goes. A finance task ends in Notion. An engineering alert ends in Slack. A sales follow-up ends in Gmail. The domain tool in the middle changes every time; the ends barely move.

Which suggests the first integration a team should connect is rarely the one specific to their function. It is whichever of these holds the context everyone already refers to.

The median task is two tools and four steps

Half the recipes use two integrations or fewer. Half are four steps or fewer. The widest is four tools; the longest is six steps. Nine recipes use a single tool.

This was the finding that surprised us most, because it is the opposite of how automation is usually sold. The pitch is orchestration — many systems, long chains, a diagram with a dozen boxes. What people actually need documented is a two-tool join: read this, decide something, write that.

The reason those small joins were worth writing is not that they are hard. It is that each one crosses a boundary a person was carrying by hand, and the crossing is the whole cost. A four-step task that spans two tools eliminates a context switch; a fifteen-step single-tool macro mostly does not.

Most of it has no schedule

Fifty-four percent of the recipes are on demand. They have no cadence at all.

The rest cluster into a handful of real rhythms — weekly for digests, before each meeting for prep, a few firing on an event like a new ticket or a failed payment. But the majority answer a question at the moment someone has it.

This is a quiet argument against thinking of this category as scheduled automation. A cron job is a commitment made in advance about when something matters. Most of these tasks are the other thing: a question you have irregularly, that used to cost twenty minutes because the answer lived in three places.

Almost every task is cross-category

64 of the 65 recipes carry more than one category. The library uses eleven categories in total, and the most common pairing is a domain category with Productivity & Collaboration or Project & Task Management.

That is the same finding as the two-tool median, seen from a different angle. A task earns its page when it leaves its own domain — when support work becomes engineering work, when an analytics number becomes a written recap. Work that stays inside one category and one tool tends to already have a feature for it, built by the vendor whose tool it is.

The gap the assistant fills is the space between products, which is exactly the space no single vendor has an incentive to fill.

What we would tell someone building a library like this

Three things, in order of how much they cost us to learn.

Write the ends before the middles. The tasks that were easy to specify were the ones with an obvious destination. Anything that ended in "and then someone decides" was hard to write and probably should not have been automated as a single task.

Resist the long chain. Every recipe that grew past five steps wanted to be two recipes. The tool count followed the same rule — four integrations was consistently a sign that a task had absorbed a second task.

Count what you built before you describe it. We assumed this library was broader than it is. It uses 41 tools, concentrated on three, in tasks averaging just over two integrations each. Describing it as "comprehensive" would have been the natural marketing instinct and would have been wrong.