agentatlas
==========

> Canonical skill doc and patterns for multi-agent swarms — graph topologies, workers, sub-agents, tools, and test runs.

URL: https://agentatlas.network/
Title: agentatlas — swarm documentation for coding agents
Languages: en (default), es (set cookie NEXT_LOCALE=es or use /es/... legacy prefix)

## For coding agents

Primary onboarding for autonomous agents:

- Setup command: set up https://agentatlas.network/skill.md
- Swarm skill doc: https://agentatlas.network/skill.md
- This LLM snapshot: https://agentatlas.network/llm.txt

Use the skill doc for graph editor contracts, control nodes, tools, and test runs.
Use this file for a plain-text summary of the public landing and architecture catalogue.

## Hero

Badge: Documentation for multi-agents
Headline: Teach your agents how to build swarms and sub-agents.
One skill URL with graph topologies, workers, nested swarms, tools, and test runs — so coding agents know how to design and run multi-agent systems.

Copy the setup command into your agent.
Your agent fetches the skill doc and learns the swarm workflow.

## Architecture patterns

Map intent to graph shape before picking LangGraph, AutoGen, CrewAI, or a custom runtime. Start with topology — then add cooperation and verification patterns inside workers.

Map intent to graph shape before picking LangGraph, AutoGen, CrewAI, or a custom runtime. Start with topology — then add cooperation and verification patterns inside workers.

Supervisor / Router (Popular)
Category: Orchestration · Layer: topology

One coordinator routes work to specialists and merges results.

A hub worker classifies or decomposes incoming work, delegates to specialist workers, and synthesizes their outputs. Edges fan out from the supervisor and converge on a merge or final responder.

Problem: Monolithic prompts hide routing logic and make it hard to swap specialists without rewriting the whole system.

When to use:
- Tasks decompose into distinct specialist roles (research, code, review).
- You need a single owner for routing, retries, and final packaging.
- Specialists can run with different models or tool sets.

When not to use:
- Every step must run in strict order with no branching.
- Routing is trivial enough for one worker with tools.
- Latency-sensitive paths where parallel fan-out is mandatory from the start.

Forces:
- Clear ownership at the hub
- Low coupling between specialists
- Easy to add or replace a specialist node

Operational profile (1–5): verification 3, traceability 4, latency 3, cost 3

Agents: 1 supervisor + 2–4 specialists (typical 3–8)

Graph: Nodes: supervisor, specialist_a, specialist_b, merge. Edges: supervisor → specialist_a; supervisor → specialist_b; specialist_a → merge; specialist_b → merge.

Framework notes:
- LangGraph: Supervisor node with conditional edges to worker subgraphs; merge via reduce or final LLM node.
- AutoGen: Group chat with a manager agent delegating to nested chats or registered agents.
- LangChain τ-bench: Maps to the supervisor / swarm routing benchmark topology.

Evidence: Common default in LangGraph tutorials and τ-bench swarm comparisons.

References:
- LangGraph multi-agent supervisor: https://langchain-ai.github.io/langgraph/
- τ-bench agent architectures: https://arxiv.org/abs/2406.08625

---

Pipeline + Critic
Category: Quality · Layer: topology

Plan, execute, then verify — each stage owns a narrow job.

Workers run in series: plan or spec, execute the main task, then a critic or verifier gates output before release. Control flow is mostly linear with an optional loop back on failure.

Problem: Single-pass generation skips explicit quality gates and makes regressions hard to catch before users see output.

When to use:
- High traceability — each stage has a named artifact.
- Outputs must pass checks (policy, tests, rubric) before shipping.
- Errors should loop back to an earlier stage with structured feedback.

When not to use:
- Subtasks are fully independent and can run in parallel.
- Verification is cheap enough to embed in one worker prompt.
- End-to-end latency dominates and serial stages are too slow.

Forces:
- Strong stage boundaries and audit trail
- Explicit verify / retry loop
- Higher latency than parallel fan-out

Operational profile (1–5): verification 5, traceability 5, latency 2, cost 4

Agents: planner + executor + critic (typical 3–6)

Graph: Nodes: plan, execute, critic, output. Edges: plan → execute; execute → critic; critic → output (pass); critic → execute (revise).

Framework notes:
- LangGraph: Linear StateGraph with conditional edge from critic back to execute.
- AutoGen: Sequential chat or nested critic agent after primary completion.
- CrewAI: Task chain with explicit review task and output guardrails.

