How Bamboo builds agents with marketers: told through one CPG product launch

This is the eight-step process we use to build agents with marketing teams, illustrated with one real engagement: a CPG ecomm brand launching a new version of its flagship product. The customer's details are anonymized; the work is as it happened.

The growth lead needed to know every day whether the launch was working, and not just whether people bought it: what they thought of it once it arrived, because for a subscription product that's what decides whether they stay. So the voice of the customer had three jobs that month. Read where retention was heading before the renewals came in. Catch feedback early enough to act on it, while the launch was still live. And benchmark the launch against the previous product, so a number meant something.

All of it existed. Channel performance sat in one set of dashboards; the customer's own words sat in support tickets, cancellation reasons and survey answers, in three systems that didn't agree with each other. Pulling it together was the job, and it cost one to two hours a day without ever adding up to one picture. What they needed was an analyst. What we built was one daily launch briefing: customer feedback beside channel performance, with a recommendation on what to do about it, and the team used it to dial up launch budget. The rest of this piece is how, and it's what a team hires us to own: finding the workflow, capturing the context, the build, the checking, and keeping the agent improving after it ships.

01Map the work

We start by sitting with the person who does the work and walking it end to end. If they ran it last week, we start from exactly what they did, not the version they'd describe in a meeting. Sometimes the work is something the team never had the hours to get to, and then the walk is about how they'd do it if they could. Either way we want the same things: where each number comes from, what each term means to this team, who gets to decide what.

The growth lead was doing this read every day, the slow way. The walk showed why it was slow. Their three feedback sources didn't speak the same language. A support tag, a cancellation-survey answer and a product-survey question could all be about the same complaint and never line up. So we mapped every tag and reason onto one shared list, and they approved it line by line. Reasons that exist in only one source stayed visible on their own instead of being forced into a bucket, because the odd ones are usually the ones you want to see. That list is the reason map, and it comes back later.

02Write the brief

The walk becomes a one-page brief: our understanding of the build, played back in the customer's language so they can catch anything we got wrong while it's still cheap. It's a simplified PRD, and it answers six questions. What do I get, as numbered outputs tied to reports they already use. What don't I get. What do you need from me, and when. How will I know it's done, with a "complete when" on every step. Where does the output land. And what it costs: the work is sized in points, the unit our plans are sold in, so they can see it against what their plan covers that sprint. The brief stops short of the engineering breakdown. That comes next, and it's ours. They approve it with a one-word reply in Slack.

03Design the flow

Our AI engineer takes the brief and writes the design doc: the entire flow, step by step, with nothing assumed. Each step gets sorted. A step is discrete if it has one right answer, and anyone with the instructions would land on it. A step is judgment if two experienced people could reasonably disagree. Discrete steps are the agent's. Judgment steps get drafted by the agent and decided by the marketer. Then every step becomes a ticket with a size on it, so the brief's points turn into a plan we can actually run. Described out loud, the daily read was a handful of steps. Written down, it was close to twenty. A few of them:

Step	Kind
Pull the support tickets	Discrete
Include every topic category the support desk files under	Discrete. Found while writing this step down
Map every tag and reason onto the reason map	Discrete
Group what customers wrote into themes; check the quotes shown are representative	Judgment, drafted by the agent under rules
Draft what changed and what to do about it	Judgment, drafted by the agent
Decide what matters, what budget does, what goes to the CEO	Judgment, the growth lead's

The bold row is why we do this on paper first. The team had been watching one product-quality complaint closely since the launch. Writing "pull the support tickets" down properly meant listing every topic category the support desk files under, and one of them had never been in the old report. With it counted, the complaint barely registered, and the few tickets that did mention it were about a different product.

Nobody had been careless. The step just wasn't written down anywhere, so nobody, human or AI, was doing it.

04Fill the brain

We hold an agent to the same standard as a new hire, and we put in the same effort. Nobody hands a new analyst a login and a one-line message and expects a good first week. You sit with them, walk them through how the business actually works, show them where the numbers come from and which ones to trust, and read their first deliverables before they go to the CEO. You assume nothing. So before any skill is written, the agent gets the context a new hire would get in their first week, in one place we call the brain.

