Agent Swarm 1.169 chains child workflows

When one agent is not enough

A standalone agent can handle a focused request, but it falls short when the work has dependencies. In a Laravel project, I may need to investigate an issue, prepare a change, run the test suite, open a pull request, and wait for validation before deployment. When every part runs separately, the process ends up scattered across chats, scripts, and tasks that are hard to reconstruct.

Agent Swarm already includes a DAG-based workflow engine, where nodes are connected through next. That makes it possible to run steps in parallel, wait for convergence, and keep checkpoints after every step. I find that more useful than asking one agent to improvise an entire operational process inside a single session.

The main addition in version 1.169.0 is the sub-workflow node. It runs another workflow as a child execution and waits for it to reach a terminal state before moving on. If the child workflow fails or is cancelled, the calling node fails as well.

A parent workflow coordinating smaller parts

The practical value is in splitting automation by responsibility. A parent workflow can receive a GitHub event or a scheduled trigger, while child workflows handle narrow jobs such as reviewing a pull request, running an infrastructure check, or preparing an update for a homelab service. The result is a set of flows I can inspect and modify without turning every automation into one oversized prompt.

For Laravel work, I would keep the validation pipeline separate from the deployment pipeline. The first one can focus on tests, static analysis, and change review; the second can depend on those checks and stop at a human approval gate. This does not make the tests smarter by itself, but it makes the order of execution and the blocking conditions much clearer.

Workflows can be started manually, through webhooks, or from scheduled tasks. Runs retain their steps and context, and the engine can resume from the last checkpoint after a crash. That persistence matters when a process touches repositories, internal services, or actions that should not be repeated blindly.

Containerized workers, not just a remote API

Agent Swarm is designed to run workers in Docker. Its official documentation lists Claude Code as the default provider and also supports Codex, opencode, pi-mono, Devin, Claude Managed Agents, and ACP-compatible agents. Each worker uses a harness that manages the provider session and credentials.

The Docker Compose setup can run the API alongside multiple workers. When replicas share the same AGENT_ID, Agent Swarm treats them as one logical agent for task routing and capacity policy. If those workers need to continue work against the same repository or generated files, they need a shared persistent volume.

This is based on the official Compose pattern for an agent with several replicas. It pins the image through AGENT_SWARM_VERSION, configures three workers, and mounts a shared workspace at /workspace/personal.

services:
  worker:
    image: ghcr.io/desplega-ai/agent-swarm-worker:${AGENT_SWARM_VERSION:-latest}
    depends_on:
      api:
        condition: service_healthy
    deploy:
      replicas: 3
    environment:
      API_KEY: ${API_KEY:?Set API_KEY in .env}
      AGENT_ID: ${AGENT_ID:?Set AGENT_ID in .env}
      AGENT_ROLE: worker
      CLAUDE_CODE_OAUTH_TOKEN: ${CLAUDE_CODE_OAUTH_TOKEN:?Set CLAUDE_CODE_OAUTH_TOKEN in .env}
      MCP_BASE_URL: http://api:3013
      TEMPLATE_ID: official/coder
    volumes:
      - shared_agent_workspace:/workspace/personal

For a self-hosted installation, I would set AGENT_SWARM_VERSION to a specific release instead of following latest. That is basic operational hygiene, especially when the system takes part in CI, deployments, or homelab maintenance. An image update should not silently change a nightly pipeline before someone has tested it.

Scheduling workflows and requiring approval

Scheduled tasks can create agent tasks, trigger a workflow directly, or run a saved script. If the real job is already modeled as a DAG, scheduling the workflow is cleaner than opening an agent task whose only instruction is to start another flow. The schedule stays separate from the work it launches.

There are also human-in-the-loop nodes that pause a workflow and request approval or input through the dashboard. That fits operations that modify system state: running a migration, rebooting a machine, updating a container, or deploying a release. The automation can prepare the work, while the sensitive action remains an explicit decision.

In a homelab, that gate prevents a periodic check from turning a detection into a destructive action. In CI, it helps separate branch validation from promoting a change to production. Those are good places for agents to remove repetitive work without giving them unrestricted control over infrastructure.

The small print

A sub-workflow does not turn an unclear design into a reliable process. If child workflows share resources without an explicit policy — the same environment, database, or repository with local changes — the DAG will only make the underlying problem easier to see. You still need to define which steps can run in parallel, which require exclusivity, and what each one produces.

Sharing an AGENT_ID across replicas does not automatically synchronize files between containers. The documentation explicitly recommends a shared persistent workspace when task continuation depends on local state. If that is not possible, the work should be reconstructible from the repository, control plane, or task attachments.

I would not use this as a replacement for deterministic tests, backups, or security reviews either. A Docker-isolated worker reduces operational coupling, but it can still handle credentials, code, and access to internal services. Permissions should be limited per worker, secrets should stay out of prompts, and human approval should remain in place for actions that change production.

A more maintainable way to run agents

The interesting part of this release is not simply another node in a visual editor. It is the ability to treat agents as part of a defined process: one agent handles a bounded job, a child workflow groups a phase, and a parent workflow decides when to continue. That is closer to operating software than launching independent assistants and hoping they coordinate properly.

For Laravel projects, CI, and self-hosted services, this makes it possible to start with something small and observable. One workflow can validate a pull request, another can check container health, and a third can coordinate them when needed. If the process cannot be understood without asking the agent to explain it, it is not ready to automate yet.

Source: https://github.com/desplega-ai/agent-swarm/releases Official documentation: https://docs.agent-swarm.dev/docs