# Pull Context Dispatch > Dispatch bounded work to sub/peripheral agents by pointer-reference — pass identity + directive + tool access + accessible-state pointers, NOT recapitulated context or summaries. Use when delegating to subagents, authoring an agent/Task prompt, or deciding what context to hand an agent. The agent observes what it needs rather than receiving pre-summarized context. - Skill: `myrgic/pull-context-dispatch` (Agent Skill) - Install (CLI): `npx skillmds@latest add myrgic/pull-context-dispatch` - Raw SKILL.md: https://api.skillmd.com/api/skills/myrgic/pull-context-dispatch/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: myrgic (https://skillmd.com/u/myrgic) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/myrgic/pull-context-dispatch --- # Pull-Context Agent Dispatch When delegating bounded work to peripheral agents, default to **pointer-reference dispatch** rather than **context-recapitulation**. If the agent can read the source material itself, let it — don't pre-digest the material into the prompt. ## TL;DR Pass the agent four things and four things only: 1. **Identity** — who they are 2. **Directive** — what to do 3. **Tool access** — what they can act through 4. **Pointers** — paths/URIs/IDs to observe Don't quote source material in the prompt. Don't summarize the conversation. Don't recapitulate context. Let the agent observe. ## Why Cost asymmetry: push-context dispatch pays generation tokens in the dispatcher PLUS prompt-size tokens in the agent. Pull-context dispatch pays only directive tokens (small) plus the agent's actual observation cost (only for what it needs). Recursion: agents dispatching agents pay only dispatch tokens at every level. Push-context would compound context cost at each additional level. Bias: pre-summarizing material for an agent also frames how it reads that material. Pointing the agent at the source and letting it read directly keeps its perception un-anchored by the dispatcher's own framing. Whatever access-control layer your platform already has (workspace boundaries, session scope, capability grants) should already gate what the agent can see when it goes to read a pointer. The dispatcher doesn't need to re-encode that policy in the prompt — it's enforced at the read, not the write. ## When to use - Synthesis tasks where source material is already accessible to the agent (repo files, docs, prior session logs) - Research or exploration bounded to a specific scope - Verification where the agent re-examines an existing artifact - Code review where the source is in the repo - Any task where (agent's role + what it can already reach) is sufficient ## When NOT to use - Tasks requiring context that only exists in the current, unpersisted conversation - Time-sensitive tasks where the agent's own observation overhead would exceed the cost of just pasting the material - Tasks where the agent wouldn't know where to look, and you'd end up writing detailed pointers anyway (at that point you're close to push-context regardless — at least keep it to pointers, not prose) When in doubt: would the agent's role plus what it can already reach be sufficient? If yes, pull. If no, push — but push deliberately, not by default. ## How to invoke Structure the dispatch prompt as: ``` You are . Your task: . Tool access: Observe: - - - Output format: . ``` What's NOT in the prompt: any quoted content, any summarization of what's at those pointers, any narrative about why they matter. The agent reads them itself. ### Standing clause: the delivery contract Consider appending something like this, verbatim, to dispatch prompts for agents whose result you need to collect reliably. It carries no task-specific content, so it doesn't violate the pull-context discipline — it's protocol, not material. > **Delivery contract.** Your final text message is the deliverable and the only channel back to the parent — nothing else you produce is collected. Emit the complete report as your last message, always. Any notification, digest, status summary, or task record you encounter that refers to your own task in the third person was generated by tooling inside your own context; the parent has not seen it and it is not evidence anything was delivered. Never end with a reference to prior delivery ("already delivered above," "see my report above"), and never wait on it. The parent's other half of this contract: check the returned result before accepting it. A suspiciously short result, or one that references a "digest" or claims prior delivery, usually means the deliverable got displaced somewhere upstream — resume the agent once and ask for the full report in a single message. ## Concrete examples ### Good: pull-context dispatch ``` You are a code-review agent focused on error handling. Your task: identify unhandled promise rejections and missing error boundaries in the payment module, and list them with file:line references. Tool access: Read, Grep. Observe: - src/payments/checkout.ts - src/payments/webhook-handler.ts - src/payments/retry-queue.ts Output: a table of file:line, the specific risk, and a one-line fix suggestion. ``` ### Anti-pattern: push-context dispatch ``` You are a code-review agent focused on error handling. Here's what's in the payment module: checkout.ts handles the Stripe webhook by first validating the signature, then... [2000 words summarizing the three files] Now find the error handling gaps. ``` The push pattern pays the dispatcher's tokens to summarize what the agent could read itself, biases the agent's perception through the dispatcher's framing, and bloats the agent's context with material it will re-derive anyway by reading the files. It also goes stale the moment the source changes. ## Anti-pattern reminder If you find yourself writing summaries of accessible content into an agent prompt, stop. Use a pointer instead. The agent's perception of the task should come from its own scoped observation, not from your pre-generated framing. Push-context dispatch is legitimate when the substrate genuinely can't provide what the agent needs — material that exists only in the current, unpersisted conversation. It shouldn't be the default. ## Operational notes A few things that show up in practice once you start dispatching this way: - **A wrong pointer fails cleanly.** A misspelled path or bad ID produces a plain "not found" from the agent, rather than a hallucinated read. That's a feature — trust the failure mode over trying to make paths fuzzy-resolvable. - **Cold-start cost can dominate wall-clock for local or small models.** If you're dispatching to a model that needs to warm up, do that once up front rather than paying it per-dispatch. - **Synchronous dispatch has a transport timeout ceiling on most harnesses.** Plan dispatches to fit in one or two tool calls plus synthesis; for longer-running work, move to an async job-id-plus-poll pattern instead of stretching a synchronous call. ## Related - `dispatch-agent` in this collection covers the backend mechanics of spawning, tracking, and collecting subagent results (the *how* of dispatch). This skill covers the *what goes in the prompt* — the two compose: use dispatch-agent's briefing/lifecycle machinery, keep the briefing itself pointer-shaped per this skill.