delegate-heavy-context

When a task risks dumping large tool output into the main thread, run this procedure. Codifies the Tier-0/1 levers from context-and-cost-economy.md.

When to use

• You are about to call browser_snapshot or run a Playwright session
• You need to tail logs, read a large file, or run a wide DB aggregate
• A subagent could return a verdict / count / extracted value instead of the raw dump
• The session is approaching a cost limit

Step 1 — Clarify the goal first

Before opening any tool, ask: what specifically needs to be verified or extracted?

If the goal is underspecified ("check if the feature works"), ask one focused question before acting. A clear goal lets you pick the cheapest path in step 2 rather than exploring blindly.

Step 2 — Apply Tier-0 pruning

Can the heavy output be eliminated at source?

Heavy operation	Tier-0 alternative
browser_snapshot to find a value	browser_evaluate("document.querySelector(...)...textContent")
browser_snapshot to check an API	browser_network_requests + filter by URL
Read a 1000-line file to find a function	grep -n "functionName" <file> or Read with offset+limit
Full DB query result	Project only needed fields; add a LIMIT
Re-snapshot to "remember" page state	Write a one-line text state instead

If Tier-0 eliminates the heavy output, you are done — no subagent needed.

Step 3 — Wrap in a subagent

When heavy I/O is unavoidable, run it in an Agent call and return only the verdict.

Template:

Agent(
  "<goal>. " +
  "Success condition: <what pass looks like>. " +
  "Return format: <pass|fail + first mismatch> / <extracted value> / <count>. " +
  "Prefer browser_evaluate over browser_snapshot. " +
  "Config/credentials: <file path, not pasted value>.",
  { subagent_type: "bewith:qa-engineer" }  // or Explore, general-purpose, etc.
)

Rules for the subagent prompt:

• State the goal and success condition first.
• Specify the return format — a verdict, a number, extracted JSON. Not a prose narrative.
• Name the cheap tool to prefer (e.g. "prefer browser_evaluate over browser_snapshot").
• Point to files/env refs rather than pasting content.

Suitable for: Playwright UI verification, log search, large-file analysis, DB aggregation.

Step 4 — Choose the model tier

Work type	Model
Mechanical: transcription, grep, doc draft, lint, format conversion	Sonnet / Haiku
Hard reasoning: root cause, design decisions, multi-step debugging	Opus
Large context genuinely required (>200 K)	Opus with 1 M window — only when the task truly needs it

The 1 M-context window is a cost multiplier. Do not default to it.

Step 5 — Maintain a text state model

After each browser or long-running action, write one line of state:

[state: logged in as admin, on /events, filter = July 2026, export button visible]

This text survives context compaction; a snapshot does not. One state line replaces the need to re-snapshot after every interaction.

Red-flags table

Rationalization	Cheaper move
"I'll just snapshot to check what's on the page"	browser_evaluate for the specific value; or ask what to check
"Let me read the whole file to find the function"	grep -n or Read with offset+limit
"I'll paste the diff so I have it handy"	Write to a temp file; Read it on demand
"I need to re-snapshot after every click"	Write a text state line; snapshot once at the key decision point
"The log is 5000 lines, I'll read it all"	grep for the error pattern; or delegate to an Explore subagent
"I'll use Opus — it's just writing a summary"	Summary writing is mechanical — use Sonnet
"I need more context, let me snapshot again"	Ask what specifically to verify; then use browser_evaluate
"I'll open the browser and explore"	State the goal first; pick the cheapest extraction path