Evidence: Aligns with plan–execute–verify loops in production coding agents.

References:
- CSIRO agentic workflow patterns (2405.10467): https://arxiv.org/abs/2405.10467

---

Parallel fan-out
Category: Throughput · Layer: topology

Fan work out to parallel workers, then merge downstream.

A router or splitter sends independent subtasks to parallel workers. A synthesizer or reducer merges partial results into one response. Maximizes throughput when subtasks do not depend on each other mid-flight.

Problem: Serial pipelines waste wall-clock time when subtasks could run concurrently with separate context windows.

When to use:
- Subtasks are independent (multi-source research, parallel tool calls).
- Wall-clock latency matters more than minimum token spend.
- Merge logic is well defined (concat, vote, LLM synthesize).

When not to use:
- Later steps need intermediate results from earlier parallel branches in real time.
- Merge quality is fragile and needs heavy sequential refinement.
- Cost budget is tight — parallel LLM calls multiply spend.

Forces:
- Best wall-clock latency for divisible work
- Higher aggregate cost than a single worker
- Merge step is a common failure point

Operational profile (1–5): verification 3, traceability 3, latency 5, cost 4

Agents: router + 2–5 workers + merge (typical 3–10)

Graph: Nodes: router, worker_a, worker_b, worker_c, merge. Edges: router → worker_a; router → worker_b; router → worker_c; worker_a → merge; worker_b → merge; worker_c → merge.

Framework notes:
- LangGraph: Send API or parallel branches from a fan-out node into a reduce node.
- AutoGen: Concurrent agent replies collected by a synthesizer.
- CrewAI: Parallel task execution with a final aggregation task.

Evidence: Standard pattern for map-reduce style agent workflows.

References:
- Map-reduce agents (LangGraph): https://langchain-ai.github.io/langgraph/

---

Roles Dinámicos y Bio-miméticos
Category: Swarm · Layer: cooperation

Agentes autónomos con roles especializados que cambian dinámicamente según el contexto.

Agentes descentralizados que siguen reglas simples bio-miméticas (inspiradas en colonias de hormigas o abejas). La comunicación es local y mínima para optimizar la colaboración sin control centralizado.

Problem: La rigidez de roles en entornos cambiantes genera cuellos de botella y vulnerabilidad ante fallos de agentes clave.

When to use:
- El entorno es dinámico y requiere adaptabilidad de tareas.
- Se busca alta escalabilidad y tolerancia a fallos individuales.
- La comunicación global o centralizada es ineficiente.

When not to use:
- Se requiere una secuencia estricta y predecible de acciones.
- Es crucial una supervisión o auditoría centralizada en tiempo real.

Forces:
- Alta resiliencia a fallos
- Bajo acoplamiento y comunicación mínima
- Especialización dinámica

Operational profile (1–5): verification 3, traceability 2, latency 4, cost 2

Agents: 10–20 agentes con roles fluidos (typical 5–50)

Graph: Nodes: a, b, c, d, e, f. Edges: a → b; b → c; c → d; d → e; e → f; f → a; a → d; b → e.

---

LLMs Embebidos y Auto-evolución
Category: Cognitive · Layer: cooperation

Cada agente integra un LLM ligero para razonamiento local y adaptación autónoma.

Cada miembro del enjambre ejecuta un LLM local para interpretar su entorno y tomar decisiones. Usan protocolos P2P para compartir estados e implementar un módulo de auto-evolución que ajusta estrategias mediante feedback colectivo.

Problem: Los agentes con reglas estáticas no pueden adaptarse a objetivos globales complejos o cambios imprevistos en la semántica del entorno.

When to use:
- Los agentes deben interpretar lenguaje natural u objetivos globales complejos.
- Se requiere aprendizaje y mejora continua en el comportamiento del enjambre.

When not to use:
- Dispositivos con recursos de cómputo extremadamente limitados.
- Se requieren garantías de comportamiento deterministas y formales.

Forces:
- Razonamiento local avanzado
- Coordinación semántica auto-organizada
- Alto consumo de recursos (tokens/cómputo)

Operational profile (1–5): verification 3, traceability 3, latency 2, cost 5

Agents: 5–8 agentes cognitivos (typical 3–15)

