A sane bidding rulebook moves a bid only when three gates agree: the n-gram clears data sufficiency (1-grams need IMP_g >= 50 and either CLK_g >= 10 or ORD_g >= 2), ACoS sits outside a deadband of 0.9x to 1.1x target, and the change fits a daily clamp of plus or minus 20%. Top-of-Search multipliers cap at 1.50, every action carries a 5-day review window on Ads, and when two rules collide a fixed precedence ladder decides, with pull-back beating scale on ties unless credible intervals say otherwise.
A bidding rulebook stops thrashing when a bid can only move after three independent gates agree: the n-gram clears data sufficiency, its ACoS sits outside a deadband around target, and the resulting change fits inside a hard daily clamp. That is the whole answer. I handed the question to our agent, which runs it as a Skill over the Amazon Ads MCP, grounded by Amazon Agent Atlas in two corpus playbooks: the Keyword Analysis Decision Framework (N-Grams) and the Sponsored Ads Bidding Configuration Decision Framework. The question that sent me looking came from our PPC lead, in Slack, on a Tuesday: every tool she had used either overcorrected or undercorrected, and she wanted to know what a sane rulebook actually looks like underneath.
Ask a plain ChatGPT or Claude chat and you hit three walls on any Amazon job. It has no access to your data: it cannot read your search-term report, your ad group configuration, or your trailing 30-day spend, so you paste a CSV that is stale the moment you paste it. It has no way to take action: it cannot change a bid, set a placement multiplier, or add a negative, so the most you get is text you retype into Campaign Manager by hand. And it runs on generic public knowledge, not Amazon's: it will produce thresholds that sound right and are not. The result is disconnected, generic, manual work that ships silent mistakes into a live account. The Amazon Ads MCP supplies your data and the tools to act on it, Atlas supplies the private rule book, and the Skill supplies the bounded workflow that keeps the two honest.
Thin data gets a hold, not a bid change
Most thrash is not a bad threshold, it is a threshold applied to a sample too small to mean anything. The rulebook gates on sufficiency before any rule is allowed to evaluate. For 1-grams that means IMP_g >= 50 and either CLK_g >= 10 or ORD_g >= 2. Longer n-grams need proportionally more: 2-grams require IMP_g >= 100, 3-grams IMP_g >= 150, with the same click-or-order condition.
There is a second gate one level up, at the ad group. The starvation guard in the Sponsored Ads Bidding Configuration Decision Framework holds everything when CLK_l30d < 50 and ORD_l30d < 5. The prescribed action is hold_thin_data with no destructive change, and the advice is to consolidate or extend the observation window rather than act early. An agent that respects both gates spends most of its first run reporting that it is not going to do anything yet.
Scale and pull-back fire at fixed distances from target
This is the part that actually prevents thrash. The scale rule and the pull-back rule do not trigger at target ACoS, they trigger at fixed distances on either side of it, leaving a gap where nothing happens at all.
A scale decision needs ORD_g >= 10 and ACOS_g <= 0.9 x TARGET_ACOS, and produces increase_bid at +5 to 10% on keywords containing that n-gram. A pull-back needs ORD_g >= 10 and ACOS_g > 1.1 x TARGET_ACOS, and produces decrease_bid at -10%, plus a 10% reduction to the Top-of-Search multiplier if one is in use. Both re-evaluate in 5 days.
Between 0.9x and 1.1x of target, no bid rule fires. That deadband is the single most load-bearing number in the rulebook. A bidder without one sits exactly at target and oscillates forever, correcting every run in whichever direction last week's noise pointed.
| Condition | Action | Re-eval |
|---|---|---|
ORD_g >= 10, ACOS_g <= 0.9x target | increase_bid +5 to 10% | 5 days |
ORD_g >= 10, ACOS_g > 1.1x target | decrease_bid -10% | 5 days |
| ACoS inside the deadband | none | next run |
ROAS_g >= target, impressions bottom quartile | increase_bid +5 to 8%, TOS +10% | 5 days |
Every lever is clamped before it ships
Gates decide whether a rule fires. Clamps decide how far it can go when it does. The global controls are short enough to memorize: a daily bid change clamp of plus or minus 20%, a Top-of-Search placement cap of 1.50, and a standard review window of 5 days for Ads and 7 to 14 days for Organic and Ops work.
The clamp matters most in the case where the rulebook is most confident. An n-gram at half of target ACoS with 200 orders is a genuinely strong signal, and the temptation is to move the bid a long way at once. The clamp refuses. Twenty percent per day, then look again in five days. Every decision record the agent emits carries its own max_change_pct and cooldown_days, the latter defaulting to 5 to 14 depending on the action type, so the bounds travel with the decision rather than living in a settings page nobody re-reads.
{
"decision_category": "scale_winner",
"action_id": "increase_bid",
"action_scope": ["ADS"],
"selector": { "ngram": "stainless steel", "n": 2, "match_type": "phrase" },
"magnitude_pct": 8,
"max_change_pct": 20,
"cooldown_days": 5,
"confidence": "high",
"reason": "ORD_g=31, ACOS_g=0.19 <= 0.9 x TARGET_ACOS(0.25); sufficiency met",
"badges": { "data_sufficient": true, "cooldown_ok": true, "thin_data_reason": null }
}Precedence decides which rule wins
Real accounts produce conflicts. A keyword can look wasteful on one metric and efficient on another, and two rules will match the same entity in the same run. Rather than letting whichever rule evaluated last take the entity, the framework fixes an order: invalid computations first, then thin data, then safety negatives, then pull back, then scale, then mining and hygiene, and creative or ops work last.
The tiebreak is explicit and conservative. When a rule suggests both scale and pull-back, prefer pull-back, unless credible intervals support scaling with high confidence. That is where the reliability layer earns its place: the recommended signals are Bayesian credible intervals at 95%, Beta for CTR and CVR, Gamma for spend and revenue ratios, alongside recency weighting with a 14-day half-life and peer medians computed with trimming. The interval, not the point estimate, is what lets a scale decision beat a pull-back decision.
What happens next
The output is a decision plan, not an applied change. Each record names the entity, the bounded action, the clamp, the cooldown, and the reason it fired, which makes it reviewable before anything reaches the account. That review step is the same pattern as a human approval gate on Amazon Marketing Cloud activation: the agent assembles the artifact, a person signs it, the platform ships it.
Once a plan is approved, the review windows do the pacing. Ads actions re-evaluate in 5 days, Organic and Ops in 7 to 14, and each record's cooldown_days prevents the next run from touching an entity still inside its window. Wired as a recurring Skill over the Amazon Agent Data layer, the agent reads a fresh rollup, skips everything on cooldown, and emits a much shorter plan the second week. A rulebook that is working produces fewer decisions over time, not more. The Selling Partner MCP covers the catalog side of the same account when a decision turns out to be a listing problem rather than a bidding one.
The pattern is worth stating plainly: bounded actions with explicit gates beat continuous optimization because they are auditable, and an agent that can explain why it did nothing is more trustworthy than one that always has a change to make.
Next: the data-mode router, and why computing ACoS on organic search-query data is the fastest way to poison a rulebook.
Run the rulebook instead of arguing with it
Bring us the bidding workflow you want your agent to run. We'll map the gates, clamps, Amazon Ads MCP, Atlas grounding, and private-beta setup with you.
Run this workflow in betaWhat you need to run this
- Required subscriptions
- Amazon Ads MCP connected to a Sponsored Products or Sponsored Brands account
- Skill
- Bidding rulebook Skill, run against a search-term or n-gram rollup
- Atlas collection
- amazon_rules (Keyword Analysis Decision Framework, Sponsored Ads Bidding Configuration Decision Framework)
- Lookback window
- Trailing 30 days for ad group configuration signals; rule window set per run
- Last verified
- "2026-07-26T00:00:00.000Z"
What success and failure look like
| scenario | success | failure |
|---|---|---|
| N-gram clears sufficiency and sits under the deadband | One `increase_bid` decision at +5 to 10%, clamped, with a 5-day re-eval | A bid increase on an n-gram with 12 impressions |
| Two rules match the same keyword | Precedence ladder emits exactly one decision record | Two opposing bid changes applied in the same run |
| Ad group below the starvation guard | `hold_thin_data`, no destructive action | A bid cut justified by four clicks |
Keep exploring this topic
Use these companion guides to understand the inputs, follow-on analysis, and adjacent workflows behind this playbook.
FAQ
What is bid thrash?
Bid thrash is a bidder raising and lowering the same bid across consecutive runs because it reacts to noise instead of signal. The deadband between 0.9x and 1.1x target ACoS is what stops it: inside that band no rule fires at all.
How much data does an n-gram need before a bid can move?
For 1-grams, `IMP_g >= 50` and either `CLK_g >= 10` or `ORD_g >= 2`. 2-grams need `IMP_g >= 100` and 3-grams need `IMP_g >= 150`, with the same click-or-order condition.
How much can a bid change in a single day?
Plus or minus 20%. The daily bid change clamp is a global control, so no single rule run can move a bid further than that regardless of how far off target the n-gram is.
What happens when a scale rule and a pull-back rule both match?
Pull-back wins. The precedence ladder runs invalid computations, thin data, safety negatives, pull back, scale, mining, then creative and ops. Scale only beats pull-back when credible intervals support it with high confidence.
Why does my bidder recommend no action on a keyword that is clearly losing money?
It is almost always the starvation guard. When `CLK_l30d < 50` and `ORD_l30d < 5`, the rulebook emits `hold_thin_data` and stops rather than acting on a sample too small to trust.
How high can a Top-of-Search placement multiplier go?
1.50 is the cap as a global control. A scale rule that raises Top-of-Search by 10% still cannot push the multiplier past that ceiling.
How long before a rule re-evaluates the same entity?
The standard review window is 5 days for Ads and 7 to 14 days for Organic and Ops actions. Every decision record also carries its own `cooldown_days`, defaulting to 5 to 14 depending on action type.