Putting AI Agents to Work on Growth Tasks

Every few weeks someone forwards me a demo of an AI agent that supposedly runs an entire growth function on its own. It scans the market, writes the campaigns, ships the experiments, and reports the wins while you sleep. I watch these, and then I go back to the actual work, which looks nothing like the demo. The gap between what agents can do in a controlled clip and what they can do reliably against your real data, your real tools, and your real edge cases is still wide.

That gap is not a reason to ignore agents. It is a reason to be precise about them. I build AI-assisted growth automations for a living, mostly with Claude and orchestration tools like n8n and Zapier, and I use agentic tools by hand every day. Agents have changed how I work. They have not replaced the judgment that makes growth work worth doing. The teams getting value are not the ones chasing the autonomous everything-machine. They are the ones who picked a narrow, annoying, valuable task and handed exactly that piece to an agent with guardrails around it.

This post is what I actually believe about putting AI agents to work on growth tasks: what an agent really is, where it helps today, where it fails, and how to deploy one without creating a mess you spend the next quarter cleaning up.

What an AI agent actually is

Strip away the marketing and an AI agent is a large language model that can do three things beyond answering a question. It can plan a sequence of steps toward a goal, it can use tools such as search, code execution, or an API call, and it can take multi-step actions, feeding the result of one step into the next until it decides it is done. That last part is the real distinction. A chatbot responds. An agent loops: it acts, observes what happened, and chooses what to do next.

That loop is the source of both the power and the risk. Because the model decides its own next step, it can handle tasks that do not have a fixed recipe, tasks where the right sequence depends on what it finds along the way. It can also wander off, misread a result, and confidently take three wrong steps in a row before you notice. A traditional program does exactly what you coded. An agent does what it decides, and its decisions are probabilistic.

So when a vendor says “agent,” the honest question is: how much of the deciding are you actually letting it do, and what happens when it decides wrong? Most useful deployments keep the deciding tightly scoped and the consequences small. The demos that look magical usually do so precisely because nothing in them was consequential.

The honest state of things right now

Agents are genuinely good at some things and genuinely unreliable at others, and pretending otherwise wastes everyone’s time. They are strong at language work: reading a large pile of text and pulling out the shape of it, drafting a first version of almost anything, translating between formats, and following an explicit set of instructions on well-structured input. Give an agent twenty support tickets and ask for the three recurring complaints, and it will do in a minute what would take you an hour.

They are weak wherever precision, current facts, or genuine accountability matter. They still fabricate confidently, especially numbers and citations. They lose the thread on long chains of reasoning. They handle the happy path well and the weird edge case badly, and growth work is full of weird edge cases. They have no real sense of what is expensive to get wrong. An agent will delete the right rows and the wrong rows with exactly the same cheerful tone.

The practical read: agents are excellent assistants and poor owners. They compress the time between having an idea and having a rough draft of the thing, which is enormous. They do not remove your responsibility to check the output, and anyone selling you “set it and forget it” for anything that touches customers or money is selling you a future incident. I go deeper on how I structure this in my piece on AI-native growth automations, which is the backbone of how I think about this whole space.

Where agents genuinely help a growth team today

Here is the part that matters, because it is concrete. These are tasks where I have seen agents earn their place on a growth team right now, not in some projected future.

Research and synthesis. Competitor scans, where you point an agent at a set of sites and ask what changed in their pricing, positioning, or onboarding. Summarizing a stack of sales calls or a month of support tickets into the themes that keep coming up. This is the single highest-return use I know: the raw material is text, the task is compression, and the cost of a small error is low because a human reads the summary anyway.

Content drafting and repurposing. Turning a long post into five social variants, drafting outlines, adapting one message for three audiences. The agent gets you to a rough draft fast, and you spend your time editing instead of staring at a blank page. This is a whole discipline on its own, and I have written about how to run it as a repeatable process in AI content operations.

Data extraction and cleanup. Pulling structured fields out of messy exports, normalizing inconsistent naming, tagging a list of accounts by segment. Tedious, rule-shaped, and forgiving because you can spot-check the output.

