Skip to content

Adjust budgets

On this page you can combine spend rate with ACoS to build daily budget raise/cut candidates, and register a monthly ad spend cap (Budget CAP) in Picaro to monitor utilization. Use it when you want to shift budget toward campaigns with headroom and trim inefficient ones.

ItemDetails
What you can doBuild daily budget raise/cut candidates; register, list, and delete monthly budget caps (Budget CAP); check utilization, pacing, and trends
Applies toMainly Sponsored Products (SP)
Data & connection neededBudget and spend actuals for the connected account (no additional setup)
ScopeVaries by prompt. Daily budget raise/cut candidates and pacing flags = analysis and proposal only / registering and deleting a monthly budget cap (Budget CAP) = records in Picaro (does not change Amazon Ads budgets and does not stop spend) / checking utilization and trends = read-only. Each prompt states its own in “Changes”
  • You want to look at spend rate and ACoS and sort campaigns into which to raise and which to lower
  • You want to set a monthly ad spend ceiling to catch overspending early
  • You want to check how much you’ve spent so far against a registered monthly budget cap
  • You want to list the monthly budget caps you registered before and delete the ones you no longer need
  • You want to find campaigns that are overspending or underspending versus the expected pace
  • You want to decide the priority order for adding budget from the past 90 days of trends
  • Connected account … if you handle multiple accounts, confirm the target account is correct first.
  • Target period / target month … since same-day and previous-day data can be unfinalized, a recent finalized period is safest. If you omit the target month on the cap-related prompts, the current month is used.
  • Target ACoS … if you register it in Set targets for sales, ad spend, and ACoS, the daily budget optimization prompt references it automatically, so you can skip entering it each time.
What you wantWhat you learn / what gets createdChangesPrompt
Build daily budget raise/cut candidates from spend rate × ACoSA list of raise/cut candidates (with current / recommended daily budget)No change (proposal only)Prompt 1
Register a monthly budget cap (Budget CAP) and monitor utilizationA confirmation table of the registered details (target month, cap, warning level, etc.)Records in Picaro (does not stop spend)Prompt 2
Check monthly budget utilization statusA table of spend rate, remaining budget, and recommended daily budgetNo change (read-only)Prompt 3
List and delete registered monthly budget capsA registration list (deletion goes through a confirmation)List is read-only / delete removes the recordPrompt 4
Find campaigns whose pacing is off the expected paceA list of deviations and recommended actionsNo change (proposal only)Prompt 5
Find budget-starved campaigns from 90-day trendsA table of growth rate, days to cap arrival, and bottlenecksNo change (analysis only)Prompt 6
Register a monthly budget cap at the portfolio levelA confirmation table of the registered detailsRecords in Picaro (does not change Amazon budgets)Prompt 7
Check the consistency between the budget cap and portfolio monthly budgetsA list of inconsistencies (unregistered caps, gaps, NO_CAP concentration, etc.)No change (proposal only)Prompt 8
Find campaigns whose daily budget is falling short and propose an increaseA list of increase candidates, defensive allocations, and bid-review-first campaigns (with current / recommended daily budget)No change (proposal only)Prompt 9

For detailed specs, see Automation phases / Troubleshooting.


Prompt 1: Build daily budget raise/cut candidates from spend rate and ACoS

Section titled “Prompt 1: Build daily budget raise/cut candidates from spend rate and ACoS”

From the combination of spend rate and ACoS, sort campaigns into which to raise and which to lower, each with clear reasoning.

When to use — when you want to shift budget toward campaigns with headroom and trim the budget of inefficient ones.

What you need — the target ACoS (auto-referenced if you’ve registered KPI targets), and the minimum daily budget (default is 500 JPY).

Using the most recent finalized week, propose daily budget optimizations against my target ACoS {{TARGET_ACOS (e.g. 15%)}}.
- Spend rate at or above 90% and ACoS at or below target → raise candidate
- ACoS above 1.5x target with spend rate below 50% → cut candidate
Set the minimum daily budget to 500 JPY.

What you can change — the spend rate thresholds and the minimum daily budget (e.g. “spend rate at or above 80%”, “minimum daily budget of 1,000 JPY”). If you’ve registered a monthly KPI target, the target ACoS is referenced automatically, so you don’t have to type it in every time.

