Too many AI automation ideas? Pick the next by reusing what already runs
Pick your next automation by whether a capability you already run can be pointed at it, not by pain.
Key points
- By task name, each idea looks separate
- Relist ideas by capability name
- Pick a second task for a running one
- Re-point only once the first runs small
Overview diagram in preparation
Contents
Listed by task name, every candidate looks different
A&A perspective
In this article, a capability means a piece of processing that works the same way across departments. "Research the other party and summarize the key points" and "turn records into a summary" are examples.
A&A perspective
Once you use Claude Code yourself, five or six tasks that look automatable appear at once: sales research, drafting quotes, sourcing hiring candidates. You could build any of them, so no order emerges.
A&A perspective
Listed by task name, each candidate looks like a separate build. Quotes and hiring have different owners and tools, so the only yardstick left is "which hurts most."
A&A perspective
How much a task hurts changes week to week. Hiring this week, quotes next week; the starting point keeps moving, and half-built automations are left behind. Stalled automations still need maintenance, which leaves even less time for the next build.
From the sources
Clay, a company that sells a sales-data research service, publishes customer stories on its own site. One covers Lovable, a service that builds web apps from plain-language instructions. The person who handles internal automation there says there is an infinite amount you can build, and the question becomes "which experiments actually generate value?"
A&A perspective
The problem described is not being unable to build, but being able to build too much. The company sizes differ, yet it is the same shape as what happens to an owner who can assemble anything with Claude Code.
Relist the candidates by capability
A&A perspective
Relisting means writing down, for each candidate task, what it does inside, using a capability name. Keep the task name and add the capability name in the next column.
From the sources
The story lists three systems the Lovable lead built. The first handles enterprise inquiries. When a form arrives, it researches the company's industry, the person's role, any existing relationship and likely priorities in real time, then routes the prospect to the best-matched sales rep. Reps also get a brief before each meeting.
From the sources
The second is creator partnerships. It researches candidate channels along with context such as views and audience makeup, then scores them against the ideal partner profile. The third is recruiting. It gathers candidates, researches their backgrounds and matches them to open roles, and then a recruiter decides whether to reach out.
A&A perspective
By task name, sales, partnerships and recruiting belong to different departments. What happens inside, though, is the same shape: research the other party, build context, and let a person decide what comes next. Grouping the three as one capability is the reading of A&A, which writes this article. The story presents them as separate use cases and credits the common thread to Clay's research capabilities.
From the sources
Gumloop, which makes workflow automation tools, has also published how its two-person support team operates. Every time a ticket arrives, an automated workflow pushes a full profile of the user into the support tool. Before a call, an AI agent researches the user and past interactions and adds pre-meeting notes.
A&A perspective
Here too, the scenes differ, yet the step of researching someone and building context keeps reappearing. Relisted this way, five or six candidates can collapse into two or three capabilities.
Hypothetical example
Suppose your candidates are sales research, sourcing hiring candidates, drafting quotes, meeting minutes and draft replies to inquiries. Rewritten by capability, sales research and candidate sourcing are "research the other party and build context." Minutes and draft replies become "turn records into summaries or drafts," and only quotes remain as a separate capability with its own calculation rules.
| Candidate task | What it does inside (capability) | Next move |
|---|---|---|
| Sales research | Research the other party and build context | If it runs, it becomes the base to re-point |
| Sourcing hiring candidates | Research the other party and build context | Make it the second destination of sales research |
| Meeting minutes | Turn records into summaries or drafts | If it runs, it becomes the base to re-point |
| Draft replies to inquiries | Turn records into summaries or drafts | Make it the second destination of meeting minutes |
| Drafting quotes | A separate capability with its own calculation rules | Re-pointing cannot cover it, so make it a candidate for a new capability |
Point a running capability at a second task
A&A perspective
The next one means a capability that already runs, pointed at a second task. List the option of building a new capability from scratch separately from the option of re-pointing a running one, and consider re-pointing first.
From the sources
The Lovable story states why the lead moved on to a second system. The inquiry system proved Clay could handle high-value workflows, which gave him the confidence to tackle a completely different problem.
From the sources
It goes on to say the creator partnerships showed that Clay's research capabilities could extend to any scenario that requires understanding many people and acting on each one's context. The page then presents the recruiting system.
A&A perspective
The story frames this as Clay's research capability, and does not say the built system itself was reused as is. Even so, the order of presentation can be read as a shape that worked being pointed at another task.
A&A perspective
The reason to put re-pointing first is the number of systems you maintain. Adding a new capability adds one more thing to fix when it breaks. Pointing a running capability at a second task keeps the core of what you fix at one. This is A&A's judgment; neither source compares maintenance load.
Hypothetical example
If pre-meeting sales research already runs at your company, the next candidate is researching hiring candidates. The subject changes from companies to people, and the reference changes from sales notes to open roles. The research-and-summarize step itself can be used in the same shape.
A&A perspective
A task cannot be covered by re-pointing when what it does inside differs from every existing capability. In the example above, quotes are that case. Only then treat it as a candidate for adding a new capability.
Widen only after the first one runs small
A&A perspective
The time to point it at a second task is after the first one runs at a small scale and you have confirmed it works.
From the sources
The Lovable lead says he tests something new at a small scale, validates what works, and adds volume when it does. The page also says the first system, for inquiries, led to the second effort.
From the sources
The Gumloop article likewise says its support operation did not start out fully formed. It grew one automated workflow at a time, over months of continuous iteration.
A&A perspective
If you point it at a second task before the first one runs, you cannot tell where a failure came from. You cannot separate a weak research step from a poor fit with the new task.
A&A perspective
On the other hand, pain can be useful as an entry point.
From the sources
The Lovable lead says that when he spots a bottleneck, he goes into Clay, experiments a bit and sees if it works.
A&A perspective
You can use both in order: pain to find candidates, and capability names when choosing the next one. This is A&A's approach, not a statement in the story.
A&A perspective
Truly urgent work, such as outages or deadlines, sits outside this way of choosing. What this covers is the state where nothing is urgent but you want to do everything.
A&A perspective
The Lovable story is also Clay's sales material, and its impact figures show no comparison period or baseline, so this article does not use them. It also describes a company with a dedicated lead, so what transfers to your company is only the relisting idea. A&A has not measured how much maintenance effort this way of choosing saves.
Summary
A&A perspective
Listed by task name, every candidate looks like a separate build and can only be compared by pain.
A&A perspective
The relisting puts a capability name such as "research the other party and build context" next to each candidate.
A&A perspective
The next one comes from a second task a running capability can be pointed at. A new capability is added only when re-pointing cannot cover the task.
A&A perspective
The time to point it at a second task is after the first one has been tested small and starts running.
Listed by task name, every candidate looks like a separate build and can only be compared by pain. The relisting puts a capability name next to each candidate, and the next one comes from a second task a running capability can be pointed at. A new capability is added only when re-pointing cannot cover the task, and the time to re-point is after the first one has been tested small and starts running.
FAQ
Is it fine to postpone a task that hurts?
Truly urgent work, such as outages or deadlines, is handled first, outside this way of choosing. Choosing by capability name is for the state where nothing is urgent but you want to do everything.
What if no automation is running yet?
This way of choosing assumes at least one automation already runs. For the first one, choosing a task whose results you can judge yourself fits. That approach is covered in "Starting AI in small business: begin with one task you can judge yourself".
Won't re-pointing end up as a rebuild anyway?
It can. If you assemble from raw parts yourself, swapping the subject you research and the reference you match against still takes work, even when the destination is natural. Gumloop describes building on its own platform where the parts already exist, so if you assemble from raw parts, the effort may not shrink the same way.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- How Lovable uses Clay to scale one of the fastest-growing startups in history
Clay · undated customer story; no visible publication date
Accessed 2026-10-27 - Supporting the world’s most AI-native companies with a 2-person team
Gumloop · 2026-02-17
Accessed 2026-10-27