Drafting experiment analyses. Feeding an agent the results of a test and having it write the first pass at what happened and what it might mean. It will not replace your statistical judgment, and you should never let it, but it removes the friction of starting the write-up. Pair this with a real analytical discipline, which I lay out in hypothesis-driven experimentation, so the agent is drafting around your thinking rather than inventing it.

Triaging and classifying inbound. Sorting incoming leads, messages, or tickets into categories and routing them. This is a strong fit because classification is a bounded task with a checkable answer.

Monitoring and alerting. Watching a dashboard, a feed, or a set of mentions and flagging the thing that needs a human. The agent is not deciding what to do, only deciding what deserves your attention.

Prototyping. Standing up a quick internal tool, a scrappy script, a rough landing variant to test an idea before you invest in building it properly.

Notice the pattern. Every one of these is scoped, the output is checkable, and a mistake is cheap to catch. That is not an accident. That is the whole selection criterion.

The difference between an automation and an agent

This distinction saves more money and grief than any other idea in this post. A simple automation follows fixed steps. When a form is submitted, add the person to a list, send the welcome email, notify the channel. The steps never change. An agent decides the steps based on what it encounters.

Most of what a growth team wants to automate is the first kind. If the logic is “when this, do that,” you do not need an agent. You need a Zap, an n8n flow, or a few lines of code. It will be cheaper, faster, and it will do the same thing every single time, which for a fixed process is exactly what you want. Adding an agent to a fixed-step task means paying more, waiting longer, and introducing the chance that the model does something creative on a task where creativity is a bug.

Reach for an agent only when the steps genuinely cannot be known in advance, when the path depends on what the task uncovers as it runs. A competitor scan is a decent fit because the agent has to react to what it finds on each page. Sending a templated email is not. The skill is being honest about which kind of problem you actually have, and defaulting to the simpler tool. I would rather run a boring reliable Zap for two years than a clever agent that surprises me once a month. If you want the practical toolkit for the hands-on side of this, I cover it in Claude Code for marketers.

How to deploy an agent safely

If you take one section seriously, make it this one, because this is where deployments quietly go wrong. Safety with agents is not a feature you buy. It is a set of constraints you design in from the start.

Scope the task narrowly. An agent with one clear job and a bounded input is manageable. An agent with a vague mandate and access to everything is a liability you cannot reason about. Narrow is safe.

Put a human in the loop for anything consequential. The agent drafts, proposes, or flags. A person approves before anything real happens. For low-stakes, easily reversible tasks you can loosen this. For anything that touches a customer, spends money, or changes production data, you do not.

Default to read-only access. Most of the value in the tasks above comes from reading and summarizing, which needs no write permission at all. Give write access only where you specifically need it, and scope it to the narrowest surface that works. An agent that can only read cannot break much.

Log everything. Every action the agent takes should be recorded so you can see what it did and why. When something goes wrong, and eventually it will, the log is the difference between a five-minute fix and a forensic investigation.

Check the output. Build in evaluation, whether that is a human spot-check, a second automated pass, or a set of test cases you run the agent against before trusting it on live work. Do not assume the output is right because it reads fluently. Fluent and wrong is the agent’s most dangerous mode.

Keep agents away from irreversible and customer-facing actions without review. Sending the email, publishing the post, deleting the records, charging the card. These are exactly the actions where the confident-but-wrong failure mode is most expensive, so these are exactly the ones that stay behind a human gate.

Keep a human accountable

Underneath all of those guardrails is one principle: a named human owns the outcome. Not the agent, not the vendor, not the automation. A person.

This matters because agents diffuse responsibility in a way that feels fine until it doesn’t. When the campaign goes out with the wrong figure or the segment gets tagged incorrectly, “the AI did it” is not an answer anyone accepts, and it should not be. The agent is a tool, and tools do not carry accountability. The person who deployed it does.

In practice this changes how you design the work. You do not ask “can the agent do this end to end.” You ask “who is accountable for this outcome, and does the design let that person actually stay in control.” If the honest answer is that nobody is really watching and nobody could catch a bad output before it landed, you have built something you should not ship, no matter how impressive the demo looked.

Start narrow, not autonomous