What you get back — a table listing, for each campaign, “current daily budget / recommended daily budget / spend rate / ACoS” (with the count of raises and cuts). The prompt specifies that each change stays within +20% / -20% per adjustment.

Changes — no change (proposal only). The actual daily budget does not change until you approve.

Next steps — to actually apply the proposals, use the approval flow in Save rules to systematize proposal approval and monitoring.


Prompt 2: Register a monthly budget cap and monitor utilization

Section titled “Prompt 2: Register a monthly budget cap and monitor utilization”

Record a monthly ad spend cap and warning level in Picaro and enable automatic utilization monitoring. This does not change the budget on the Amazon Ads side.

When to use — when you want to set a monthly ad spend ceiling to catch overspending early.

What you need — the target month, the budget amount, the currency (defaults to Japanese yen), and the warning level (e.g. 80%).

Register the monthly budget cap for {{TARGET_MONTH (e.g. 2026-05)}} at {{BUDGET_AMOUNT (e.g. 1,000,000)}} ({{CURRENCY (e.g. JPY)}}).
Warn me when the spend rate exceeds 80%.

What you can change — the warning level (e.g. 80%) and the currency (defaults to Japanese yen). The daily spend guideline is calculated automatically by dividing the monthly cap by the number of days in the month.

What you get back — a table summarizing the registered details (target month / cap / currency / warning level / registered at). If a cap is already registered for the same month, a confirmation step asks whether to overwrite it.

Changes — records a monthly budget cap in Picaro (does not change Amazon Ads budgets and does not stop spend). Once registered, the daily budget optimization and utilization-monitoring prompts on this page reference it as a guardrail (an automatically referenced ceiling).

Next steps — to check utilization go to Prompt 3; to list or delete registered caps go to Prompt 4.


Prompt 3: Check monthly budget utilization status

Section titled “Prompt 3: Check monthly budget utilization status”

See at a glance the spend rate, remaining budget, and days-remaining-based recommended daily budget against your registered monthly budget cap.

When to use — when you want to check how much budget you’ve used this month and at what pace to use the rest.

What you need — the target month (defaults to the current month). You need to have registered a monthly budget cap in Prompt 2 beforehand.

Goal: catch budget overruns and underspending early, and right-size the daily budget.
Check the ad spend consumption for {{TARGET_MONTH (e.g. 2026-08)}}. Follow these steps.
1. First check whether a monthly budget cap is registered. If it isn't, state "no cap registered" and don't register one on your own. Even if one is registered, when the cap amount is an order of magnitude away from that month's actual ad spend (e.g., an extreme value has been written in by an auto-sync from a portfolio budget), state "the cap is out of line with reality" and don't use its utilization rate as a basis for judgment.
2. If the cap is valid — show the utilization rate, remaining budget, recommended daily budget, and ACoS together.
3. If the cap is unregistered or invalid — provide these as a substitute: (a) the period's actual ad spend, ad-attributed sales, and ACoS; (b) daily budget utilization = actual average daily ad spend ÷ the sum of daily budgets of delivering campaigns (shown per portfolio as well). Do not speculate about what the utilization rate would be if a cap were registered.
4. If the target month is the current month, always state the finalized date range included in the aggregation (start date–end date) and the days remaining, and do not assert the figure as a month-end utilization rate. Add that the most recent few days can still move on re-aggregation.
5. Write items whose value is null / not retrieved as "cannot be retrieved," not as "0." Do not calculate a utilization rate by mixing figures from different data sources.
Finally, output these 3 items.
1. Recommended action — for portfolios/campaigns whose utilization rate (or daily budget utilization) is over 90% or under 50%, present running "Prompt 1 (Build daily budget raise/cut candidates from spend rate and ACoS)" along with the target names (prioritized by the size of the deviation). Exclude anything whose ACoS exceeds {{ACoS ceiling (e.g., 60%)}} from the increase candidates and present it on the decrease side instead. If nothing applies, state "pacing normal, continue monitoring"
2. How to execute it — hand the portfolios/campaigns with the largest deviations, with their ACoS, to Prompt 1 (Build daily budget raise/cut candidates from spend rate and ACoS)
3. Measurement — at {{evaluation date (e.g., 7 days later)}}, re-fetch the gap between the recommended daily budget and the actual utilization rate; if it has been resolved, Keep; if it has worsened, revisit it with Prompt 1

