Deep-Research Errands: Run Work Off Your Context
There's a specific failure mode in agent design that doesn't show up until you're running something real: a task that would take five minutes and ten thousand tokens of intermediate search results, page fetches, and refinement — done inline, in the middle of a single turn, burning context the whole time whether or not any of that intermediate work ends up mattering to the final answer. Multi-round research is the canonical example, but it's really any task where the process of getting the answer is much bigger than the answer itself.
WingMan's errand system is built specifically for that mismatch: submit the job, get a job_id back immediately, and let the work happen somewhere that isn't your context window.
What "off your context" actually buys you
submit_errand returns as soon as the job is queued — not when it's done. The multi-round search, page rendering, and refinement for a deep_research job (roughly 1-2 minutes of real work) happens in a background process, not inside the turn that called submit_errand. Your agent's context holds a job_id and nothing else until it decides to check back in. That's the entire value proposition: the token cost of "doing the research" is paid once, by the errand worker, and never touches your context at all — only the final result does, when you choose to collect it.
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"submit_errand",
"arguments":{"type":"deep_research",
"inputs":{"query":"comparison of USDC settlement rails for agent micropayments","max_rounds":3}}}}Three shapes of async work
submit_errand handles three types, each solving a different flavor of "not now, later":
deep_research— multi-round web search → render → refine → a cited markdown report.max_rounds(1-3) trades thoroughness for latency. One in flight per agent at a time, deliberately — it keeps the queue from being flooded by a single agent firing off parallel jobs.fetch_bundle— up to 8 URLs fetched and rolled into a single artifact in one call, for when you know exactly what you want fetched and just don't want the page-render overhead sitting in your own turn.delay— a callback fired after N seconds. The simplest case, but the same shape: submit now, get notified later, don't hold the wait open in your own execution.
job_id you check with check_errand, which reports status and, once complete, the result plus an artifact_url if one was produced. An optional callback_url on submission means you don't have to poll at all if you'd rather be told when it's done.
Watches: the same idea, but recurring
Errands solve "do this once, later." create_watch solves the adjacent problem — "keep checking this, and only bother me when it actually changes." Give it a url, an interval_seconds (minimum one hour), and optionally an extract mode (text, links, code, headings, or grep with a pattern), and it re-checks on that schedule, notifying only on a real diff. That's a durable clock a stateless agent categorically cannot build for itself — there's no process left running between your turns to check anything on a schedule, which is exactly the gap create_watch fills.
The constraints are honest ones: up to 5 watches per handle, auto-expiring after 14 days, auto-pausing after 7 days idle. list_watches doubles as the inactivity check-in that keeps a watch alive — calling it periodically is part of using the feature, not just an accessor. cancel_watch ends one early by its watch_id.
The pattern underneath both
Errands and watches are the same design principle applied to two different time shapes: work that's slow once (errands) and work that needs to happen repeatedly, on a schedule you don't control the timing of (watches). Neither one asks your agent to sit and wait, because sitting and waiting is exactly what a stateless, single-turn agent structurally can't do. Submit it, note the id, and check back — the work happened whether or not you were watching.