lifesight-budget-optimization

name: lifesight-budget-optimization description: > Use when the user wants to reallocate, optimize, or plan marketing budget across channels with Lifesight — "optimize my budget", "where should I move spend", "what's the best allocation for Q4", "how do I hit $X revenue", "should I increase budget", "what if I shift spend from X to Y". Runs the MIA optimization flow cleanly, applies the workspace guardrails, and pressure-tests the result before recommending it. Routed to from the lifesight router after the workspace is calibrated. allowed-tools: Read, Grep, Glob

Lifesight Budget Optimization

The flagship analysis job: turn a budget question into a defensible reallocation decision. The optimizer does the math; your job is the judgment — making sure the answer maximizes the business outcome, not just the metric the tool was pointed at.

Prerequisites (the router handles these): workspace calibrated, profile loaded (model, channels, scale, guardrails). Operate under lifesight-core rules and present under lifesight-rendering. Load both.

Step 1 — Lock the objective BEFORE running anything

This is the most important step and the one a naive agent skips. "Maximize revenue" with no budget constraint will happily buy revenue at a loss (it triples spend for a sub-1.0 marginal return). Decide the objective first:

• Default to fixed-budget reallocation (same total spend, optimized mix) unless the user explicitly wants to change the budget. This is the safe, common case.
• If the user wants growth, frame it as "what's the most efficient way to deploy $X" or "what budget hits $Y revenue at an acceptable iROAS" — never uncapped max-revenue.
• Apply the profile's default_objective and iroas_floor if set.

State the objective in one line and proceed. If the user truly asked for uncapped max-revenue, run it — but you MUST surface the marginal economics (Step 4).

Known MCP limit: a fixed-total-budget request sometimes errors. If it does, run the standard optimization and reconcile to the fixed budget in your reading (note the total delta and the marginal return), rather than presenting an unconstrained plan as if it were fixed-budget.

Step 2 — Walk the gate funnel (one answer at a time)

MIA gates step-by-step. Answer each gate with one value; never re-send the whole request. Typical funnel:

1. Model — already set from the profile; if MIA re-prompts, supply the default model.
2. Constraint strategy — Current / Conservative / Moderate / Aggressive / Custom. Default to Moderate unless guardrails say otherwise; if the profile sets max_channel_change, use Custom with those bounds.
3. Time period — match the user's horizon (e.g. Quarter for Q4).

Completing these gates produces ONE optimization — that's one heavy step. If the session sours (repeated errors), reset and re-align the workspace per lifesight-core Rule 5, then resume.

The optimization is a mandatory gate the chain must pass. A power user may ask for the full package (optimize + forecast + saturation + worksheet). You may run it as a chain — but the moment the optimization returns, apply the Step 4 pressure-test BEFORE doing anything downstream:

• Sound result → continue the chain (forecast, saturation, worksheet), still one heavy call at a time, and deliver the package.
• Value-destroying, self-contradictory, or silently budget-inflating result → HALT. Present the problem and the fix. Do NOT build a forecast or worksheet for a plan that shouldn't ship — that is the exact failure this gate prevents.

Default to presenting the optimization first when the change is large or high-stakes (a 3× budget swing, a board/CFO-bound number); proceeding straight through is fine for a clearly-sound routine reallocation. Never run an unattended pipeline that ignores the optimization's result — the Step 4 check between the optimization and anything downstream is non-negotiable.

Step 3 — Apply guardrails from the profile

Before trusting the output, enforce the customer's rules:

• iroas_floor — do not recommend scaling any channel sitting below it.
• locked_channels — never recommend changing these.
• max_channel_change — flag (or constrain) any move beyond the cap.

If guardrails are unset in the profile, ask the one question that matters ("Any iROAS floor or per-channel caps I should respect?") rather than assuming none.

Step 4 — Pressure-test before you recommend (mandatory)

Run every optimization output through these checks. This is what makes the answer defensible:

1. Did total budget change? If the plan increased spend, say so explicitly and compute marginal return = Δrevenue ÷ Δspend. If marginal < 1.0 (or < the iROAS floor), the incremental spend destroys value — say that plainly.
2. Platform ROAS or causal iROAS? Name which the numbers are. A "grow 100%" recommendation on a sub-1.0 platform ROAS gets a caveat — the causal picture may differ.
3. Do the figures reconcile? Headline totals vs the channel table, and metrics vs each other. If the tool reports contradictory efficiency numbers, flag it and recommend verifying in-platform — don't relay both as fact.
4. Is the reallocation signal still useful even if magnitudes are shaky? Usually yes — separate the trustworthy direction (scale vs cut) from the suspect exact numbers.

Step 5 — Present (via lifesight-rendering)

Use the budget-optimization presentation order: the honest "so what" → optimized mix (clean channel names, signed deltas) → the why (marginal ROI + saturation in plain language) → impact forecast → 2-4 sequenced next actions. Frame the lead line for the persona (CMO / Growth / CFO / Analyst). Curate — don't dump every channel row.

Step 6 — Offer the right next step

Pick 1-2 genuinely useful follow-ups, not a menu:

• "Run the forecast on this plan" · "Weekly pacing worksheet" · "What-if on a specific channel" · "Save this scenario". Only suggest channels that actually exist in this workspace (per the profile).

Red flags — STOP

• About to recommend "adopt max-revenue" without checking marginal return → Step 4.1
• About to call a sub-1.0 channel "high headroom, scale it" → check iROAS floor + platform-vs-causal
• Relaying two different efficiency numbers from one response as both true → flag the contradiction
• Re-sending the whole prompt at each MIA gate → answer the one gate
• Promising to auto-run optimize → forecast → saturation → worksheet in one chain → run the optimization, PRESENT it with the Step 4 pressure-test, THEN proceed; a value-destroying plan stops the chain
• Recommending a move that violates a locked_channel or max_channel_change → enforce the guardrail

Common mistakes