Task Agents Get a Scoped Toolset and a Real Brief

July 27, 2026 · InfraScout Team

Task Agents let the AI hand a self-contained piece of work to an isolated run that reports back a conclusion. The mechanism has been in place for a few weeks now, which means we have real runs to look at instead of expectations — and looking at them turned up three separate ways delegation was costing far more than the work required.

None of the three were exotic. Each was a case of a run being handed something it should not have been handed, or not being told something it needed to know.

Every run received the entire catalog

We pulled all thirty-eight delegated runs from our development tenant and added up what they cost. Twenty-three dollars, of which more than half of the Sonnet-class spend went on cache writes — and roughly seven-eighths of that was the same static block of tool definitions and system instructions, rewritten from scratch on every single run.

The reason was a single unexercised code path. A run gets its tool groups from the spawn request or from the parent conversation, and when neither supplies them the code fell through to handing over everything. Across all thirty-eight runs, neither supplied them. Every run received the full builtin catalog plus every registered external tool — around ninety thousand tokens of prefix before it read a word of its brief.

The chat loop already had two mechanisms for narrowing the catalog. Delegation used neither.

Now, when nothing else supplies a scope, InfraScout derives one from the brief: the groups that own tools the brief explicitly names, unioned with a planning pass over the brief itself, plus the core groups every run needs. The set a run actually received is recorded with the run, so an expensive one can be explained rather than guessed at.

The effect is not subtle. Four runs doing identical work on the same day split cleanly by whether their parent conversation happened to carry a tool group: the two that inherited one ran on seventy-one tools and cost one to thirteen cents; the two that did not ran on 327 tools and cost around sixty cents each. Same task, same answer, six to fifty times the price, decided by an accident of context.

Fixing that surfaced a second bug in the same area. The planner was running on those expensive runs, and returning a sensible answer — it correctly identified the vCenter and Splunk servers the brief needed. Then the answer was discarded, because it consisted entirely of custom tool group IDs and the code only kept builtin ones. A verified custom-group selection is now honored, which matters disproportionately: narrowing builtin groups does nothing to the external tool count, and it was the external tools — 130 of them — that made those runs expensive. The custom group takes that 130 to 30.

The same fix for OpenAI conversations

Digging into the planner turned up something worth stating plainly, because we had been claiming otherwise.

"Chat already has two catalog-reduction mechanisms" was true only of the Anthropic path. The OpenAI dialect had neither: no planning pass, and no tool search, since that relies on an Anthropic capability. In our development tenant, across every OpenAI-dialect conversation ever run, not one had a tool group selection persisted. Every turn shipped the entire catalog — roughly 207 tools, every time.

The planner is now dialect-neutral, so scoping applies to OpenAI and Azure Foundry conversations as well as Anthropic ones. If you run InfraScout on an OpenAI-family connection, this is the change in this batch most likely to show up on your bill.

A brief that gives a method, not a menu

Two runs in the sample did the same task, on the same model, on the same day, and differed by a factor of two in cost and by a factor of seven in iterations.

The cheap one named the exact host, the exact path, and the exact tool. Three iterations, zero tool errors, six cents.

The expensive one suggested five typical paths the file might be at, and offered searching the whole filesystem as a fallback. Twenty iterations. Twenty-three tool errors. Every single shell call failed. The brief had handed the run a menu rather than a method, and the run dutifully worked through it.

Two more patterns showed up in the same data. One run spent fifteen of its twenty-one iterations polling an asynchronous job, and two of its siblings hit their deadline still polling — a dollar twenty-two spent to return nothing at all. Another brief prescribed a filesystem search whose output came back at 130 kilobytes, which was then carried through six more turns at a total cost of a dollar seventy-eight.

So delegation now follows a stated structure: the goal, the targets, what is already known, the method to use, when to stop, what is out of scope, and what to report back. The stopping condition and the output bound are there specifically because of those two runs — without them, a run that finds itself waiting on something will wait until the budget is gone, and a run that finds a large answer will carry it forever.

The structure is stated at the point the orchestrating AI writes the brief, and again to the run receiving it, so both ends are working from the same contract.

And where a brief names a tool the run will not be given, InfraScout notices the mismatch and says so in the run's first instruction. The run routes around it immediately instead of discovering the gap through a failed call.

Delegated runs have no memory, and now they know it

A five-scenario test run had one delegation fail outright and another visibly struggle, both because their briefs assumed access to the tenant's AI Memory. The obvious reading was a missing capability.

It is not. It is the design, and the design has a reason.

A delegated run writes only records it owns. That principle is already why a run cannot submit the session it was given — it does not own the session — and cannot change the status of an insight it did not create. Memory is the largest-consequence unowned write available: it is tenant-global, it outlives every conversation, and a run has the narrowest possible view of the environment from which to decide what the whole organization should remember. A run reports findings. The orchestrator, which is talking to you, decides what gets kept.

The actual defect was that nothing said so. The orchestrator wrote memory-dependent briefs, and the runs burned turns discovering a boundary nobody had told them about.

Now the contract is stated rather than detected. The spawn guidance tells the orchestrator that a run has no memory access, that the brief's known-context section is the only channel for prior context, and that persisting whatever comes back is the orchestrator's own job. The run is told the same thing unconditionally.

Stating it beats detecting it here for a reason worth noting: a brief-scanning check structurally cannot catch this one. "Memory" is an ordinary English word on an infrastructure platform — "list the top processes by memory" — so there is no reliable way to tell a tool reference from prose. A rule that is always true is better said once than guessed at repeatedly.

Turns against budget, on the card

One smaller addition that came out of the same review. A delegated run now reports how many turns it has taken against the budget it was given, and that shows on its card in the conversation.

A run heading for its ceiling is now visible while there is still time to do something about it, rather than being something you work out afterward from a run that stopped without concluding.

What you will notice

Mostly, lower cost — sharply lower on anything delegated from an unscoped conversation, and lower across the board on OpenAI-family connections. Beyond that, delegated runs that finish in a handful of iterations rather than grinding through a search, and cards that tell you how far through their budget they are.

Nothing here needs configuring. For the full picture of how delegation works, see Chat. Questions or observations from your own runs? info@infrascout.cloud.