What you can change — the target month (if omitted, the current month is used).

What you get back — a table summarizing “monthly budget cap / month-to-date actual / spend rate / remaining budget / days remaining / recommended daily budget (even distribution over the remaining period)”. If the warning level has been exceeded, a warning is included as well.

Changes — no change (read-only). It does not change any budget.


Prompt 4: List and delete registered monthly budget caps

Section titled “Prompt 4: List and delete registered monthly budget caps”

List your registered monthly budget caps so you can clean up past months or remove mistaken registrations.

When to use — when you want to review caps you registered before, or delete a month you registered by mistake.

What you need — the target month, only when deleting.

Show me the list of registered monthly budget caps.
(If you want to delete one, tell it to delete by specifying {{TARGET_MONTH (e.g. 2025-12)}}.)

What you can change — specify the target month only when deleting.

What you get back — a table summarizing “target month / cap / currency / warning level / registered at”. When deleting, you specify the target month explicitly and a confirmation step asks whether to proceed.

Changes — listing is read-only / deleting removes the monthly budget cap recorded in Picaro (no effect on Amazon Ads budgets or spend).


Prompt 5: Find campaigns whose pacing is off the expected pace

Section titled “Prompt 5: Find campaigns whose pacing is off the expected pace”

Extract this month’s SP campaign pacing and flag campaigns that are off the expected pace by 5% or more.

When to use — when you want to find campaigns that are overspending or underspending versus what you expected, and take action.

What you need — the deviation threshold to flag on (default is 5% or more).

Extract this month's Sponsored Products budget pace and flag campaigns that deviate from the expected pace by 5 percentage points or more. Include the direction of the deviation and a recommended action.
[Fix the data boundary first]
0. Fetch this month's daily ingestion status with get_data_ingestion_status, and treat only days whose status is completed as "finalized days." Do not include fully_missed / in_progress days (usually today) in either the numerator (actuals) or the denominator (day count). State the number of finalized days as D at the top, and align the numerator's target period and the denominator's day count to D in every calculation that follows.
[Definition of the true utilization rate (normalizing the units is mandatory)]
1. Fetch the campaign list with the async version (start_existing_sp_campaigns_job → get_mcp_job_status → get_mcp_job_result). The sync version times out. Pass the finalized date range as from_date/to_date.
2. The budgetUtilizationRate returned is "total spend over the period ÷ one day's worth of dailyBudget" — it carries the unit of "days' worth," not a ratio (over a D-day window it inflates up to D-fold). It must not be treated as a utilization rate as is.
True utilization rate = period spend ÷ (dailyBudget × D) = budgetUtilizationRate ÷ D
Normalize it this way before judging. Every time you give a ratio in your answer, state the numerator, denominator, and day count. For campaigns whose dailyBudget is null, don't calculate a true utilization rate — list their count and names separately.
[Definition of the expected pace (state the basis you obtained)]
3. Check for a monthly budget in the following order and state which one you adopted.
a. check_budget_status (if status is unconfigured, there is no monthly CAP)
b. manage_budget_cap with action=list (read-only; do not run upsert/remove)
c. list_portfolios / get_portfolio_budget_summary (budget_type and cap_amount)
If a monthly cap was obtained: expected pace = monthly cap × (D ÷ the number of days in the month), with actuals using the total spend over the same D days.
If it cannot be obtained: use the median true utilization rate across all ENABLED campaigns as the expected pace, and state that "the median was used as a proxy basis because no monthly budget is set." Do not use the simplistic basis of daily budget × D = 100%.
[Determination]
4. Measure the deviation as the difference in the true utilization rate (in percentage points). Target anything where |true utilization rate − expected pace| ≥ 5 percentage points. Measuring 5% as a relative ratio (a multiple) against the median makes almost everything qualify in accounts with high variance, which is no selection at all — always measure in percentage points. If more than half of all campaigns qualify, state explicitly that the threshold is not working.
[Output]
5. State the rows retrieved / total count / retrieval rate, the target period (the finalized date range and D), and the breakdown by state at the top. Actually compute every campaign, and show the median, maximum, and minimum true utilization rate. If you vary the counts within your answer, state what each count refers to.
6. Write amounts in yen and always double-check the digits (e.g., ¥500,000 is five hundred thousand yen, not five million).
7. Split "overspending" and "underspending" into separate tables, and on each row give the recommended action as a concrete daily budget change in yen or as a percentage change. Derive the change amount from the true utilization rate and attach the formula.
8. Campaigns whose true utilization rate is 80% or more are likely pinned to their daily budget ceiling, so present them separately along with the estimated lost opportunity. Set priority by deviation (percentage points) × period spend, and state that basis.
9. Separate ENABLED campaigns with zero period spend out of the overspending/underspending tables as "not delivering," and note their count and representative examples separately.
Finally, output these 3 items.
1. Recommended action — state the action (change amount / %), the reason, the priority, the expected effect, the confidence, and the risk
2. How to execute it — hand budget reallocation to an approval/execution prompt in the "Adjust budgets" category (a candidate for creation; not in place today). This prompt performs no writes such as budget changes
3. Measurement — after {{evaluation period (e.g., 7 days)}}, re-fetch the true utilization rate and ACoS with the same normalization procedure; Keep if the deviation falls within 5 percentage points, and re-adjust if it does not

