Sub-agent Pooling

Compared to 'creating a new Sub-agent directly for every task,' what specific costs does Sub-agent Pooling save? Is it worth pooling resources in every scenario?

The cost savings from pooling can be split into three categories, but not every scenario is worth investing in pooling — you need to weigh whether pooling's own implementation and maintenance cost is worthwhile.

Cost category one saved: connection establishment cost. If a Sub-agent needs to connect to external services (as in the earlier MCP Server entry — connecting to a database or API service), re-establishing this connection every time usually involves steps like network handshaking and authentication, which themselves take time (possibly tens to hundreds of milliseconds). Pooling means the connection only needs to be established once, then reused repeatedly, saving the time of repeatedly establishing connections.

Cost category two saved: configuration loading cost. If a Sub-agent's initialization needs to load some relatively substantial configuration or resources (a rule list, a whitelist), re-creating an instance means this loading process runs repeatedly; pooling makes this loading process only need to happen once too.

Cost category three saved: the indirect value of concurrency control (highlighted in the card points earlier) — this value isn't direct time or money savings, but improved system stability — even if technically re-creating a Sub-agent is cheap, a fixed-size pool still provides a simple and effective concurrency-ceiling mechanism, a value that's especially important in scenarios where task volume can suddenly spike.

Scenarios where pooling isn't worth it: if a Sub-agent's initialization cost itself is very low (it's just pure function logic, involving no external connections or heavy data loading), the initialization cost pooling can save is negligible, but pooling's own implementation (managing borrow/return logic, handling state cleanup) adds extra code complexity — in this case, pooling's maintenance cost might exceed the performance cost it saves, not worth doing; if the system's task volume itself is very stable and low (only a few dozen tasks a day), the performance burden of re-creating a Sub-agent is itself insignificant, and concurrency control's value is small too (since task volume was never going to spike), pooling's marginal benefit is limited.

A practical signal for judging whether pooling is worthwhile: if you find the Sub-agent's initialization process itself accounts for a substantial share of the whole task-processing time (initialization takes 200ms while the task's core processing only takes 100ms), or your system often faces sudden task-volume spikes, both signals point toward pooling being worth implementing; if initialization cost is negligible relative to overall task processing time, and task volume is stable and predictable, pooling's return on investment is usually low.

The article cards mention that 'state cleanup upon return' is the most easily overlooked problem — concretely, what things inside a Sub-agent need cleaning up, and how do you ensure nothing gets missed?

What needs cleaning can be prioritized by 'how much damage would result if this information leaked into the next task,' rather than aimlessly trying to clean everything.

High priority: any context related to user identity or confidential data. If a Sub-agent, while processing task A, temporarily stored user A's personal information, API keys, or any confidential data in memory or internal state, and this isn't cleared before being lent to task B, task B might accidentally read user A's confidential information (e.g., the Sub-agent's reasoning process might reference 'what the previous conversation round mentioned' — if conversation history isn't correctly reset, old confidential content might get incorrectly carried into the new task's reasoning context) — this is the category most needing priority ensured-clean status, since an error here directly causes data leakage, a security-level severe problem.

Medium priority: business-logic-related temporary state. For example, the 'query count' and 'accumulated cost' counters mentioned in the earlier LangGraph entry — if a Sub-agent has similar temporary counts internally, not reset upon return, the next task borrowing this Sub-agent might start from a non-zero count (rather than the expected zero), causing the count-cap or cost-cap calculations discussed in the earlier retry-strategy and Circuit Breaker entries to skew — this type of error doesn't directly leak confidential data, but it makes the earlier-mentioned protection mechanisms malfunction or misjudge.

