Feedback Loops: Sub-Agent Learning and Iteration
Why Swarms Need Feedback, Not Just More Agents
Here's the thing most people miss when they first build swarms: spawning ten agents in parallel doesn't magically give you better results. Without structured feedback loops, you just get ten independent opinions, some brilliant, some wildly wrong, and no way to reconcile them. From what I've seen, production swarms succeed when they treat every worker output as a draft that gets validated, critiqued, and potentially revised before it influences the final result.
Feedback loops are how multi-agent systems learn and iterate. A controller spawns workers, collects their results, and then routes those results through validators or peer critique before aggregating. If something fails quality thresholds, the controller re-spawns workers with the critique as additional context, moving tasks through pending → in-progress → review → done states. Multi-agent orchestration with feedback achieves 100% actionable recommendation rates vs. 1.7% for single-agent approaches (Codebridge, 2026). The difference isn't more intelligence, it's deliberate revision.
There are two kinds of feedback: endogenous (peer agents evaluating each other's reasoning) and exogenous (external validators like test suites or human review). Both matter. Endogenous feedback catches logical inconsistencies and conflicting assumptions. Exogenous feedback grounds outputs in real-world constraints, does this code actually compile, does this plan fit the budget, does this recommendation match the customer's history?
Check your understanding
Your DevOps incident response swarm spawns five parallel workers to investigate an outage. Three return plausible root causes, one times out, and one confidently blames a service that hasn't changed in weeks. What does this scenario demonstrate about feedback loops?
Aggregation Strategies: From Voting to Deliberative Critique
Once you have multiple worker outputs, you need a strategy to combine them. The simplest approach is consensus-based aggregation, majority vote, weighted confidence scores, or averaging numerical results. This works when tasks have clear right answers and workers fail independently. If three agents say "database connection pool exhausted" and one says "cosmic rays," the vote is straightforward.
But voting breaks down when the task requires nuanced judgement or when all workers share the same blind spot. That's where deliberative critique comes in. A reviewer agent evaluates not just the conclusions but the reasoning behind them. Did the worker consider edge cases? Are the assumptions documented? Does the solution actually address the root cause, or just the symptoms? Anthropic's Claude Opus 4.6 Agent Teams use approvePlan consensus gates where teammates must collectively agree on a solution before deployment, catching flawed logic that any single agent might miss.
For high-stakes workflows, add a validation agent as a final filter. In a content pipeline, the reviewer might check completeness and accuracy against criteria; in a code generation swarm, a validator runs tests on each worker's output before merging. Moonshot AI's Kimi K2.5 research showed that non-stationary feedback handling, treating delayed worker results and iterative refinements as part of training, improved tool-use accuracy by +20.1% vs. +11.0% for GPT-5.2. The key insight: aggregation isn't a one-shot merge, it's a loop.
Chatter Loops Are Real
If you spawn agents without clear termination criteria, you can get stuck in infinite critique cycles, Agent A revises, Agent B requests changes, Agent C disagrees, repeat forever. Always set max_iterations limits (most frameworks default to 50) and explicit quality thresholds. If three revision cycles don't pass validation, escalate to a human or fail gracefully. Coordination complexity grows quadratically with agent count; more agents without guardrails = debugging nightmares.Check your understanding
Match each aggregation strategy to the scenario where it works best.
Implementing Iterative Refinement with Isolated Contexts
Let's get practical. When a reviewer agent finds a problem and you need to re-spawn a worker for revision, that new worker has no memory of its predecessor. Spawned sub-agents start with fresh, isolated contexts, they don't inherit conversation history or shared state. This is by design (prevents context pollution and runaway memory growth), but it means you must explicitly pass all necessary information in the delegation call.
Nikola Balic's Sub-Agent Spawning pattern documents the canonical approach: the controller maintains a task queue with state (pending, in-progress, review, done). When a worker completes, the result goes to a reviewer. If the reviewer rejects it, the controller spawns a new worker with three things: (1) the original task description, (2) the previous attempt's output, and (3) the specific critique or failure reason. This gives the new worker enough context to improve without dragging along the full conversational history.
In LangGraph, you'd use the Send API for dynamic branching and checkpointing to persist task state between iterations. AG2 Beta (March 2026) introduced async-first event-driven architecture that makes iterative patterns cleaner, workers emit events on completion, the orchestrator listens for review results, and re-spawning happens through async task dispatch rather than blocking calls. The multi-file software engineering CAID pattern (arXiv 2603.21489) uses this approach with separate git worktrees per worker: each revision spawns a fresh worker in a clean workspace, merges back through structured integration, and test-based verification gates the next iteration. This improved accuracy 26.7% on paper reproduction tasks vs. single-agent baselines.
Pass Context Explicitly
When re-spawning a worker for revision, don't say 'improve the previous output', the new agent never saw it. Instead, pass a structured payload: original_task, previous_output_summary, critique_points, constraints. Treat each spawn as a fresh function call with all required arguments. Implicit references will silently fail in isolated contexts.Check your understanding
You're building a content research swarm where workers investigate topics in parallel and a reviewer checks for completeness. A worker's output is rejected for missing primary sources. Explain what information you must pass when re-spawning a worker to fix this issue, and why each piece matters.
Production Constraints: Depth Limits and Lifecycle Management
In theory, you could let swarms iterate forever, spawn, critique, revise, repeat. In production, you'll hit constraints fast. Most frameworks impose recursion depth limits (max_spawn_depth) and iteration caps (max_iterations, often defaulting to 50) to prevent infinite spawning and runaway costs. Workers are synchronous within a parent turn; if the orchestrator's turn gets interrupted or times out, all child workers cancel.
This means you need explicit lifecycle management. Spawned agents have finite lifespans, they execute their task, return a summary, and dissolve. They don't persist state or context beyond what they explicitly write to shared storage (a database, a file, a task queue). The controller is responsible for deciding when to stop iterating: you might set a quality threshold ("pass three validation checks"), a time budget ("stop after 30 seconds"), or a cost limit ("max five spawns per task").
LangGraph's Send API supports per-node streaming and checkpointing for stateful swarm workflows, you can pause mid-iteration, inspect intermediate results, and resume. AG2's async event-driven model lets you set per-worker timeouts and resource limits independently. Anthropic's Claude Code TeammateTool spawns up to 13 coordinated teammates, each with its own 200K context window, but the lead agent orchestrates lifecycle and gates deployment through consensus, preventing any single teammate from deploying broken code.
For me, the biggest lesson here was treating feedback loops as bounded searches rather than open-ended conversations. You're not trying to reach perfection, you're trying to reach "good enough to pass validation" within resource constraints. Set your thresholds up front, log every iteration, and always have a fallback when the loop exhausts its budget.
Feedback Loops Are Bounded Searches
Don't chase perfection. Define explicit success criteria (tests pass, reviewer approves, metrics hit threshold) and failure modes (max iterations exhausted, timeout, cost limit). Log every spawn and revision so you can debug when things don't converge. The goal is reaching 'good enough' within constraints, not infinite refinement.Key takeaways
- Feedback loops, endogenous (peer critique) and exogenous (external validation), turn parallel worker outputs into iterative refinement, moving tasks through pending → review → done states.
- Aggregation strategies range from simple majority voting (independent clear-cut tasks) to deliberative critique (nuanced judgement) to validation agents (enforcing external constraints like tests).
- Spawned sub-agents have isolated contexts with no conversation history, you must explicitly pass original task, previous output, critique, and constraints in every re-spawn.
- Production swarms require recursion depth limits, max_iterations caps, and explicit lifecycle management to prevent infinite loops and runaway costs.
- Treat feedback loops as bounded searches with predefined success criteria and failure modes, log every iteration and always have a fallback when the loop exhausts its budget.
Your product check-in
Apply “Feedback Loops: Sub-Agent Learning and Iteration” to a product or workflow you know. What would you try, what could go wrong, and what evidence would help you decide?