What you can change — the deviation threshold (e.g. 5%).

What you get back — a table summarizing “campaign / current spend rate / expected spend rate / deviation / recommended action”.

Changes — no change (proposal only). It does not change ad settings.

Next steps — to adjust daily budgets based on the flags, go to Prompt 1.


Prompt 6: Find budget-starved campaigns from the past 90-day trend

Section titled “Prompt 6: Find budget-starved campaigns from the past 90-day trend”

Analyze account performance trends over the past 90 days, and identify budget bottlenecks from the fastest-growing campaigns and their budget cap arrival status.

When to use — when you want to decide the priority order for adding budget from growth trends and cap arrival status.

What you need — (the target period is fixed to the past 90 days)

Analyze account performance trends over the past {{analysis period (e.g., 90 days)}}, and check the fastest-growing campaigns and budget cap arrival status. Also identify campaigns that are budget bottlenecks.
[Definition of "growth"] Match the last {{analysis period (e.g., 90 days)}} against a prior period of the same length by campaign_id, and calculate the period-over-period change in sales (amount and rate of increase). Do not silently substitute a ROAS ranking or an absolute-sales ranking. For campaigns whose prior-period sales were 0, state "rate of increase cannot be calculated (prior period 0)" — don't write +100% or the like. If it cannot be calculated, state "cannot be calculated (reason)," and don't use a misleading heading such as "by ROAS."
[Data boundary] Today is unfinalized (ingestion status is fully_missed), so always close the analysis window at yesterday. If you produce a time series, don't include a partial week or partial month as the final point of the trend (it gets misread as "a sharp drop"). Past periods can also be re-counted via re-crawl/backfill, so don't present the figures as immutable.
[Handling ratios] Every time you give a ratio, state the numerator, denominator, and number of days alongside it, in a form that makes it possible to tell whether the change came from the denominator or the numerator. A period-over-period difference in ACoS/TACoS is an absolute difference in ratio (points), not bps, so express it in pt.
[Procedure]
1. State the rows retrieved / total count and whether truncated at the top. Accurately record the breakdown of ad types in the aggregation (SP/SB/SD) with counts, and also show the coverage of campaigns for which a period-over-period comparison could be calculated (calculated count / total count). If there is an ad type for which campaign-level detail cannot be retrieved, name that ad type with its count and state "campaign level cannot be calculated — ad-type totals only."
2. Show the top 10 by sales increase in a table sorted by increase descending. Also show the top 5 by decrease, and distinguish whether the decrease came from a budget constraint or from a deliberate pause/reduction, using the change in ad spend and the state (ENABLED/PAUSED/ARCHIVED). State that PAUSED/ARCHIVED items are not eligible for an increase.
3. Determine budget cap arrival across all three tiers — "account monthly budget cap," "portfolio budget," and "campaign daily budget" — for every item, and give the number with no cap set and the number that reached the cap for each, as figures.
- If no cap is set, don't write "0 reached"; write "no cap set, so not eligible for determination" as a distinct case. Even where a cap is set, if the target is stopped (ENDED, etc.), show the number that are active and have a cap separately.
- 🔴 Always calculate the utilization rate yourself as "ad spend over the period ÷ (daily budget × the number of days in the period)." The utilization-rate field the tool returns can still have a one-day denominator with mismatched units, and using it as is inflates the value by the day count and produces a flood of false positives. If you do use the tool's returned value, cross-check that the denominator is normalized over the period, against the values in the response and a manual calculation, before using it.
- 🔴 A period-average utilization rate cannot tell you "whether there were days when the campaign was pinned to its budget cap." If a daily budget-exhaustion signal cannot be retrieved, write "not detectable on a period average (cannot be determined daily)" rather than "no budget bottleneck was detected."
- If the total number of portfolios in the list differs from the number for which budget information could be retrieved, always state the difference in counts and the reason for it.
4. Separate budget bottlenecks from non-budget bottlenecks (deteriorating efficiency, bids, targeting, etc.), and present concrete budget reallocation proposals such as "raise the daily budget by ¥X," prioritized by the size of the lost opportunity.
- For campaigns that haven't reached their cap, state that raising the daily budget alone will not increase delivery volume, and give effective levers (bids, targeting, placements) as alternatives.
- When you attach a determination label (🔴, etc.), state whether it is a value the tool returned or a classification of your own judgment.
[Notes on retrieval]
- A ready-made aggregation surface that returns campaign-level period-over-period figures may ignore the period you specify and return the current calendar month vs. the previous month. Every time, check that the actual period fields in the response match the period you requested; if they don't, don't use that aggregation — fetch the detail for both periods and match them yourself.
- Synchronous list retrieval times out or exceeds the token limit, so use the async job version (start_*_job → check status → get result), and check truncated / total_pages / next_page_token to retrieve everything.
- If the order count (orders) shows a large discontinuity across periods that is inconsistent with the change in sales, don't use it as a period-over-period metric, and say so.
Finally, output these 3 items.
1. Recommended action — state the budget reallocation proposal, the reason, the priority, the expected effect, the confidence, and the risk
2. How to execute it — hand budget reallocation to an approval/execution prompt in the "Adjust budgets" category (a candidate for creation; not in place today). This prompt performs no budget writes whatsoever
3. Measurement — after {{evaluation period (e.g., 14 days)}}, re-fetch sales and ACoS; judge Keep if the growth rate improved and ACoS worsened by 5pt or less, and Revert if it exceeded that. When re-fetching, apply the same [Data boundary] and [Handling ratios] rules and the utilization-rate formula from step 3 under the same conditions