Lower priority but still worth noting: cached data. If a Sub-agent, for performance, temporarily caches some query results (last time's market data), and this cache isn't properly handled, the next task might accidentally use stale cached data instead of freshly querying real-time data — echoing the earlier slippage-tolerance article's discussion of 'data timeliness,' an uncleaned cache can cause a Sub-agent to make an outdated judgment based on stale data.

A concrete method to ensure nothing gets missed: rather than manually cleaning up item by item on every return (easy to miss newly added fields or state), a more robust approach is explicitly defining the Sub-agent's internal state as a structured object (echoing the earlier Structured Output approach); when returning to the pool, instead of 'cleaning up known fields,' directly reset the entire state object to a fresh, predefined initial state — this way, even if a field is added later, as long as it's part of this state object, the reset logic automatically covers it, without needing to manually add a cleanup line every time a new field is added, substantially lowering the probability of the oversight of 'forgot to clean up a certain field.'

If tasks arrive at a rate far exceeding the pool's size, and all Sub-agents are borrowed out, how should a new task be handled at that point? Directly reject it?

Direct rejection is one option, but not the only one — there are several common practical handling strategies, and which to choose depends on the task's own nature (can it wait, is it time-sensitive).

Strategy one: queue and wait. If a task isn't particularly urgent and slight processing delay doesn't affect the final result, a new task can enter a wait queue, processed in order once a Sub-agent is returned and becomes idle. This strategy's key design is a reasonable wait-timeout mechanism — if a queued task has waited past a certain time threshold without being processed, it should proactively give up queuing and report 'system currently overloaded, please try again later,' rather than letting the task sit indefinitely in the queue — echoing the earlier retry-strategy article's degradation approach that 'not every failure needs an infinite attempt to solve.'

Strategy two: reject directly, reporting an explicit overload state. If the task itself has strong time-sensitivity (as discussed in the earlier slippage-tolerance article — market data can go stale at any moment, and queuing to wait might mean market conditions have completely changed by the time the task completes), queuing to wait might actually cause a bigger problem (executing an operation that's no longer reasonable, based on stale data). In this case, rejecting the new task directly and clearly reporting 'resources are currently full, please retry later' is actually the safer approach, returning the decision of 'whether to retry with delay' to the caller, rather than the system deciding on its own how long to queue.

Strategy three: dynamically expand pool size (elastic pooling). If underlying resources (API quota, computational resources) allow, the system can be designed to dynamically create additional temporary Sub-agent instances when detecting the pool is continuously full, handling the current peak load, then releasing the excess temporary instances once the peak passes and task volume drops back to normal, returning to the original pool size. This strategy provides better elasticity, but with higher implementation complexity, and 'dynamic expansion' itself must not be completely uncapped (or it circles back to the uncapped-resource-consumption risk discussed in the earlier Circuit Breaker entry) — usually a 'maximum expansion multiplier' is set, avoiding unlimited expansion.

The judgment basis for which strategy to choose: the core question is 'which causes more damage for this task — the damage from queuing to wait, or the damage from rejecting directly' — if queuing to wait itself doesn't degrade the task's result (the task doesn't involve time-sensitivity-critical judgment), queuing is usually the better user-experience option; if queuing to wait might lead the task to make an inappropriate decision using stale data (especially tasks involving money operations), rejecting directly and returning the decision to the user is usually the safer option. This judgment should be set by strategy per task type, rather than the entire system using a single strategy to handle every task.

In a complex multi-agent system with multiple different Sub-agent types (e.g., simultaneously having 'query-type,' 'analysis-type,' and 'execution-type' Sub-agents), should pooling use one unified large pool, or an independent pool per type?

It should be an independent pool per type, not mixed into one unified large pool, for the same design logic discussed in the earlier Circuit Breaker entry's 'user-level should use independent breakers rather than global sharing' — different Sub-agent types have different resource-need characteristics and risk levels, and managing them mixed together creates unnecessary coupling problems.

The problem with mixing into the same pool: if query-type, analysis-type, and execution-type Sub-agents share the same pool, a common failure scenario is — at a certain point, a flood of query-type tasks arrives (many users simultaneously wanting to query market data), occupying the entire pool's resources, causing execution-type tasks (possibly more urgent, more important actual transaction executions) to instead be unable to borrow a Sub-agent, forced to queue or fail directly. This is a classic resource-contention problem of 'less important tasks occupying resources important tasks need,' echoing the broader design principle discussed in the earlier least-privilege entry that 'different roles' permissions and resources shouldn't be managed together indiscriminately.'

Concrete design of separated pooling: the query-type Sub-agent pool can be designed relatively larger (since query-type tasks are usually high-volume but each has lower resource consumption and risk); the execution-type Sub-agent pool can be designed relatively smaller but given higher queuing priority (since execution-type tasks are usually fewer in count, but each involves higher risk and importance, worth reserving dedicated resources for it, not crowded out by other task types); the analysis-type Sub-agent pool's size sits between the two, dynamically adjusted based on analysis tasks' actual arrival frequency.

An additional value: separated pooling makes resource usage easier to monitor and diagnose. If all Sub-agents are mixed in the same pool, when the system shows a problem like 'task queuing time getting longer,' it's hard to judge which task type is causing the bottleneck; if each type's pool utilization is independently monitored, you can more precisely pinpoint 'is it a surge in query-type task volume filling up the query pool, or the execution-type Sub-agent's own processing time getting longer slowing down the execution pool's turnover' — this improved diagnostic precision has high value for system operations.

The core principle this design echoes: resource management in a multi-agent system follows the same underlying logic as the permission management and Circuit Breaker design discussed repeatedly earlier — components of different roles and risk levels should have their resources and protection mechanisms designed separately, so that 'an anomaly or congestion in one segment' has its impact range bounded to its own scope, not accidentally spilling over into other segments that were operating normally, or are even more important.