We don't start by asking the customer what goes in it. For every job we've built, there's a context playbook: what the agent has to know to do this work well, and what goes wrong when it doesn't. For a customer read during a launch, that's what every term means to this team, which number is the source of truth when two disagree, the baseline to compare against, the rules it must never break, and who owns what. We seed it from what the team already has, their existing docs and a round of Q&A, and then fill it in as the agent is used and we spot the gaps.

For the growth lead, the reason map went in first. So did the fact that this business reports Monday to Sunday, the previous product's cancellation reasons as the baseline, and the rule that refunds come from the warehouse table, not inferred from charge status. The brain is one shared thing: change a definition once and every run after it follows.

Plain files the customer owns, and a map of what's filled in and what still needs a person.

Some of what the brain needs, only the customer can answer. How close do two revenue figures have to be to count as matching? Which of three reports is the canonical number for a day? Those go back to the team as plain questions, one at a time, and the answers land in the brain, not in someone's chat history.

05Build the skills

With close to twenty steps on the board, the first build decision is one skill or several. One artifact or several. We chunk by block of work: the feedback pull, the cancellation read, the themes, the daily write-up. Each block becomes its own skill, owning its own part of the view, so it can be tested and fixed on its own. It's still one agent, reading one brain and graded by one set of evals, running several skills the way a person on the team would. When a block is big enough to be its own job, it gets its own sub-agent under an orchestrator; this one didn't need that.

Then we write it. Skills are natural-language code: the steps, the inputs, the checks along the way, the output format, and the traps in this team's data, held in a file the agent reads on every run rather than typed into a chat and lost by the next one. The evals, meaning the checks that grade each run against what the team said a good one looks like. And where a number has to be exact, deterministic code: the cancellation counts are reconciled against the source system's published totals, and the two reasons built from free text are flagged as reading slightly low rather than quietly smoothed over.

06Deploy

The agent runs where the team already works, in their own Claude, on a schedule, not in a tool they have to log into. Deployment is staged, the way you'd roll out anything that touches a live number: the marketer runs each skill against their own numbers first, and when its output matches what they'd have produced by hand, that skill goes on the schedule and the next one follows. The brief carries a launch date with buffer built in, so the agent is proven before the day it's needed.

Deployment also means building the surface the work lands on. Chat is a good place to ask a question and a poor place to synthesize: a marketer scanning a launch every morning needs a view, not a transcript. So we build the UI as part of the deployment, an artifact or an MCP app inside their Claude, where the numbers sit side by side, each one opens to its evidence, and the recommendation is a block you can act on. The marketer reads it the way they'd read a dashboard, in seconds.

For the growth lead, this is what landed in their Claude every morning.

07Human in the loop

It recommends. They decide. For the first two weeks of the launch, the growth lead had an executive briefing on it every morning. The agent updated the data on a schedule, said what had changed, and recommended what to do about it, with the tickets and survey answers behind every number one click away. They used their judgment on what mattered and took the pulse into the briefing with the CEO and the team. Hand off everything that isn't the marketer's decision, and nothing that is.

What the pulse said, across the first week, was that feedback on the new product was steady and the concerns the team had carried into the launch weren't turning into issues. With acquisition cost running below target and projected customer value above it, the team used that read as the case to dial up budget across channels.

08Learn from the runs

An agent that runs every day leaves a trace every day: what it was asked, what it pulled, where it stalled, what it wrote. We use that telemetry two ways. The brain checks itself against it and flags what's missing, stale or contradicted. And a Bamboo marketing engineer reads a sample of the runs, not every one, and annotates them: where the read was wrong, where it was thin, where it reached for something the brain didn't have. Each note is routed to the layer that owns it. A missing definition goes into the brain. A bad step goes into the skill. A rule goes into the evals, so the next run catches it. Fixes ship like features, through the same review as everything else, and when the brain needs an answer only the team has, it asks.

Every night the brain checks itself, fixes what it can with a receipt, and routes the rest to a person.

That's the difference between an agent that's good on launch day and one that's better a month later. For the growth lead, the next brief is retention by customer segment, on the same brain and the same skills. That's the shape every engagement takes: one agent that earns trust, then the next.