Task Agents: The AI Plans Its Work and Delegates It
July 9, 2026 · InfraScout Team
A serious assessment is rarely one question. "Review the domain controllers" really means: figure out which hosts matter, check each one's event log, pull identity configuration, then reconcile all of it into a conclusion. Until now the AI carried all of that in a single conversation — every intermediate reading, every raw command output, every dead end — and you watched it happen as an unbroken stream of tool calls with no visible structure.
This release gives that work a shape. The AI now maintains an explicit task plan for the conversation, and for the parts of the plan that stand on their own, it delegates: it spawns a Task Agent, an isolated run that does the work in its own context and reports back only the conclusion. You get to see the plan form, watch the delegated runs execute, and read what each one found — without the conversation drowning in the raw material that produced it.
A plan you can watch take shape
When the AI takes on work with more than one moving part, it writes down a plan. Each task moves through a simple lifecycle — pending, then in progress, then either completed or cancelled — and tasks can declare that they depend on other tasks. A synthesis step that needs three host reviews finished first says so explicitly, and it will not start until those reviews are done.
The plan renders as a live panel in the conversation. As the AI works, tasks light up and settle, so you can see the assessment's shape as it forms rather than inferring it from a stream of tool calls. Tasks whose dependencies are not yet satisfied show as locked, which tells you at a glance what the AI is waiting on and why it hasn't started something you expected it to start.
This matters most on long reviews. A plan you can read is a plan you can correct — if the AI's decomposition of the problem is wrong, you see it early, while it's still cheap to steer, instead of discovering it in the summary at the end.
Delegating to a Task Agent
Some tasks are self-contained: "check the event log on this host for authentication failures in the last 24 hours" needs no context from the rest of the conversation and produces a small answer from a large amount of raw data. That is exactly the work the AI now delegates.
When it delegates, InfraScout spawns a Task Agent — a nested run with its own fresh context window, given a brief and a scoped set of tools. It does the work independently and finishes by submitting a distilled result: a summary, the findings it made, and the references behind them. Only that conclusion crosses back into your conversation. The hundreds of lines of event log the run waded through to get there do not.
The point is not tidiness, it's headroom. The main conversation's context stays clean, so the AI can hold the whole assessment in mind instead of spending its attention on raw output it has already interpreted. And because each run is independent, the AI can fan several out at once and work through a fleet of hosts in parallel rather than one after another.
Nothing is lost by keeping the transcript out of the conversation. The full record of what a delegated run did — every tool call, every result — persists for audit, and you can open it whenever you want it. The conversation shows you the conclusion; the audit trail keeps the evidence.
Read-only by default
Delegation is the AI's call — it decides what to hand off and how to scope it, the same way it decides which tool to reach for. What is not its call is the default it gets handed: a delegated run is read-only unless it explicitly asks otherwise, and read-only here has a precise meaning — the run may not change the host it is assessing.
That boundary is structural, not advisory. Host-mutating tools are simply absent from a read-only run's toolset. There is no instruction it can be talked past, because the capability was never handed to it in the first place — which matters more than usual here, since a delegated run's context fills up with raw output from the host it is investigating, and that is the last place you want a safety rule to live.
Within that boundary a read-only run is far from helpless. It can still do everything an assessment actually needs:
- Open a session against the target host
- Query the Windows event log
- Read system state through WMI
- Query directory data over LDAP
- Pull a host summary
- Read log files
- Save the insights it produces, which persist like any other finding
That last one matters. A run delegated to find something must be able to record what it found, so saving insights stays available to read-only runs — those write into InfraScout's own audited records, never into the assessed host.
If a run genuinely needs to change something on the host to complete its brief, it doesn't improvise and it doesn't quietly give up. It stops, reports that it failed, and names the tool it needed. That answer goes back to the conversation, where changing a host is a decision that runs through you: the orchestrating AI tells you what it intends to change and waits for your go-ahead before it acts. The delegated run cannot route around that, because it never had the tools to.
INFO
You do not configure any of this per run. Read-only is the default a delegated run is born with, and the escape hatch from it leads back through the conversation — and therefore through you.
Turns don't end half-finished
A plan is only useful if it stays honest. Previously a turn could end with tasks still sitting in progress — the AI had moved on, but the plan still claimed work was underway, and you had no way to know whether it was abandoned or forgotten.
Now, when a turn is about to end with tasks still open, InfraScout reminds the AI once to close each one out: mark it completed, cancel it, or explicitly defer it. The reminder appears in the conversation as a distinct system note, so you can see it happened. It fires at most once, and the turn ends afterward regardless — the AI never gets stuck in a loop trying to satisfy the plan. What you get is a plan whose final state means something.
Blocked is not the same as waiting
Dependencies come with a distinction worth knowing about. A task waiting on a dependency that is still pending is simply waiting — the gate will open once that dependency completes. But a task waiting on a dependency that was cancelled is waiting for something that will never arrive. A cancelled task is terminal, and only a completed dependency unblocks the task that needs it.
The AI is now told those two situations apart. Instead of retrying a gate that can never open, it recognizes a permanently blocked task for what it is and re-plans: it cancels the dead task and, if the work is still worth doing, creates a replacement that doesn't depend on the abandoned branch. A cancelled dependency doesn't silently satisfy the tasks downstream of it — that would let a synthesis step report success over inputs that were explicitly abandoned. Recovery is a deliberate re-plan, and you see it happen in the plan panel.
Task Agent cards in the chat
Each delegated run renders in the conversation as its own card, laid out to be read rather than decoded. The run's brief is the card's title, and beneath it you get the summary the run submitted, its findings, and a quiet metadata footer with the details you only want when you want them.
Status on the card is honest. A run that has finished stops spinning. A run that is queued but hasn't started says so. And you no longer have to wait for a run to finish before you can look inside it — you can open the live transcript of a Task Agent while it is still working, and refresh it as it goes. If you're watching a long fan-out across several hosts, each card settles on its own as its run completes, instead of all of them waiting on the slowest sibling.
The same card shows up in the Chat Audit view in administration, so reviewing a conversation after the fact gives you the same structure, with the full delegated transcript one click away. See Chat Audit for how to browse conversations and their delegated runs.
Delegated spend is visible
Task Agent runs call a model, and calling a model costs money. Because delegated runs are kept deliberately separate from the conversation that spawned them, none of that spend showed up in any cost figure InfraScout displayed — and it is not a rounding error. On real assessments, delegated work routinely costs more than the conversation orchestrating it. Conversations that reported around a dollar had actually spent four.
That gap is closed. Delegated spend now appears everywhere conversation cost already did: in the chat footer while you work, in the cost column and detail view of the Chat Audit, and in the usage figures on the administration dashboard. The chat footer also refreshes as the conversation goes, rather than freezing until you reopen it.
Crucially, the number is broken out rather than merged. Wherever a conversation delegated work, you can see the split between what the conversation itself spent and what its Task Agents spent, so a rising bill tells you where it's rising. Conversations that delegated nothing look exactly as they always did.
INFO
The cost breakdown appears only on conversations that actually delegated work. If a conversation shows a single combined figure, it means no Task Agents ran in it.
Try it
Open a conversation in the InfraScout portal and give the AI something genuinely multi-part — a review across several hosts, or an investigation that has to gather before it can conclude. Watch the plan panel fill in, watch the Task Agent cards appear and settle, and open one mid-run to see what it's doing. Then check the cost in the footer and see how much of the work was delegated.
If you want assessments that run this way without you in the chat at all, pair Task Agents with Agentic Workflows — a workflow's run gets the same planning and delegation, on a schedule or a webhook. Questions or feedback? Reach us at info@infrascout.cloud.