The most common mistake I see is starting with ambition. A team decides to build an agent that owns a whole channel or runs the entire content operation, and six weeks later they have a fragile system nobody trusts and a lot of wasted enthusiasm.

The approach that works is the opposite. Pick one narrow task that is genuinely valuable and a little painful. Weekly competitor summary. Ticket triage. Draft repurposing. Build an agent for exactly that, with the guardrails above, and run it until it is boring and reliable. Then, and only then, consider expanding scope.

Narrow tasks are easier to specify, easier to verify, and easier to trust. They give you a real result quickly, which earns the room to do more. They also teach you how agents fail on your specific data, which is knowledge you cannot get from a blog post, including this one. Every reliable broad system I have seen was assembled from narrow reliable pieces. None of them started broad and got reliable.

The skills a growth PM needs to direct agents well

Working well with agents is a skill, and it is not the skill people expect. It is less about prompting tricks and more about the discipline of specifying work clearly, which turns out to be the same discipline that makes you good at delegating to people.

Writing clear specs. An agent, like a new hire, does only as well as the instructions allow. Vague input produces vague output. The ability to state precisely what you want, what “done” looks like, and what constraints apply is the core skill. Most disappointing agent output is actually a disappointing spec.

Decomposition. Breaking a large goal into steps small enough that each one is checkable. This is exactly what you do when you plan a project, and it is what lets you hand the checkable pieces to an agent while keeping the judgment calls for yourself.

Verification. Knowing how you will confirm the output is right before you run the task, not after. If you cannot describe how you would check the result, you are not ready to trust an agent with it, and honestly you are not ready to trust a person with it either.

These are old skills. Agents just raise the reward for having them, because a clear spec now produces a draft in seconds instead of a week.

What to expect in the near future, honestly

I will not pretend to know where this lands. What I am reasonably confident about: agents will keep getting more reliable at the bounded tasks they already do, the tooling to keep them scoped and observable will get better, and the cost and latency will keep falling. The set of tasks worth handing off will grow.

What I do not believe is coming soon: a trustworthy autonomous agent that owns your growth function without oversight. The failure modes that make oversight necessary, confident fabrication and poor judgment about consequences, are not close to solved. The teams that win will not be the ones who removed humans from the loop. They will be the ones who used agents to remove the tedious work so the humans could spend their attention where judgment actually matters.

Common mistakes to avoid

A short list of the ways I see this go wrong, so you can skip the lessons I already paid for.

Over-trusting the output. Fluent text reads as correct. It often is not. Check it, especially anything with a number in it.

No guardrails. Handing an agent broad access and hoping for the best. Scope, permissions, logging, and human review are not optional extras. They are the deployment.

Agent theater. Building an agent for a task a simple automation handles better, because “agent” sounds more advanced. It is not advanced. It is expensive and less reliable for a fixed job.

Ignoring cost and latency. Agents that loop and call tools cost real money and take real time. A task that runs fine once can be painful at scale. Know the per-run cost before you turn it loose on volume.

No accountable owner. Deploying something nobody is really watching. If no human could catch a bad output before it does damage, the system is not ready.

The short version

• An AI agent is an LLM that can plan, use tools, and take multi-step actions on its own, not just answer questions. The self-directed loop is both the power and the risk.
• Agents are strong at language work: research, synthesis, drafting, classification, extraction. They are weak wherever precision, current facts, or accountability matter.
• The best current uses are scoped tasks with checkable output and cheap mistakes: competitor scans, ticket and call summaries, content repurposing, data cleanup, experiment write-up drafts, triage, monitoring, prototyping.
• If the steps are fixed, use a plain automation, not an agent. Default to the simpler tool.
• Deploy safely: narrow scope, human approval for anything consequential, read-only by default, full logging, checked output, and no irreversible or customer-facing actions without review.
• Keep a named human accountable for every outcome. The tool does not carry responsibility; the person who deployed it does.
• Start with one narrow valuable task, make it boring and reliable, then expand. Skip the autonomous everything-machine.
• The skills that matter are clear specs, decomposition, and verification. Same discipline as good delegation.

---

I am Deepanshu Grover, a Growth Product Manager in Paris. If you are trying to figure out where AI agents actually fit in a growth team, connect on LinkedIn or get in touch.