Graph: Nodes: llm_a, llm_b, llm_c, llm_d, llm_e. Edges: llm_a → llm_b; llm_a → llm_c; llm_a → llm_d; llm_a → llm_e; llm_b → llm_c; llm_b → llm_d; llm_b → llm_e; llm_c → llm_d; llm_c → llm_e; llm_d → llm_e.

---

ReAct / Agentic Tool Loop (Foundation)
Category: Agentic · Layer: topology

Single agent iterates through Reason → Act (tool call) → Observe until goal is reached — the building block of most real agents.

One capable agent loops through a think-then-act cycle. At each step it chooses a tool (web search, code exec, scrape, etc.), observes the result, and reasons again. No parallel workers — all complexity lives in the tool selection and prompt. The agent decides when the goal is met.

Problem: Multi-worker graphs add coordination overhead when a single goal only requires iterative tool use, not parallel specialization or distinct roles.

When to use:
- A goal is achievable by one capable agent with the right tools (search, code exec, scrape).
- The number of steps is unknown upfront — the agent decides when done.
- Adding a second worker would only fan out the same tool set, not add real specialization.

When not to use:
- Tasks decompose into genuinely different roles needing different models or prompts.
- You need guaranteed parallel throughput — the loop is serial by nature.
- The loop could iterate infinitely — add a While node with maxIterations.

Forces:
- Simplest possible graph: one worker node
- All intelligence lives in the agent prompt and tool selection
- Hard to parallelise; add fan-out if throughput matters

Operational profile (1–5): verification 3, traceability 4, latency 3, cost 3

Agents: 1 agent + 2–5 tools (typical 1–1)

Graph: Nodes: agent, tool_web, tool_code, tool_scrape. Edges: agent → tool_web; agent → tool_code; agent → tool_scrape; tool_web → agent (observe); tool_code → agent (observe); tool_scrape → agent (observe).

Framework notes:
- LangGraph: Single StateGraph node with tools list; conditional edge loops back until agent emits final answer.
- AutoGen: ConversableAgent with function_map; loops via reply until termination condition.
- CrewAI: Single-agent task with tool list; Process.sequential with self-reflection enabled.
- agentatlas: One worker node with agentTools configured. Add a While control node with maxIterations cap if infinite loops are a risk.

Evidence: Foundation of OpenAI function calling, Claude tool use, and most single-agent production deployments.

References:
- ReAct: Synergizing Reasoning and Acting in LLMs (Yao et al. 2022): https://arxiv.org/abs/2210.11610

---

Debate / Multi-perspective Judge
Category: Verification · Layer: cooperation

Two agents argue opposing positions; an independent judge synthesizes and decides — surfaces blindspots systematically.

A router sends the same task to two agents with deliberately different framings (Pro vs Con, Method A vs Method B, or Red Team vs Blue Team). An independent Judge agent reads both arguments and renders a structured verdict. The adversarial framing forces surface of counterarguments before committing to an answer.

Problem: Single-agent responses can be confidently wrong. Parallel analysts with the same framing produce correlated errors. A structured adversarial setup surfaces counterarguments and edge cases that single-perspective evaluation misses.

When to use:
- High-stakes decisions with two valid framings (policy, fact-check, legal review).
- You want to explicitly surface counterarguments before committing to an answer.
- The judge can be prompted with a structured rubric for evaluation.

When not to use:
- The task has no meaningful opposing perspective — debate adds cost without benefit.
- Latency is the primary constraint — minimum 3 serial LLM calls.
- Both agents will hit the same retrieval source and produce correlated outputs.

Forces:
- Surfaces blindspots and counterarguments systematically
- Judge prompt quality determines final output quality
- 3× minimum LLM cost vs. single-agent approach

Operational profile (1–5): verification 5, traceability 4, latency 2, cost 4

Agents: 2 debaters + 1 judge (typical 3–5)

Graph: Nodes: router, agent_pro, agent_con, judge, output. Edges: router → agent_pro; router → agent_con; agent_pro → judge; agent_con → judge; judge → output.

Framework notes:
- LangGraph: Fan-out from router node to two parallel agent nodes, reduce into judge node.
- AutoGen: Two-agent debate chat; third judging agent reads the conversation history.
- agentatlas: Parallel fan-out to two worker nodes with opposing system prompts, converge on judge worker.

Evidence: Used in constitutional AI evaluation, red-teaming, and high-stakes document review workflows.

References:
- Society of Mind and multi-agent debate (Du et al. 2023): https://arxiv.org/abs/2305.14325

