AI Marketing Agent: Own the Loop From Events to Revenue

A copy generator takes a prompt and hands back words. An agent that owns the loop starts one step earlier and finishes one step later.

1. Read the product. What events exist? Signup, activation, subscription, churn. What is missing?
2. Fix the gaps. Add the events and conversion tracking so the goal is measurable before anything sends.
3. Do the work. Draft the email, the ad, the search page, the Reddit reply, based on those events.
4. Hold some back. Send to most of the audience and keep a holdout so there is something to compare against.
5. Report what it earned. Lift on the goal, not opens.
6. Feed it back. Winners become automations, losers get paused, and the next morning's scan starts from better data.

Most tools sold as an AI marketing agent do step 3 and stop. That is why the results look like activity and never like revenue. The rest of this page is about steps 1, 2, 4, and 5, because that is where the technical work lives and where the hire earns its keep.

Here is what a morning scan is built to catch: signup is in the product events, and activation is not. Until the activation event exists, nothing you send afterwards can be measured. The situation plays out in the walkthrough on Ranla's agent window page.

An agent that only writes copy would draft a re-engagement email and send it. An agent that owns the loop notices that there is no activation event, which means there is no way to know whether the email worked. So the first action in that scan is not an email. It is a pull request that tracks activation where setup completes.

Ranla reads your repo or your analytics to do this. On the analytics side it connects to PostHog, Amplitude, and Mixpanel, and it reads Stripe for revenue. On the code side it connects to GitHub. When it finds an event that should exist and does not, it writes the tracking code and opens a pull request in your repo. Ranla's pricing page lists this under its engineering job: product events and conversion tracking as a pull request you review.

The rule that makes this safe is short. Nothing goes to your default branch. Ranla's agent window page states it in the scan itself: the pull request "waits for your review." Your engineers see the diff, decide whether the event fires in the right place, and merge or reject it like any other change. The agent never gets to decide that on its own.

That is also why this is the first job and not the third. If activation is untracked on Monday, every campaign you run before it is tracked produces numbers nobody can defend.

The pull request pattern extends past tracking code. Ranla's agent window page describes one window with six desks, one per job, and each desk has its own conversation. You can ask for the email, the ad budget change, the search page, the Reddit reply, or the events pull request, and the work opens beside the thread where you can edit it.

Three kinds of work always wait for you, whatever mode the agent is in:

• Merges. Code changes are pull requests, reviewed by a human.
• Spend changes. Ads get drafted and budget, audience, and keyword changes get proposed. The spend moves after you approve.
• Large audiences. In the scan example, the 53,000-person activation campaign was drafted with a ramp of 400 a day, and the page notes that "an audience this size always waits for your approval before it sends."

This is the difference between an agent you can let run and an agent you have to babysit. If the worst thing it can do without you is write a draft, you can give it room.

Every desk runs in one of three modes, and you set the mode per job. The modes decide how far the agent goes before it stops and asks.

The limits are explicit numbers, not vibes. A daily send ramp. A weekly send cap. A spend ceiling. An audience size above which the agent asks. In the scan example, three product changes shipped and 12,400 people used the parts that changed, but only 4,000 sends were left under the week's cap, so the agent narrowed the send to the best 4,000 and queued the rest for the following week rather than holding the whole thing or blowing through the cap.

Each morning's scan makes one of six calls on each row: draft, propose, narrow, hold, decline, or ask you. Autopilot is one setting among several, and it is off until you turn it on. Ranla's pricing page notes that Autopilot and campaign sending need a paid plan; drafts and proposals across all six jobs work on the free plan.

Opens and clicks are not outcomes. They are what an email tool reports because it cannot see your product. An agent that has shipped your activation and payment events can report the number you actually care about, and it can do it honestly by keeping a holdout.

The activation campaign in Ranla's agent window page is scheduled as "2,000 most recent, 400 a day, 15% holdout." Ranla's default holdout is 10%; this campaign set it to 15%. The 15% never receive the email. At the end of the ramp, activation among the people who got it is compared with activation among the people who did not. The difference is the lift, and the lift is what the work earned. The same page shows the reasoning in the agent's own words: start with the most recent 2,000 and "hold the rest until we see what it earns."