What you can change — (none; it analyzes the past 90-day trend)

What you get back — a table summarizing “high-growth campaigns / days until the budget cap is reached / bottleneck determination”. Useful for deciding the priority order for adding budget.

Changes — no change (analysis only). It does not change ad settings.


Prompt 7: Register a monthly budget cap at the portfolio level

Section titled “Prompt 7: Register a monthly budget cap at the portfolio level”

Register a monthly spend cap (monthly budget cap) in Picaro for a specified portfolio rather than the whole account. It does not change the portfolio budget on the Amazon Ads side; it is recorded as a Picaro-side spend ceiling, and later budget-adjustment prompts reference it automatically as that portfolio’s ceiling.

When to use — when you want to monitor separate spend ceilings per portfolio, such as by brand or by product line.

What you need — the target portfolio (can be specified by name), the budget amount, the currency, and the target month (defaults to the current month).

Register the monthly budget cap for portfolio {{TARGET_PORTFOLIO (e.g. Torani)}} at {{BUDGET_AMOUNT (e.g. 500,000)}} ({{CURRENCY (e.g. JPY)}}).
Don't change the portfolio budget on the Amazon side; record it as a Picaro-side spend ceiling,
so that later budget-adjustment prompts can reference it automatically.

What you can change — you can specify the portfolio by name (the target is resolved internally). If you omit the month, the current month is used.

What you get back — a table summarizing the registered details (target portfolio / cap / currency / target month). If a cap is already registered for the same portfolio, a confirmation step asks whether to overwrite it. When it is no longer needed, you can delete it by specifying the target month.