---

Extended patterns

Additional topologies documented for agents — included in the skill catalogue.

Series (pipeline)
Category: Refinement · Layer: topology

Sequential refinement — each worker passes output to the next (`A → B → C → D`).

Workers run in a strict chain with no parallel branches. Each stage transforms or enriches the artifact from the previous step. Simpler than Pipeline + Critic when you do not need an explicit verify loop.

Problem: One-shot generation cannot iteratively refine context — later steps lack structured handoffs from earlier specialists.

When to use:
- Work naturally decomposes into ordered phases (draft → expand → polish).
- Each stage needs the full prior artifact, not partial parallel results.
- Branching and merge logic would add complexity without benefit.

When not to use:
- Subtasks are independent and could run concurrently.
- You need explicit quality gates or revision loops between stages.
- A single worker with tools can cover the whole chain cheaply.

Forces:
- Maximum traceability per stage
- Wall-clock time sums across stages
- Easy to reason about and debug

Operational profile (1–5): verification 3, traceability 4, latency 2, cost 3

Agents: 3–4 chained specialists (typical 2–6)

Graph: Nodes: a, b, c, d. Edges: a → b; b → c; c → d.

Framework notes:
- LangGraph: Linear StateGraph — each node reads prior state and writes the next field.
- AutoGen: Sequential chat or chained agent handoffs.
- CrewAI: Tasks with explicit `context` from prior task outputs.

Evidence: Baseline pattern in CSIRO sequential workflow catalogue.

References:
- CSIRO agentic workflow patterns (2405.10467): https://arxiv.org/abs/2405.10467

---

Parallel + synthesizer
Category: Analysis · Layer: topology

Independent analyses in parallel, then one synthesizer merges perspectives.

A router fans out to parallel analyst workers (research, code review, risk, etc.). A dedicated synthesizer worker merges divergent outputs into one coherent answer — stronger emphasis on merge quality than raw throughput fan-out.

Problem: Single-perspective analysis misses contradictions; concatenating parallel outputs produces incoherent bundles.

When to use:
- You need multiple independent lenses on the same input.
- Merge quality matters — synthesis is a first-class step, not an afterthought.
- Analysts can disagree; the synthesizer resolves or ranks findings.

When not to use:
- Parallel branches produce identical artifact types that only need concatenation.
- Synthesis is trivial enough for the router to handle inline.
- Cost of N analysts plus a synthesizer exceeds budget.

Forces:
- Richer coverage than one monolithic analyst
- Synthesizer is the quality bottleneck
- Higher cost than parallel fan-out without dedicated merge

Operational profile (1–5): verification 4, traceability 4, latency 4, cost 5

Agents: router + 2–4 analysts + synthesizer (typical 4–10)

Graph: Nodes: router, analyst_a, analyst_b, analyst_c, synthesizer. Edges: router → analyst_a; router → analyst_b; router → analyst_c; analyst_a → synthesizer; analyst_b → synthesizer; analyst_c → synthesizer.

Framework notes:
- LangGraph: Map-reduce with a dedicated reduce/s synthesizer node and structured analyst outputs.
- AutoGen: Parallel nested chats feeding a summarizer agent.
- CrewAI: Parallel tasks converging on a final aggregation task with rubric.

Evidence: Common in multi-source research and due-diligence agent demos.

---

Hybrid
Category: Complex workflows · Layer: topology

Mixed control flow — parallel branches, conditionals, and sequential stages in one graph.

Combines routing, parallel fan-out, if/else control nodes, and serial refinement in a single swarm. Use when real tasks need different shapes in different phases — not one pure topology end to end.

Problem: Forcing a pure supervisor, pipeline, or fan-out pattern onto heterogeneous workflows creates awkward workarounds and hidden state.

When to use:
- Phases differ: e.g. parallel research → sequential draft → conditional deploy path.
- Control nodes (if/else, while) belong between worker stages.
- You have test traces proving which branches fire in production.

When not to use:
- A simpler topology covers 90% of runs — start there first.
- Team cannot maintain or debug multi-shape graphs yet.
- No observability — hybrid flows fail silently in unexpected branches.

Forces:
- Highest expressiveness for real-world tasks
- Hardest to test and document
- Requires strong trace inspection in agentatlas test panel

Operational profile (1–5): verification 4, traceability 4, latency 3, cost 4

