What is growth engineering?

What the job actually involves once AI is doing the work, and the layer underneath that decides whether it keeps working.

Amy WilkinsonFounder, FounderGrowthOS

18 September 2026
10 minute read

I get asked what growth engineering is fairly often. Usually right after I've said "growth engineer" out loud and watched someone politely decide not to ask a follow-up question.

So this is the full answer. If you've seen my Reel, this is the longer version with the parts I couldn't fit into three minutes.

We'll cover what the term means, what it looks like in a real workflow, where the experience comes in, the part most tutorials skip, and a checklist you can use on any AI growth system, including one you've already built.

If you're about to build your first system, read 5 steps to having AI run growth systems for you alongside this. That guide covers the order I'd build in. This one is about what you're actually building, and what keeps it honest once it's running.

1. The short definition

Growth engineering means using technology and data to help a business grow, which in practice means getting and keeping more customers.

The term started out mostly inside product teams. A growth engineer might rebuild an onboarding flow, test a referral mechanic, fix the point where trial users drop off, then measure whether any of it worked. The role existed because there was a gap between "we should try this" and "this is live, and here's what happened."

AI has changed who can close that gap. Someone with real growth experience can now build a lot more of it themselves.

The part I specialise in is slightly different. I take the judgment of an experienced growth operator and build it into AI systems that do recurring growth work: finding prospects, preparing outreach, planning follow-ups, producing content, checking what happened.

In practice, that's less mysterious than it sounds. It's a very well organised filing system:

Swipe the table sideways to see every column.

When those layers are designed well, the system can feel like an extra two or three operators. When they aren't, it feels like an extra two or three operators who never read the handover doc.

2. What it looks like on a normal Tuesday

Definitions only get you so far, so here's a real one.

Most of my clients use the FounderGrowthOS acquisition engine. The assistant that runs it is called Andy. Andy works from the client's business context and the processes I've built around it: who makes a good prospect, what counts as a real reason to reach out, what evidence is needed, and when a human has to decide.

A working day looks roughly like this:

Swipe the table sideways to see every column.

Where the prospects come from

Sourcing is the part people assume is a list purchase. It isn't. The system reads the places where a real reason to talk shows up, and which places those are depends entirely on who the client sells to.

If they sell to restaurants, that's trade press, local restaurant news, awards and openings. If they sell to early-stage startups, it's funding announcements, accelerator batches and product launches. A company that has just raised, just opened, just hired or just shipped is a different prospect from the same company last month, and the timing is most of the value.

Each candidate arrives with the evidence attached, so the founder can see why it surfaced rather than taking the system's word for it.

Choosing the way in

Then the system has to pick a route, which is a decision in itself.

A warm introduction through someone the team already knows beats a cold email to a general inbox. So the engine checks the team's own networks first, then looks for the named person who actually owns the problem, then decides the channel: email where there's a verified address, LinkedIn where there isn't.

What gets recorded

Every stage writes down what happened: what was sent, when, from whom, what came back and what the next step is. That record is what lets the next run be smarter than the last one, and it's what stops the same person being contacted twice by two different parts of the system.

Nothing in that table is technically extraordinary on its own. Plenty of tools can find a lead or draft an email.

What makes it growth engineering is everything connecting. The rejection reaches the sourcing step. The approval reaches the drafting step. The booked call changes what happens next instead of triggering another follow-up nobody needed. All those little jobs you'd otherwise have to remember and coordinate are joined up, and the founder stays in the decisions that matter.

3. Where the experience comes in

Here's an uncomfortable truth about AI agents. They will follow your instructions very well, including the bad ones.

If you don't know what a good prospect looks like, automating the search gives you a faster way to collect the wrong ones. If you don't know when a follow-up is helpful and when it's irritating, you'll build something that's efficiently irritating.

That's why this work needs someone who has actually done the job. Before I build anything, I want answers to questions like these:

• What does a good result look like, and how would you spot a bad one that looks good?
• Which signals mean someone is worth contacting now rather than in six months?
• What should the system do when information is missing or conflicting?
• Which decisions always need a human, even when the system is confident?
• What would you want to know about at the end of the day, and what should it leave alone?

A company can match your target industry perfectly and still be a terrible prospect. If you've never had to explain why, the agent has no chance of learning it.

4. The part the ten-step tutorials skip

I keep seeing posts promising you can get Claude to run your marketing in ten steps. And yes, building has become far more accessible. Six months ago, most of this needed an engineer.

But those tutorials tend to end at day one. The interesting problems start around week six.

Every time you say "remember this", "do it differently next time" or "actually, change that process", the information goes somewhere. Depending on how the system is built, you might be updating its memory, adding another instruction or changing the workflow itself.

Do that for a few months and you've got layers of decisions sitting underneath what still looks like a simple chat. Some go out of date. Some contradict each other. A one-off exception you made for one client quietly becomes the rule for all of them.

Here's how that looks in practice:

Swipe the table sideways to see every column.

That third one is the one I care about most.

If approval is only an instruction, the system is relying on the agent remembering to ask. If approval is a check the publishing or sending tool enforces, nothing goes out without a recorded yes, whatever the agent happens to believe that day. Those look identical in a demo. They are very different on a busy Tuesday.

What to put in place:

• Give each kind of information one home. Business facts, instructions, decisions and run history are different things. Keep current rules separate from historical records.
• Make corrections replace the old rule. When a rule changes, retire the previous version so it isn't left sitting next to the new one.
• Route decisions to the step that needs them. A rejection should reach sourcing. A corrected claim should reach every drafting step.
• Enforce approvals in the tool. Sending, publishing and spending should be impossible without a recorded yes.
• Review the context on a schedule. Look for stale facts, contradictions and exceptions that have turned into rules.

More memory doesn't automatically make a better system. You need to know what it's remembering, which version it should trust and what it's allowed to do with that information.

5. A checklist for any AI growth system

Ten questions I'd want answered before letting any AI system near my inbox. Use them on something you're about to build, something you've built, or something someone is trying to sell you.

1. Can you say what job it does in one sentence? "Runs growth" doesn't count.
2. Can you see why it made each decision? Evidence, source and reason, not just an output.
3. Where does a correction go? Can you point to the place it's stored?
4. What happens to the old rule when you change one?
5. Does a rejection reach every step that needs it?
6. Is approval enforced by the tool, or requested in a prompt?
7. What does it do when information is missing? Ask, skip, or confidently guess?
8. Does it tell you when it had a thin day, or does it pad the numbers?
9. Who notices when a connection breaks? And how quickly?
10. Can you pause it, and do you know how?

If you can answer all ten, you have a system. If you can't answer three or more, you have a promising demo that needs some engineering before it gets anywhere near your inbox.

So, do you need a growth engineer?

Honestly, it depends where you're starting from.

Swipe the table sideways to see every column.

I love that more people can build this now. I also want people to go in knowing what they're taking on, because the setup deserves as much attention as the exciting bit where the agent starts doing things.

It's easy to build. It's easy to build wrong, too.

This is the work I do with founders at FounderGrowthOS: working out which growth work should come off your plate, building the system around your judgment, and keeping it accurate as it grows.

If you'd like help with yours, reply with the growth job you'd hand over first and how you handle it today. That's a far better starting point than "I think I need some agents."

Written by Amy Wilkinson, 18 September 2026.