Changes — records the specified portfolio’s monthly budget cap in Picaro (does not change the Amazon Ads portfolio budget and does not stop spend).

Next steps — to raise or lower the Amazon Ads portfolio budget itself, use Manage the budgets of multiple campaigns together.


Prompt 8: Check the consistency between the budget cap and portfolio monthly budgets

Section titled “Prompt 8: Check the consistency between the budget cap and portfolio monthly budgets”

Cross-check the account-level monthly budget cap (Budget CAP), portfolio-level monthly budgets, and actual ad spend, and detect setup mistakes such as an unregistered cap or an order-of-magnitude mismatch.

When to use — after registering caps in Prompt 2 (Register a monthly budget cap and monitor utilization) and Prompt 7 (Register a monthly budget cap at the portfolio level), when you want to check all at once whether there’s any mismatch between the account-level cap, the portfolio-level caps, and actual ad spend.

What you need — the target account name, and the period to check (e.g., start of this month through yesterday). You can run this even without having registered a monthly budget cap (an unregistered cap is detected and reported as “not registered”).

Goal: to prevent budget overruns and delivery stoppages caused by ad-budget setup mistakes, check the
consistency of {{account name (e.g., Torani)}}'s ad-budget settings.
[Data] Cross-check the following three sources.
① Picaro-registered monthly budget cap (Budget CAP) … fetch "every registered month" from
manage_budget_cap's list (don't look only at the current month — setup mistakes can persist in
past months). Run check_budget_status for each month with a registered cap and for the current
month, and also note the cap's source (manual registration / auto-sync from a portfolio budget).
If a given month has no registration, record it as "not registered" — don't treat that the same as
0 or "no cap."
② Actual ad spend and daily pace … for the current month use get_dashboard's ad spend
({{period start (e.g., start of this month)}} through {{period end (e.g., yesterday)}}); for
period-over-period comparisons use get_portfolio_budget_summary's spend. If check_budget_status
returns status=unconfigured, note that ad_spend also comes back null (not just the utilization
rate) by spec, so state "cannot be calculated because no cap is registered" rather than "there is
no spend," and fill in actual spend from the alternate sources above.
③ Amazon Ads portfolio monthly budgets … cap_amount / budget_type / status from list_portfolios and
get_portfolio_budget_summary (include_ended=true). When budget_type=NO_CAP, treat cap_amount=0 as
"no cap" rather than "a ¥0 cap."
[Analysis]
1. For each month with a registered Budget CAP, calculate the gap (utilization rate) between the cap
and actual spend; if there's an order-of-magnitude gap (several hundred percent or more), report it
as a setup mistake rather than an operational reality, at the highest priority. For caps sourced
from auto-sync, cross-check against ③'s per-portfolio cap_amount and show exactly what was summed.
2. At the portfolio level, calculate the potential spend (sum of ENABLED campaigns' daily budgets ×
remaining days in the current month) and its ratio to the actual spend pace.
3. Detect the following inconsistencies — (a) the current month's Budget CAP is not registered,
(b) actual spend is concentrated in a portfolio with no cap (NO_CAP), (c) an ENABLED campaign
remains under an ENDED portfolio, (d) the cap is an order of magnitude smaller or larger than
actual spend.
[Data quality] Always state the row count from get_portfolio_budget_summary versus the total from
list_portfolios, plus active_campaign_count / total_campaign_count / campaigns_without_portfolio, and
explain any discrepancy. Withhold judgment unless the spend for any unretrieved portion is known.
Also, since there is no read tool that returns delivery status (a servingStatus such as
OUT_OF_BUDGET), limit yourself to an estimate from daily budgets and caps, and don't assert that
delivery has stopped.
Finally, output these 3 items:
1. Recommended action — list, in priority order, portfolios where utilization exceeds 100%, potential
spend exceeds the cap, or the cap is unregistered/off by an order of magnitude from actuals, and
separately propose whether to revisit the cap or revisit bids (propose only — don't execute)
2. How to execute it — for bid revisions, reflect them only after the user reviews and approves the
proposal. For cap revisions, hand off to Prompt 7 (Register a monthly budget cap at the portfolio
level) (this prompt does not register/delete Budget CAPs or change portfolio budgets)
3. Measurement — at {{recheck date (e.g., 7 days later)}}, re-fetch the same 3 data sources and
confirm whether the current month's Budget CAP has been registered, and whether the utilization
rate and potential-spend ratio of the over-budget portfolios have improved

What you can change — the target account name / the check period (e.g., start of this month through yesterday) / the recheck date.

What you get back — the gap between the monthly budget cap (Budget CAP) and actual spend, the gap against the potential spend calculated from portfolio-level daily budget totals, and a priority-ordered list of 4 kinds of inconsistency: (a) the current month’s cap not registered, (b) spend concentrated in a portfolio with no cap (NO_CAP), (c) an active campaign remaining under an ended portfolio, and (d) an order-of-magnitude gap between the cap and actual spend. It also separates out whether the cap or the bids need revisiting.

Changes — no change (proposal only). Nothing is recorded in Picaro and nothing is written to Amazon Ads.

Next steps — if bids need revisiting, reflect the proposal only after the user reviews and approves it. If the cap itself needs revisiting, go to Prompt 7 (Register a monthly budget cap at the portfolio level).


Prompt 9: Find campaigns whose daily budget is falling short and propose an increase

Section titled “Prompt 9: Find campaigns whose daily budget is falling short and propose an increase”

Extract only campaigns with a high spend rate and an insufficient daily budget, and propose an increase that stays within target ACoS / TACoS. Prompt 1 handles both raises and cuts, but this prompt narrows to the shortfall (raise) side only and surfaces the lost opportunity.

When to use — when you want to surface only campaigns with a high spend rate and an insufficient daily budget, and separate those that can be raised from those that need a bid review first.

What you need — the target account name, and the analysis period (a recent, finalized period). You need to have registered the target month’s target ACoS / target TACoS beforehand in Set targets for sales, ad spend, and ACoS (if not set, no increase proposal is made, and setting the targets is requested first).

List {{account name (e.g., Torani)}}'s campaigns with an insufficient daily budget and propose an
appropriate daily budget. Propose only — do not execute. Exclude from the increase candidates any
campaign already exceeding target ACOS/TACOS, and recommend a bid review first for those instead.
[Step 0: resolve the account and finalize the period — required]
1. Resolve account_id from the account name with list_accounts
(list_picaro_accounts only returns the agent list and can't be used for name resolution.
The default account may differ from the target, so pass account_id explicitly on every
subsequent tool call.)
2. Check the finalized data boundary with get_data_ingestion_status, and exclude fully_missed /
in_progress days from the target period. Finalize the start date, end date, and day count (N days)
of the analysis period {{target period}} and state them at the top of your response.
[Execution steps]
3. Check monthly-budget spend status, remaining budget, and recommended daily pace with
check_budget_status
- If status=unconfigured (cap etc. are null), state "Monthly budget Cap: not set" and get actual
ad spend / the sum of ENABLED daily budgets instead from get_portfolio_budget_summary
4. Check each portfolio's ceiling with list_portfolios / get_portfolio_budget_summary
- A portfolio with budgetType=NO_CAP has no ceiling. State "ceiling not set" and don't write a
nonexistent ceiling as a constraint
5. Get the target month's target ACOS / target TACOS with manage_kpi_targets (action=list)
- If the target month has no target ACOS set, state "cannot judge increases — target ACOS not
set," don't issue an increase proposal, and ask for the target to be set first.
Don't substitute a guessed value or another month's value as the target
6. Get the basis data for the increase/decrease amount with optimize_budget
- If target_acos can't be resolved, it hard-errors with
"Target ACOS is unresolved; proposal was not generated." and no proposal is produced. Pass the
target ACOS obtained in step 5 explicitly
- Check the returned target_acos_goal_resolution.basis.kind and state in your response whether it
came from operator_input (a value someone provided) or from the KPI
7. Each campaign's individual ACOS is included in optimize_budget's reason string
(e.g., "Spend rate 259% / ACOS 7.6% → budget-constrained, 50% increase recommended").
Only if it isn't included, fetch it via the async job
start_existing_sp_campaigns_job → get_mcp_job_status → get_mcp_job_result
(the sync version list_existing_sp_campaigns times out; analyze_ad_type_performance is banned
due to a known bug where it returns only a single combined row).
For any campaign you can't retrieve, state "cannot judge — not retrieved" and don't judge it
[🔴 Normalizing the spend rate — required, skipping this flips the conclusion]
The "spend rate" optimize_budget returns is "period-total spend ÷ one day's worth of daily budget,"
not divided by the number of days. Taking an N-day period inflates the value up to N-fold.
- Always normalize to "true daily spend rate = returned spend rate ÷ N days" before judging
- Always list both the "tool-returned spend rate" and the "true daily spend rate" side by side in the
table, and state the numerator (period spend), denominator (daily budget × N), and N
- Run one control call with a 1-day period and confirm it's consistent with the normalized value
- Calculate the account-wide true daily spend rate (= spend ÷ (daily_budget_sum × N)) from
get_portfolio_budget_summary's daily_budget_sum and spend, and confirm it's the same order of
magnitude as the normalized per-campaign results
- After normalizing, any campaign whose true daily spend rate is under 100% is "not budget-constrained."
Don't add it to the increase candidates even if the tool returned "budget-constrained, increase
recommended"
[Rules for using values and metrics — strict]
Every number/metric you cite in your response (ACOS, TACOS, spend rate, daily budget, recommended
budget, etc.) must come only from a value present in a tool result actually fetched this turn. Don't
fill in numbers from prior conversation history, memory, or guesswork. Annotate every cited number
with its source tool name in parentheses
(e.g., ACOS 21.1% (from optimize_budget's reason, as measured)). Don't use a number you can't
annotate. Any value you calculated yourself (normalization, allocation, etc.) must be marked
"calculated value" with the formula shown alongside.
[Output rules for the proposal]
Increase recommended: true daily spend rate over 100% (normalized) AND ACOS within target (actual
retrieved value) → present a proposed daily budget within the bounds of the monthly Cap and portfolio
ceiling. If none qualify, state "none."
Bid review first: ACOS over target (actual retrieved value) → don't increase the budget; recommend
excluding wasted terms or lowering bids instead.
Cannot judge: ACOS or target ACOS is not present in this turn's tool results → state "cannot judge —
not retrieved."
Defensive allocation: branded / catch-all-type campaigns are not included in the increase-candidate
table; list them separately and hold them steady.
[Items required in the output]
Governing (the actual values and source for the monthly budget Cap, target ACOS, target TACOS, and
portfolio ceiling; mark any unset item "not set"), the analysis period and day count, an increase-
candidate table (acquisition-only, sorted descending by true daily spend rate, showing both the
tool-returned spend rate and the true daily spend rate side by side, with ACOS as an annotation
column), a defensive-allocation table, an explicit note on monthly-Cap overrun risk, and a statement
that execution is not performed (no write tools such as execute_proposal are called).
[Handling the effect amount — strict]
optimize_budget's items don't include spend / sales / estimated_impact. Don't present the difference
between current_value and recommended_value (the budget delta) as "additional ad spend" or "savings."
For a campaign whose true daily spend rate is under 100%, raising the daily budget barely increases
actual spend. If you present an effect amount, fetch actual-spend data separately (e.g., from
get_portfolio_budget_summary) and state that source.
If the increase is approved and applied, re-fetch the target campaigns' ACOS and Impression Share
7 days later ("Measure the impact of an initiative"), and present Keep if ACOS hasn't worsened and
share has improved, or Revert if ACOS has worsened by more than 3pt. Approval and execution: reflect
the proposal only after the user reviews and approves it.

What you can change — the target account name / the analysis period.

What you get back — the applied status of the target ACoS, target TACoS, monthly budget cap, and portfolio ceiling (Governing); an increase-candidate table normalized by true daily spend rate (current daily budget / recommended daily budget / true daily spend rate / ACoS annotation); a list of defensive-allocation campaigns excluded from increase candidates (branded / catch-all); and a list of campaigns recommended for a bid review first because they exceed target ACoS.

Changes — no change (proposal only). No write tools such as execute_proposal are called.

Next steps — once an increase is approved, reflect the proposal only after the user reviews and approves it. Re-fetch the target campaigns’ ACoS and Impression Share 7 days later to judge (use Log initiatives and external events and verify their impact for the impact measurement).