Agents: router + parallel block + serial tail + controls (typical 5–12)

Graph: Nodes: router, parallel_block, ifelse, serial_tail, output. Edges: router → parallel_block; parallel_block → ifelse; ifelse → serial_tail (pass); ifelse → router (retry); serial_tail → output.

Framework notes:
- LangGraph: Compose subgraphs — parallel Send blocks, conditional edges, nested StateGraphs.
- AutoGen: Mix group chat routing with nested sequential teams.
- agentatlas: Use control nodes (if/else, while) between worker nodes; validate `sourceHandle` on branch edges.

Evidence: Production swarms often evolve into hybrid graphs after v1 linear or supervisor designs.

References:
- AutoGen conversation patterns: https://microsoft.github.io/autogen/docs/tutorial/conversation-patterns

---

LLM Centralizado y Agentes Distribuidos
Category: Orchestration · Layer: topology

Un LLM central como orquestador cognitivo para agentes ejecutores simples.

A single LLM hub interprets the global state and dispatches adaptive directives to lightweight executor nodes. Unlike Supervisor/Router — where workers are full LLM agents with their own reasoning — executors here can be APIs, scripts, or physical actuators that only carry out instructions. All cognition is centralised; use this when you want cheap or zero-LLM executors.

Problem: Dotar a cada agente de un LLM es costoso e ineficiente, pero un enjambre puramente reactivo carece de dirección estratégica.

When to use:
- Se requiere planificación compleja y centralizada con ejecución física o local distribuida.
- Presupuesto limitado que impide ejecutar LLMs en cada nodo.

When not to use:
- Entornos con latencia crítica o pérdida de conectividad constante con el nodo central.
- El punto único de fallo (el LLM central) es inaceptable.

Forces:
- Planificación centralizada coherente
- Bajo costo en los nodos ejecutores
- Vulnerabilidad al punto único de fallo

Operational profile (1–5): verification 4, traceability 4, latency 3, cost 3

Agents: 1 controlador + 5–10 ejecutores (typical 4–20)

Graph: Nodes: central_llm, executor_1, executor_2. Edges: central_llm → executor_1; central_llm → executor_2.

---

Control de Cohesión y Garantías Formales (Research)
Category: Control · Layer: verification · Research only

Modelos de control no lineal y algoritmos formales para garantizar estabilidad bajo ruido.

Utiliza capas de control basadas en dinámicas no lineales y algoritmos matemáticos para asegurar la cohesión global y estabilidad dinámica del swarm en entornos ruidosos y con topologías cambiantes.

Problem: Los enjambres puramente heurísticos o basados en aprendizaje pueden divergir o volverse inestables ante perturbaciones del mundo real.

When to use:
- Sistemas físicos críticos (como UAVs o robótica móvil) donde la colisión o dispersión es catastrófica.
- Entornos con alto ruido de comunicación y topologías altamente dinámicas.

When not to use:
- Tareas puramente de procesamiento de software o datos sin dinámicas físicas.
- Fases tempranas de exploración donde no se han definido las métricas de estabilidad.

Forces:
- Garantías matemáticas de estabilidad
- Robustez frente al ruido del entorno
- Alta complejidad matemática y de modelado

Operational profile (1–5): verification 5, traceability 3, latency 4, cost 2

Agents: 20–50 nodos controlados (typical 5–100)

Graph: Nodes: n1, n2, n3, n4, n5, ctrl. Edges: n1 → ctrl; n2 → ctrl; n3 → ctrl; n4 → ctrl; n5 → ctrl; ctrl → n1 (adjust); ctrl → n3 (adjust); n1 → n2; n2 → n3; n3 → n4; n4 → n5; n5 → n1.

---

Representación Compacta y Aprendizaje (MARL) (Research)
Category: Learning · Layer: cooperation · Research only

Compresión de estado mediante mean embeddings o factorización tensorial para aprendizaje reforzado.

Los agentes usan representaciones compactas de sus vecinos para reducir la sobrecarga de comunicación. Emplea aprendizaje por refuerzo multiagente (MARL) y separa las fases de entrenamiento (centralizado) y ejecución (distribuido/asíncrono).

Problem: El crecimiento exponencial del espacio de estados y la comunicación satura el sistema al escalar el número de agentes.

When to use:
- Sistemas de gran escala (cientos de agentes).
- Se dispone de un entorno de simulación para entrenamiento offline.

