Scale a measured delivery process, not a collection of role names
A fictional community repair team prepares an internal weekly report from service records. One assistant already handles ten synthetic entries; the team now wants multiple site batches and review. The question is which work is independent, how errors are detected, when revisions stop and whether quality and cost remain acceptable under load. This guide preserves decomposition, self-review and scaling. Establish a sequential baseline before adding concurrency. More agents do not guarantee better quality or throughput. No team was launched, customer records analyzed or report sent for this article.
Scenario one: decompose around dependencies and artifacts
Specify acceptance first: every number traces to input, sites and dates remain distinct, unresolved items survive, and sensitive information stays out. Split normalization, site summaries, cross-checking and final writing. Site summaries may run concurrently after the normalized input is fixed. The total and narrative wait for accepted summaries. Each task card names input revision, scope, output schema, tools, acceptance, failure state and recipient. A north-site worker handles only its assigned records and cannot change another site's artifact. Missing dates go into an unresolved table rather than being guessed. Choose task size through independent acceptance, not one new role for every paragraph. The coordinator tracks IDs and snapshots, workers produce artifacts and reviewers check standards. People set scope and resolve meaningful ambiguity without repeatedly approving routine reversible steps already authorized. External material cannot expand the task. A method document does not supply an unavailable runtime or tool. Assign ownership to parallel outputs and merge through one explicit step. Separate contexts, models or channels do not prevent overwrites, duplicate writes or privilege leakage. Share necessary provenance without carrying full history everywhere or summarizing away important restrictions. For Chinese workflows, define fields and terminology such as accepted versus completed before delegation. English handoffs need the same state definitions; more English documentation does not prove compatibility. Deliver a dependency map, dictionary, task cards, input snapshot and waiting conditions, marking unexecuted work.
Scenario two: give review loops evidence and an endpoint
A review is not merely asking whether anything looks wrong. Define checkable conditions: totals match eligible records, site subtotals agree, missing values are not invented and claims have sources. Deterministic validation checks structure and arithmetic; a reviewer examines meaning and exceptions; an owner resolves decisions outside the rules. Another model can inherit the same mistaken summary. Each issue needs an ID, location, violated standard, evidence, proposed correction and retest. Workers change relevant parts and return a revision with a diff explanation. Reviewers retest original issues and affected rules rather than generating a wholly different report every round. Preserve accepted work so repair does not become continual regression. Set revision, time and call budgets and define the exhausted-budget output: best current artifact, unresolved issues, impact and owner decisions. An unbounded loop can spend resources on wording changes without improving correctness. Persistent failure may reflect conflicting standards or insufficient input, not a need for a larger limit. Separate transient failures from errors requiring different input. Temporary network failure may suit bounded backoff; missing fields and denied access usually require explanation rather than repeated calls. If timeout leaves an outcome unknown, inspect state first. Writes and sending have side effects and must not repeat because a review restarts. This example produces only an internal draft. Configure steps, timeout, retry and cancellation against the selected framework version. LangGraph's public graph and fault-tolerance documentation is a reference, but defaults vary by language and release. Persistence helps recovery while replay semantics still require side-effect design. Supported recovery does not mean exactly-once behavior automatically. Deliver standards, located issues, revision differences, retests and stopping records. Test success, repeated failure, insufficient input, rejection and budget exhaustion so none is disguised as completion. Review reduces some risks; it does not guarantee automatic conflict resolution.
Scenario three: decide expansion through load and quality evidence
Fix representative fixtures and a baseline, then increase batch size and concurrency gradually. Record run ID, input volume, model and tool versions, concurrency, completions, failures, latency, retries, usage and human rework. Keep missing data and unsuccessful runs rather than only the fastest success. Separate queue waiting from execution. Identify whether the bottleneck is model capacity, service quota, shared storage or review. More workers can move pressure to an aggregator or API rather than remove it. Use queueing, concurrency bounds, rate control and cancellation, with a sequential fallback. Simple tasks can remain single-agent. Check quality under load: duplicate or lost records, mixed sites, repeated output after restart and clear partial-batch failure. Lower latency with more rework may not be an improvement. Define acceptable ranges before measuring and avoid a guaranteed-throughput claim. For redacted local measurement CSV files, Exploratory Data Analysis fits the measurement-analysis step. Its public SkillPI listing, pinned K-Dense source and MIT license have been checked. It can support data-quality, missingness, distribution and anomaly review. Establish permitted files and Python prerequisites, with a bounded directory when needed. It is not a scheduler, does not launch agents and cannot establish causation from correlated logs. Clarify whether a row represents a run or a call so retries are not counted as independent tasks. Define units, failures and incomplete-run treatment. Inspect missing and unusual values before comparing latency and rework on matched tasks. Small samples or changed environments may be incomparable; state that rather than producing a confident-looking speed claim. Deliver a load matrix, quality and cost comparison, bottleneck hypothesis and expansion or rollback decision. Select frameworks through state, maintenance, tools and language needs rather than an enterprise label. Open source runtime, tutorials and skill procedures are different layers; installing instructions does not create a working queue and monitoring system.
A practical trial request
“Design a report over ten synthetic service records. Establish single-agent baseline and acceptance. Split by dependency, parallelizing only independent site summaries. Require located review findings and revisions within an explicit budget. Include missing input, rejection, failure, unknown timeout and duplicate-submission fixtures. Produce drafts only. Distinguish design from execution, then compare matched quality, latency and rework.” The team sets budgets according to resources rather than treating an example number as universal.
FAQ and troubleshooting
Must a good single agent be replaced? No; establish the bottleneck and likely decomposition benefit. Conflicting artifacts require scope, revision and ownership checks, not another coordinator persona. Endless review requires checking standards and inputs and defining escalation or a limited result rather than an infinite loop. Why did usage rise? Inspect repeated context, excessive granularity, retries and review rounds, along with external calls and storage. Does documentation language guarantee readiness? No; tools, inputs and outputs need validation. Which skill belongs here? Only a publicly verifiable package with matching purpose, source and license. The linked analysis skill supports measurements, not orchestration.
Sources and maintenance
The paired originals cover decomposition, review loops, scaling and FAQ. Those remain with original site-report fixtures and measurement definitions. References are LangGraph graph execution, fault tolerance and recovery documentation and the linked EDA package's pinned source. Popularity, free-use, perfect-isolation and inevitable-productivity claims are omitted. Refresh versions and associations while preserving public slug and pairing. No real batch execution is claimed.