Taming the Swarm: Breyta’s Bounded, Observable Agent Fanout

By Vegard Steen • Published 2026-05-29

Explore Breyta's agent fanout capabilities, transforming chaotic multi-agent swarms into predictable, observable workflows with strict concurrency caps and deterministic lineage.

Breyta workflow automation

The AI ecosystem loves to talk about "agent swarms"—the idea of turning an LLM loose to dynamically spin up dozens of sub-agents that talk to each other in an unbounded, recursive tree until a problem is solved. It sounds magical.

In production, however, unbounded agent swarms are an operational nightmare. They are untraceable, prone to infinite loops, brutally expensive, and impossible to debug when a single leaf node fails.

At Breyta, we believe multi-agent collaboration shouldn't feel like a roll of the dice. With our latest agent fanout capabilities, we are treating parallel multi-agent execution not as a chaotic experiment, but as predictable workflow infrastructure.

Here is how Breyta allows you to execute named specialist agents concurrently while maintaining strict concurrency caps, deterministic lineage, and robust failure policies.

---

What is Agent Fanout?

Agent fanout is the ability to run multiple sibling specialist agents in parallel from a single parent workflow, collecting their individual outputs for a final synthesis.

This architecture is incredibly powerful for tasks that naturally split into independent analysis branches, such as:

  • Code Review: Running security, performance, reliability, and documentation specialists over a repository simultaneously.
  • Incident Triage: Dispatching parallel specialists to inspect application logs, deployment history, and database metrics during an outage.
  • Market Intelligence: Analyzing a target company across separate legal, financial, and competitive landscape branches.

The key requirement here is independence. If your agents need a back-and-forth conversation with one another, they belong in a direct delegation loop. But if they can execute their tasks concurrently and report back, they belong in a fanout block.

---

The Two Patterns: Dynamic vs. Deterministic

Breyta supports two distinct authoring patterns for agent fanout. You can let a coordinator agent decide how to split the work dynamically, or you can declare the parallel paths deterministically at the flow level.

Pattern 1: Agent-Internal Fanout (Dynamic)

Use this pattern when a coordinator agent needs to evaluate a situation during runtime and dynamically decide which specialists to spin up.

You configure the coordinator with an explicit allowlist of top-level agents it is permitted to invoke:

(flow/step :agent :orchestrator/review
  {:objective "Review the repository. Fan out to specialists when parallel review is useful, then synthesize the results."
   :inputs {:repo-tree repo-tree}
   :tools {:fanout {:agents [:review/security :review/performance]
                    :max-items 5
                    :max-concurrency 3
                    :on-error :collect}}
   :max-iterations 8})

Under the hood, Breyta injects a generated tool named fanout_agents into the coordinator's tool loop. The model interacts with a clean, structured schema:

{
  "items": [
    {
      "agent": "review/security",
      "input": { "area": "auth", "focus": "OAuth tokens" }
    },
    {
      "agent": "review/performance",
      "input": { "area": "database queries" }
    }
  ]
}

Pattern 2: Flow-Level Fanout (Deterministic)

Use this pattern when your business logic already dictates the exact list of agents that must run in parallel. There is no need to make a coordinator agent reason about the split; the parent flow handles it explicitly.

(flow/step :fanout :parallel-review
  {:items [{:type :agent
            :agent :review/security
            :input {:area "auth" :repo-tree repo-tree}}
           {:type :agent
            :agent :review/performance
            :input {:area "queries" :repo-tree repo-tree}}]
   :max-concurrency 2
   :on-error :collect})

---

Choosing the Right Approach

| Scenario | Recommended Pattern | | --- | --- | | An orchestrator agent must dynamically decide if and how to split work | Agent-Internal (@@INLINE_0@@ tool) | | The branch list is static and known before execution begins | Flow-Level (@@INLINE_1@@) | | An agent needs an adaptive, back-and-forth conversation with a specialist | Direct Tool Delegation (@@INLINE_2@@) | | A branch represents an entire sub-workflow or a separate app boundary | @@INLINE_3@@ inside a fanout block |

---

Architectural Guardrails: Safety by Default

Breyta enforces safety through the structure of the runtime, not just through prompt engineering. When an agent calls fanout_agents, the platform steps in to manage the execution lifecycle.

1. The Child-Workflow Abstraction

Breyta does not execute sub-agents inline or within an unmanaged thread pool. Instead, every fanout branch spawns an isolated async child workflow.

Each child run is bound to an internal synthetic entrypoint that resolves directly to the targeted top-level agent definition. This ensures that every specialist runs in an isolated state container with its own execution budget, timeout controls, and retry policies.

2. Built-In Hard Limits

To prevent runaway costs and API provider throttling, Breyta bakes strict engineering guardrails directly into the platform schema:

  • Max Fanout Width: Up to 25 parallel items per fanout execution.
  • Max Concurrency: An effective cap of 5 concurrent child workflows running at once.
  • No Unbounded Nesting: Recursive asynchronous child fanouts are automatically blocked past a depth of 1 to eliminate circular process trees.
  • Data Thresholds: Inline result payload sizes are capped at 512 KB to preserve LLM context windows; larger payloads must be written as persistent resource references.

3. Graceful Failure Policies

When running multiple complex agents concurrently, failures can happen. Breyta gives authors explicit control over branch errors using the :on-error directive:

  • :fail – Aborts the entire step immediately if any branch drops.
  • :continue – Tolerates the failure and proceeds silently.
  • :collect – Highly Recommended. Captures both success data and error traces, handing a structured matrix back to the coordinator agent so it can intelligently synthesize partial results.
;; Example of a collected result payload returned to the coordinator
{:successes [{:item {...} :result {:vulnerabilities []}}]
 :failures  [{:item {...} :error  {:type :provider_timeout :message "..."}}]
 :total 2
 :success-count 1
 :failure-count 1}

---

Best Practices for Production Fanout

  • Mind Your Input Inheritance: By default, sub-agents inherit the coordinator's full input map. If you are handling large repository trees or sensitive customer tables, set :inherit-inputs? false and pass precise, localized slices to each specialist to avoid inflating your token bill.
  • Enforce Structured Outputs: If a coordinator agent is responsible for synthesizing findings, ensure your specialist agents use an explicit schema or :output {:format :json}. It is much easier for an orchestrator to compile a report when its inputs are predictably structured.
  • Keep State out of Arguments: Never pass raw secrets, database passwords, or deploy tokens via fanout inputs. Keep authorization locked safely inside Breyta’s environment connections; the child workflows will inherit the necessary secure context seamlessly.

Clean Observability

Because every fanout branch is an authentic Breyta child workflow, tracking execution is completely transparent.

The parent run's trace timeline will clearly display the fanout_agents tool invocation, while the platform automatically logs explicit lineage markers like :root-workflow-id, :parent-workflow-id, and :fanout-depth. If a specialist fails, developers don't have to sift through a single messy log dump—they can jump straight into the isolated child workflow trace to pinpoint the exact step failure.

By moving away from unbounded agent swarms and embracing structured child-workflow fanouts, Breyta gives teams the freedom to build sophisticated multi-agent architectures that remain resilient, observable, and enterprise-safe.