When not to use:
- Sistemas con pocos agentes donde la representación compacta pierde precisión útil.
- No es posible realizar un entrenamiento previo o simulado.

Forces:
- Escalabilidad teórica masiva
- Reducción drástica del ancho de banda
- Fase de entrenamiento costosa y compleja

Operational profile (1–5): verification 3, traceability 2, latency 5, cost 4

Agents: 50–100 agentes con MARL (typical 10–1000)

Graph: Nodes: tr1, tr2, tr3, ex1, ex2, ex3, ex4. Edges: tr1 → tr2; tr2 → tr3; tr1 → ex1 (policy); tr1 → ex2 (policy); tr2 → ex2 (policy); tr2 → ex3 (policy); tr3 → ex3 (policy); tr3 → ex4 (policy).

---

Enjambre Homogéneo Minimalista (Research)
Category: Bio-inspired · Layer: cooperation · Research only

Agentes idénticos con comunicación binaria simple o de un solo bit.

Agentes simples y homogéneos que interactúan de forma local mediante protocolos de comunicación minimalistas (como WOSP). Basado en la emergencia de comportamiento colectivo sin requerir sincronización global ni mensajes complejos.

Problem: Protocolos de comunicación pesados causan colisiones de red y alto consumo energético en hardware limitado.

When to use:
- Hardware extremadamente simple o barato.
- Tareas de cobertura de área, patrullaje o dispersión simple.

When not to use:
- Se requiere coordinación de planes complejos o razonamiento simbólico.

Forces:
- Costo de hardware mínimo
- Protocolo ultra ligero sin colisiones
- Comportamiento individual extremadamente simple

Operational profile (1–5): verification 2, traceability 2, latency 5, cost 1

Agents: 100+ agentes homogéneos (typical 10–10000)

Graph: Nodes: h1, h2, h3, h4, h5, h6. Edges: h1 → h2; h2 → h3; h4 → h5; h5 → h6; h1 → h4; h2 → h5; h3 → h6.

---

Enjambre Jerárquico con Metaheurísticas (Research)
Category: Optimization · Layer: cooperation · Research only

Jerarquías dinámicas y optimización híbrida mediante PSO y algoritmos genéticos.

Forma jerarquías temporales asignando líderes según el contexto. Combina el comportamiento de enjambre con metaheurísticas de optimización (como Particle Swarm Optimization y algoritmos genéticos) para resolver tareas complejas en espacios 3D.

Problem: La falta de estructura temporal dificulta la resolución de subtareas complejas que requieren secuenciación.

When to use:
- Optimización de rutas en espacios 3D (ej. enjambres de UAVs).
- Tareas que se benefician de división jerárquica temporal.

When not to use:
- Entornos planos bidimensionales o de procesamiento de texto simple.

Forces:
- Optimización global eficiente
- Liderazgo adaptable sin rigidez
- Complejidad en la sincronización de líderes

Operational profile (1–5): verification 4, traceability 3, latency 3, cost 3

Agents: 12–24 agentes con sub-líderes (typical 6–40)

Graph: Nodes: l0, l1, l2, f1, f2, f3, f4. Edges: l0 → l1; l0 → l2; l1 → l2 (peer); l1 → f1; l1 → f2; l2 → f3; l2 → f4.

---

Swarm Modular Asíncrono
Category: Modular · Layer: cooperation

Roles modulares (exploradores, recolectores, coordinadores) con mensajes asíncronos.

Basado en SwarmSys, los agentes se dividen en módulos especializados para roles específicos. Operan en fases iterativas para adaptación continua y se comunican mediante mensajes asíncronos para flexibilidad y escalabilidad.

Problem: La comunicación síncrona bloquea a los agentes y reduce la velocidad de exploración y recolección.

When to use:
- Tareas de búsqueda, exploración o recolección de recursos distribuidos.
- Sistemas donde el desacoplamiento temporal de tareas es beneficioso.

When not to use:
- Sistemas que requieren consenso síncrono inmediato para cada paso.

Forces:
- Especialización de tareas clara
- Desacoplamiento temporal completo
- Monitoreo global más complejo

Operational profile (1–5): verification 3, traceability 4, latency 4, cost 3

Agents: 3 roles x 4 agentes cada uno (typical 6–30)

