Lifesight Core

Lifesight Core — Operating Rules for the Lifesight MCP

These rules apply to EVERY response in a Lifesight conversation, before any other skill. They exist because the Lifesight tools behave in specific ways that, unmanaged, crash the conversation or leak internals. Follow them exactly.

The companion skill lifesight-rendering owns how output looks and reads (voice, numbers, channel names). This skill owns how you operate the tools. Load both.

The tools, by weight — know this before you call anything

The single most important fact: ask_mia summarizes for you; query_ad_data does not. When a question could go to either, prefer ask_mia.

What counts as "one heavy step": the chain of gate-answers that completes a SINGLE ask_mia analysis (e.g. model → constraint → period to produce one optimization) is one step — finishing those gates is expected. But two DISTINCT analyses — an optimization and then a forecast, or a saturation run, or a worksheet build — are separate steps. Present the first before you start the second. Do not pre-commit to running the forecast/saturation/worksheet in the same turn as the optimization.

Rule 1 — One heavy call per turn. Never chain.

ask_mia and query_ad_data are heavy. In a single turn, call at most one.

• ❌ Do NOT fire query_ad_data and ask_mia and get_current_budget to answer one question. That is the most common way conversations flood and die.
• ✅ Make one heavy call, present the result, then offer the next step.

If a request needs two heavy calls, that is two turns. Do the first, show it, continue.

Even when the user demands "all of it, don't make me wait" — you still run ONE heavy step, PRESENT it, then continue. Do not pre-commit to auto-running a chain of heavy calls (optimize → forecast → saturation → worksheet → raw pull) across the turn. The present-then-continue checkpoint is not friction — it is where judgment lives: if the optimization comes back value-destroying or self-contradictory, you must NOT go on to build its forecast and worksheet. It is fine to outline the plan and ask the one question that unblocks it; it is not fine to execute it as an unattended heavy-call pipeline. Run step one, show the result (with its sanity checks), and let that result decide the next step.

Rule 2 — Decompose before you pull.

A multi-part question is multiple steps, not one giant query. Before any heavy call, break the request into the smallest first step that produces something useful, run only that, present it, then continue.

User: "Optimize my budget, forecast it, and show me where I'm saturated." ✅ Run the optimization first (one ask_mia call). Present it. Then offer: "Want the forecast next, or the saturation view?" — each is its own turn.

Rule 3 — query_ad_data is narrow-only. Never dump rows.

query_ad_data returns raw rows and will flood the context window if asked broadly. Every query_ad_data question MUST be scoped:

• One metric (or a small named set) — not "all metrics".
• One breakdown dimension — by channel OR by campaign, not both at once.
• A bounded timeframe — a specific range, not "all time".
• Aggregated — totals, averages, top-N. Not row-per-day-per-campaign.

If the user genuinely wants granular analysis (saturation, marginal ROI, what-if, optimization), that is an ask_mia job — it summarizes. Route it there instead of widening query_ad_data.

If a user insists on a broad raw pull, narrow it for them and say what you did: "That would return thousands of rows. I've pulled the top 15 campaigns by spend instead — tell me which to drill into." Never silently fire the broad query.

Rule 4 — ask_mia is stateful and gates. Walk the funnel.

ask_mia remembers the selected model and scenario across calls in a session, and it asks for what it needs one step at a time (model → constraint strategy → output). Do not try to pre-answer everything in one giant prompt. When it returns a gate (a numbered menu, a "pick one", a clarifying question):

1. Surface the choice to the user in plain language (or pick the sensible default and say which — e.g. "I'll use the Moderate constraint unless you'd prefer tighter or looser bounds").
2. Pass the single answer back. Let MIA advance to the next gate.

Do not re-issue the whole original request at each gate — just answer the gate.

Session hygiene: if you switch the analytical context (different model, different question family, or you just switched workspace), call reset_mia_session so stale model/scenario state doesn't bleed in.

Rule 5 — Resolve workspace + model ONCE, up front.

Before the first heavy call, make sure the right workspace and model are set — not mid-task. ask_mia requires a model; some workspaces have none, some have several. The router/intake step handles this. If you arrive here without it:

1. list_workspaces → confirm the active one is the user's intended account. Switch with set_active_workspace if not (this resets the MIA session).
2. list_models → if zero, tell the user a default scenario must be configured in the platform UI first. If multiple, ask which (or infer from the user's stated KPI — Revenue vs Installs).

Resolve both before analysis. Don't let MIA re-prompt for the model mid-flow.

If a lifesight-workspace-profile exists, it already names the default model, channels, scale, and guardrails — load it instead of re-discovering. If none exists, the router runs lifesight-calibration first. Note: if reset_mia_session ever leaves the workspace reporting zero models, re-align with set_active_workspace to recover the default (a known MCP quirk).

Rule 6 — Never leak internals into user-facing text.

The Lifesight tools sometimes surface raw internals. The user must never see them. Render the meaning, not the plumbing.

Never appears in chat:

• Raw column names: apple_search_spend, spend_meta, Google_pmax_spend, X_spend, tvcm_spend → use clean display names ("Apple Search Ads", "Meta", "Google PMax", "Twitter/X", "TV"). Use the channel map from the lifesight-workspace-profile if present, else derive clean names with the rule in lifesight-rendering. Channel names are per-workspace — never assume a fixed set.
• Infra paths and identifiers: projects/<gcp-project>/..., dataAgents/agent_..., BigQuery dataset names, internal IDs.
• Tool names and call narration: never type ask_mia, query_ad_data, set_active_workspace into chat, and never narrate "Let me call…", "I'll run the query…", "switching tools because…". The user wants the answer, not the method.

When a tool errors, do not paste the raw error. Reframe in one plain line about the outcome: "I couldn't reach the ad-performance data for this workspace — it looks like a permissions setup issue on that account. Want me to try a different workspace, or work from the measurement model instead?" No GCP paths, no stack traces, no agent IDs.

Quick reference — the operating loop

1. Workspace + model resolved?           → if not, fix it first (Rule 5)
2. Is this a methodology "how/why" Q?     → search_knowledge_base (light)
3. Is this granular analysis?             → ask_mia, one call, walk its gates (Rule 4)
4. Is this a small specific data lookup?  → query_ad_data, narrow + aggregated (Rule 3)
5. Multi-part request?                    → decompose, do step one only (Rule 2)
6. Present the result via lifesight-rendering (clean names, causal voice)
7. Offer the single most useful next step

Red flags — STOP, you're about to crash the conversation

• About to call two heavy tools in one turn → stop, do one (Rule 1)
• About to ask query_ad_data for "everything / all / by-day-by-campaign" → stop, scope it (Rule 3)
• About to paste a long raw table or error blob into chat → stop, summarize or reframe
• About to type a tool name, column name, or GCP path into chat → stop, render the meaning (Rule 6)
• MIA returned a menu and you're re-sending the whole original prompt → stop, just answer the gate (Rule 4)
• User says "do it all at once / don't make me go back and forth" and you're about to promise an auto-chain of heavy calls → stop, run one step, present it, then continue (Rule 1)

Common mistakes