- An agent-ready rule has five parts: a trigger, the evidence to gather, the decision logic, the action and the approval tier with a named owner.
- Set autonomy per action rather than per agent. Reversible, low-risk actions can earn the right to run alone; spend changes stay with people longer.
- Write down the exceptions too, and review the run history weekly. That record is how a playbook gets better instead of going stale.
Every growth team has a playbook, even if nobody has written it down. “If CPA jumps for two days in a row, check the landing page before touching bids.” “Never scale a campaign whose product has less than a week of stock.” “During a sale, compare against last year’s sale, not last week.” “Anything over ₹25,000 a day needs the founder’s okay.”
These rules are the team’s real expertise, and most of them live in three places: the heads of the two most experienced people, a Notion page last edited in March, and a few hundred Slack messages. An agent can follow none of them in that form. It can follow all of them once each is written with enough structure to be checked.
What makes a rule agent-ready
A rule an agent can follow has five parts.
- Trigger. The condition that starts the rule, stated in business terms and a governed metric: “CPA on a campaign above its target by 30% for two consecutive days.”
- Evidence. What to check before deciding: landing page status, stock cover, recent budget or creative changes, competitor prices, any team instruction.
- Decision logic. How the evidence maps to a choice, including the “do nothing” branch.
- Action. A named action the system knows how to perform: reduce budget by a stated percentage, pause an ad set, notify an owner.
- Approval tier and owner. Whether the action runs on its own, needs approval, or is only reported, and which person is accountable.
A well-built agent setup works the same way. You give the agent instructions and a model of the business, it turns them into rules that reference business entities, and it sends recommended actions to a person to approve or reject. Writing rules against entities (“a campaign”, “a product”) rather than platform column names is what lets one rule work across Google, Meta and marketplaces.
Worked examples
| Trigger | Evidence | Decision | Action | Tier |
|---|---|---|---|---|
| CPA > target +30% for 2 days | Landing page status, recent changes, stock | If page is broken, fix page; if a change was made < 48h ago, wait; else reduce | Reduce budget 20% or notify owner | Approval |
| Product stock cover < 5 days | Restock date, active campaigns promoting it | If no restock within cover, stop promoting | Pause promotion on that SKU | Auto-run (proven) |
| Search term spend > ₹2,000 with 0 conversions | Term relevance, match type | If irrelevant, exclude | Add negative keyword | Auto-run (proven) |
| Competitor price cut > 10% on a hero SKU | Our price, margin floor, conversion trend | Flag for pricing decision; don’t change bids | Notify founder with evidence | Report only |
| Month-end spend projected > budget by 10% | Pacing by campaign, planned promotions | Trim lowest-efficiency campaigns first | Reduce specific budgets | Approval |
Two things stand out. The evidence column is usually longer than the trigger, which is why these rules fail when agents only see the ad account. And the “Decision” column always includes a branch that does nothing, or does something outside the ad platform. Good playbooks are as much about when not to act as when to act.
Set autonomy per action
Trust in an agent is easiest to manage one action at a time: for each action, decide whether the agent may only observe, recommend, stage it for approval or run it alone. This is graduated autonomy. By default an agent only stages actions for a person to approve, and specific, well-proven processes are promoted to run on their own, with that latitude widened or narrowed centrally. Some lines should stay hard: anything that reaches a customer directly is refused unless a person started it.
- Run on its ownProven, reversible actions: negative keywords, stock pauses
- Stage for approvalSpend and status changes, routed to the owner
- RecommendSuggest with evidence; a person decides
- ObserveRead-only monitoring and reporting
A sensible starting point for a growth team:
- Observe: monitoring, morning briefs, anomaly alerts. No risk; start here on day one.
- Recommend: pricing responses, creative swaps, new audiences. The agent proposes; a person decides and acts.
- Stage for approval: budget changes, pausing or resuming campaigns. The agent prepares the exact change; a named person approves with one tap.
- Run on its own: only actions that are low-risk, easy to reverse and consistently approved. Negative keywords on obviously irrelevant terms and pausing promotion on out-of-stock SKUs are common first candidates.
Write the exceptions down too
Most bad automated decisions come from a rule applied in a situation its author never pictured. The fix is to write exceptions as part of the playbook, in the same structured form:
- Planned pushes. Launch weeks and brand campaigns are judged against their own goals, not steady-state targets.
- Sale periods. Diwali, end-of-season and marketplace sale days are compared with the same event last year.
- Client or founder instructions. “Hold spend on this service until October” overrides the efficiency rules until its end date.
- Data settling. No efficiency decisions on the last two days of data while conversions are still arriving.
Each exception should have an owner and an end date. Exceptions without end dates quietly become the new rules.
Run history is how the playbook improves
Every run should record what triggered it, the evidence it saw, what it proposed, who approved or rejected it and what happened afterwards. Once a week, someone reads that history with three questions: which recommendations were rejected and why, which approved actions had to be reversed, and which rules never fired. Rejections point to missing evidence or exceptions. Reversals point to thresholds that are too loose. Rules that never fire can go.
Keep the review short and regular. Twenty minutes every Monday with the growth lead and whoever approves most actions is enough for a small team. Record each change to a rule with the date and the reason, so that six months later anyone can see why a threshold is 30% and not 20%. This kind of record is sometimes called decision lineage: when a decision was made, on which data and by whom. It is what turns a playbook from a document into a system that learns.
This is also where autonomy is earned. An action that was approved unchanged for several weeks is a candidate to run on its own. An action that was often modified is a sign the decision logic is still incomplete.
A two-week rollout
- Days 1–3: write five rules you already follow, in the five-part format. Pick ones that fire weekly.
- Days 4–7: run them in observe and recommend mode only. Compare recommendations with what the team actually did.
- Week 2: move spend changes to stage-for-approval. Keep every change behind a named approver.
- End of week 2: review the history. Promote one low-risk, reversible action to run on its own if it was consistently right.
Meerkats lets teams turn rules like these into workflows that monitor, investigate, decide, ask for approval and act, with the run history in the same place. The format above works with any tool, though. The discipline of writing the rule down is where most of the value comes from.