Graph: Nodes: sc1, sc2, coord, ga1, ga2. Edges: sc1 → coord (async); sc2 → coord (async); coord → ga1 (task); coord → ga2 (task); coord → sc1 (feedback); sc1 → sc2; ga1 → ga2.

---

Human-in-the-loop Gate
Category: Safety · Layer: verification

A human approval checkpoint pauses the swarm until a person approves, rejects, or redirects — essential for irreversible actions.

An approval gate node interrupts execution flow and waits for human input before continuing. On approval the graph proceeds to the action node; on rejection it loops back to a revision worker. Adds an explicit human control point without changing the rest of the graph structure.

Problem: Fully autonomous swarms can confidently take irreversible actions (send emails, deploy code, charge cards) with no checkpoint. Adding explicit gates makes risk visible, auditable, and controllable.

When to use:
- Actions are irreversible: send, publish, deploy, charge, delete.
- Regulatory or compliance requirements mandate human sign-off.
- Output quality variance is high enough that human review adds reliable value.

When not to use:
- Humans are unavailable in the time window required by the task.
- The action is fully reversible and cost of error is low.
- Full automation is the explicit product requirement.

Forces:
- Makes irreversible risk explicit and auditable
- Blocks throughput — latency is bounded by human response time
- Adds compliance-grade accountability trail

Operational profile (1–5): verification 5, traceability 5, latency 1, cost 2

Agents: 1–2 workers + 1 approval gate + human (typical 2–6)

Graph: Nodes: worker, gate, continue, revise. Edges: worker → gate; gate → continue (approve); gate → revise (reject); revise → worker.

Framework notes:
- LangGraph: langgraph.interrupt() blocks execution and waits for external resume signal.
- AutoGen: Human proxy agent in the chat loop with reply=human_input.
- agentatlas: Use the built-in user_approval control node — sources: approve → continue, reject → revise loop.

Evidence: Standard safety pattern in production agentic workflows handling financial, legal, or irreversible operations.

---

Nested Swarm Delegation
Category: Composition · Layer: topology

An orchestrator delegates complex subtasks to specialized child swarms as callable black boxes — enables reusable modular composition.

A top-level orchestrator agent decomposes work and invokes child swarms as tools (run_swarm). Each child swarm encapsulates a full multi-step workflow; the parent only sees inputs and outputs. Enables modular composition of complex systems without exposing internal graph structure across boundaries. Child swarms can be developed and tested independently.

Problem: A single flat graph becomes unmanageable as task complexity grows. Nesting swarms as black-box tools enables reuse, independent testing, and team ownership of sub-workflows without coupling internal state.

When to use:
- A subtask is complex enough to warrant its own multi-worker graph.
- The same child workflow is reused across multiple parent swarms.
- Teams own different swarms independently — loose coupling is required.

When not to use:
- The subtask is simple enough for one worker with tools.
- Cross-swarm real-time state sharing is required — nesting hides internal state.
- Latency budget is tight — each nested run adds call overhead.

Forces:
- Maximum composability — child swarms are reusable, independently testable
- Clean boundary: parent only sees swarm input/output
- Debugging requires tracing into child run history separately

Operational profile (1–5): verification 4, traceability 3, latency 2, cost 5

Agents: 1 orchestrator + 2–3 child swarms (3–5 workers each) (typical 4–20)

Graph: Nodes: orchestrator, sub_a, sub_b, merge, output. Edges: orchestrator → sub_a; orchestrator → sub_b; sub_a → merge; sub_b → merge; merge → output.

Framework notes:
- LangGraph: Subgraph nodes compiled separately; parent graph invokes them as nodes with their own state schemas.
- AutoGen: Nested GroupChat or ConversableAgent wrapping an inner chat manager.
- agentatlas: Add swarm control node to parent graph; configure swarmTools on the orchestrator worker to expose child swarms as callable tools.

Evidence: Common in production agentic systems: a research swarm feeds a drafting swarm, each independently versioned.

Sweet spot: 3–7 workers. Avoid filler agents (format-only steps → use functions, not workers).

## Footer

Platform to create and test agent swarms.

Links:
- Privacy: https://agentatlas.network/privacy
- Terms: https://agentatlas.network/terms
- Sign in: https://agentatlas.network/sign-in
- Sign up: https://agentatlas.network/sign-up
- Dashboard (authenticated): https://agentatlas.network/dashboard

© 2026 agentatlas. All rights reserved.

---
Generated from the public landing page. Last updated: 2026-06-21.