The goal is named up front. Ranla's pricing page lists conversion goals, analytics and holdouts, and revenue as platform features on every plan, and it reads Stripe so that a paid conversion is a real event, not a proxy. When you ask what a piece of work earned, the answer is in the unit you chose when you set the goal.

This matters for the modes above, too. Autopilot is only reasonable when the thing it is optimizing is measured correctly. Variant B scaling because it earned 2.4× variant A over 900 sends is a defensible decision. Variant B scaling because it had a higher open rate is not.

Ranla's pricing page describes the same agent running six jobs, all based on your product events, all included on every paid plan.

Email is one row of six. If what you want is an email platform with a chat box on top, this is the wrong shape, and the section below says so.

This is the move when:

• You run a SaaS product with a self-serve signup and a paid conversion, and the alternative on the table is hiring a growth person or stitching Google Ads, SEO, and an email tool together yourself.
• Your team is small enough that a full-time growth hire is a real budget decision, and you would rather have engineering review the work than hand a contractor admin access.
• Your engineers will accept a pull request from a tool. If tracking changes have to go through code review anyway, an agent that opens pull requests fits the process you already have.
• You can name one goal. Activation, first payment, upgrade. Holdouts need a goal to measure against.

This is not the move when:

• You sell through demos and a sales team. Ranla is built for self-serve motions, not enterprise pipelines.
• You are in healthcare or handle HIPAA data.
• You already pay for Mailchimp, Customer.io, or Loops and want an agent bolted onto it. Ranla runs email on its own stack rather than driving someone else's.
• You only want a transactional send API. That is a different product.
• You want an agency or a we-do-it-for-you service. This is a tool your team operates, with a human approving the parts that matter.

This is what the loop looks like in practice, drawn from the scan and campaign that Ranla's agent window page walks through. Treat the numbers as an illustration, not a benchmark.

Day 1: connect. You enter your website. Ranla reads it, then connects to your repo or your analytics tool and Stripe. By the next morning the first scan has run and the desks have drafts in them.

Day 2: merge the events. The scan found that signup is tracked and activation is not, and opened a pull request that fires an activation event where setup completes. An engineer reviews the diff and merges it. Nothing else should ship before this does.

Day 3: approve the first campaign. The scan previewed a segment of 52,917 people who signed up and never activated, removed 4,112 unsubscribed, bounced, or recent contacts, checked sending health, and drafted a campaign with three angles. You pick the recommended one, adjust the schedule if you want, and approve: 2,000 most recent, 400 a day, 15% holdout. You get a test send first if you ask for one.

Day 4: answer the ads proposal. One Google Ads keyword is spending with no activation behind it. The proposal is to pause it and move its $40 a day to the activation campaign. You approve or decline. The money does not move until you do.

Day 5: review the drafts you did not ask for. The search desk has ranked the questions buyers are typing, from Search Console, and drafted a page for the top one. The social desk has scored a Reddit thread and drafted a reply. You edit and publish the page, and approve or edit the reply.

End of week: read what it earned. The activation campaign has finished its ramp. The report compares activation among the 85% who received it against the 15% who did not. If variant B beat variant A over the first sends, the rollout to the rest of the segment is waiting for a yes, because the remaining audience is over the line you set.

By the second week you have decided which desks can move to Autopilot inside their caps and which stay on Propose. The scan keeps running at 6:00 AM either way.

Ranla's pricing page lists a free plan and four paid plans. Every paid plan includes every feature. The plans differ only in monthly credits, where one credit is a chat with Ranla or 100 emails, and research, images, and pull requests use more.

Contacts are never billed. Google bills ad spend to your own card, and SMS goes through your own Twilio account. If you run out of credits on a paid plan you can add more in Billing; otherwise Ranla pauses, including sending, until the next month.

The free plan is enough to see the loop start. You can watch the first scan, read the events pull request, and see the campaign draft with its holdout before paying anything. No card is required to start free.