Open-Source Dynamic Workflows: How awman Enables Multi-Model Collaborative AI Programming

Origins: Breaking Single-Model Limits with Dynamic Workflows

The concept of "Dynamic Workflows" introduced by Claude has opened up new possibilities for AI programming — enabling AI to autonomously design and execute multi-step task pipelines, rather than relying on developers to manually orchestrate them.

The fundamental difference between dynamic and static workflows lies in who does the orchestrating. Traditional automation workflows (like Apache Airflow or Prefect) have human developers pre-define a DAG (Directed Acyclic Graph), with each node's inputs, outputs, and execution order hardcoded. Dynamic workflows shift the decision of "how to decompose a task" to the AI itself, allowing it to generate a customized execution plan at runtime based on the task's content, complexity, and context. The theoretical foundation for this paradigm shift comes from the planning capability of LLMs — research has shown that large models can effectively decompose complex goals into executable subtasks within a chain-of-thought reasoning framework, and dynamic workflows externalize this capability into an observable, executable structured process.

However, this capability has long been tied to specific models and frameworks, making it difficult to flexibly combine different agents and models. A developer shared their solution on Reddit: adding a --dynamic flag to their agent workflow manager, awman (agent workflow manager), to create an open-source version of dynamic workflows that can adapt to any framework and model. The core motivation behind this effort comes from three major pain points with single-model solutions.

Why Multi-Model Collaboration?

The author offers three practical reasons:

• Hedging against model biases and blind spots: Different LLMs have their own shortcomings in reasoning style and knowledge coverage. Having multiple agents tackle the same problem simultaneously allows them to cross-check each other and cover each other's blind spots.
• Distributing subscription usage: Spreading task loads across multiple LLM services avoids hitting the rate limits of any single provider.
• Combining local and cloud models: The author uses both cloud and local models simultaneously via OpenCode and oMLX, balancing performance, cost, and data privacy.

The idea of Multi-Model Orchestration draws from the software engineering principle of "separation of concerns" and the statistical concept of Ensemble Learning — a combination of multiple weak learners often outperforms a single strong one. Differences in pre-training data distribution, RLHF alignment strategies, and architectural design across LLMs give each model a distinct "cognitive style": for example, the Claude family excels at long-context reasoning and code security, GPT-4o has an edge in multimodal tasks, while local models (like Llama/Mistral running via MLX) offer irreplaceable advantages in data privacy and zero marginal cost. Rate limiting is especially prominent in enterprise use cases — mainstream LLM APIs typically cap usage by TPM (tokens per minute) and RPM (requests per minute), making multi-model load balancing a practical engineering approach to bypass bottlenecks and maintain high throughput.

These three points capture the universal frustration of heavy AI programming users — being "locked in" to a single provider is neither economical nor operationally resilient.

How awman's Dynamic Workflows Work

awman's dynamic workflow design is quite comprehensive and can be broken down into several key components.

Configuration Layer: Model Pool and Workflow Rules

First, users configure a whitelist of agents/models that dynamic workflows are allowed to call — essentially defining the available "troops" for the system. Second, users define "dynamic workflow guidance" — a set of rules passed to the "leader agent" that constrain the principles it should follow when designing a workflow.

This two-layer "whitelist + rules" configuration is fundamentally a set of guardrails on the AI's autonomous decision-making: it preserves the flexibility of self-directed orchestration while ensuring outputs align with user expectations.

The Leader Agent: Autonomously Designing an Execution Plan

The user designates a leader agent, which awman launches to generate a customized workflow. The workflow is produced as a TOML file describing three sections:

• Setup (initialization configuration)
• Agent graph (agent collaboration relationship graph)
• Teardown (cleanup)

awman's choice of TOML (Tom's Obvious, Minimal Language) as the workflow description format — over JSON or YAML — carries engineering significance. TOML's strong typing, comment-friendliness, and human readability make it an ideal choice for configuration files, and it's widely adopted in the Rust ecosystem (Cargo.toml) and Python project configuration. More critically, workflows are organized as an "Agent Graph" — a concept borrowed from Computational Graphs: each agent is a node in the graph, data dependencies form directed edges, and nodes without dependencies can execute in parallel. This graph structure allows workflows to describe both sequential tasks and naturally support fan-out parallelism and fan-in aggregation, forming the underlying structural basis for "5–7 agents running in parallel." The Setup/Teardown design borrows lifecycle management concepts from testing frameworks (like pytest fixtures) and container orchestration (like Kubernetes Jobs).

Once the workflow file is generated, awman automatically executes the entire process in "yolo mode" (no step-by-step human confirmation required). This means the pipeline from requirement to execution is nearly fully automated — users only need to define the goal and rules at the starting point.

Shared Context: Breaking Down Information Silos Across Agents

awman features a persistent "workflow context" directory that is mounted into each agent's runtime container, allowing agents to share notes, scripts, discovered issues, and instructions for subsequent agents.

Multi-agent system communication architectures generally fall into three categories: Message Passing, Shared Memory, and Blackboard Systems. awman's "workflow context directory" is an implementation of the Blackboard System — a concept originally proposed by Hayes-Roth in 1985 to describe multiple expert systems sharing a "blackboard" to collaboratively solve complex problems. Compared to point-to-point message passing, the blackboard system's advantage lies in loose coupling: agents don't need to know about each other's existence; they only need to read and write to the shared state. In the LLM agent context, this design is especially important because an LLM's context window is a finite resource — it's impossible to inject all agents' conversation histories into a single context. The file system as a persistent blackboard both overcomes context window limitations and provides a natural audit log, striking a balance between engineering practicality and theoretical elegance.

This design addresses one of the thorniest problems in multi-agent collaboration — information silos. When 5 to 7 agents run in parallel, if they cannot exchange intermediate results, collaboration degrades into each agent working in isolation. The shared context directory is essentially a "team whiteboard" that allows parallel agents to form a genuine collaborative network.

Quality Assurance: Engineering Rigor in Setup and Teardown

Another highlight of awman is how it brings software engineering rigor to AI workflow management.

The "isolated Worktree" technique awman uses maps directly to Git's git worktree feature — which allows multiple branches to be checked out simultaneously into different directories within the same repository, without cloning multiple copies. In the context of AI agent programming, this mechanism's value lies in: when multiple agents modify code in parallel, each operates within an independent filesystem view without conflicts, and the main codebase remains clean until the Teardown verification passes. This "isolate-verify-merge" three-phase pattern echoes the Feature Branch Workflow in software engineering, essentially bringing the rigor of code review into automated agent execution.

The Setup and Teardown steps ensure that isolated worktrees are properly initialized and that agents in the workflow don't break existing tests or build pipelines. More critically — when a Teardown step fails, the system can automatically launch "remediation agents" to resolve the problem. The fault-tolerance mechanism of automatically launching remediation agents corresponds to the Self-Healing System concept in DevOps, and represents a critical engineering threshold for AI agents to move from prototype to production-grade tools.

This is a notably mature fault-tolerance mechanism. It acknowledges the inherent uncertainty in AI agent outputs and uses an "auto-validate → auto-repair" feedback loop as a safety net, rather than handing unverified code directly to the user. This "trust but verify" engineering mindset is precisely the critical threshold that separates experimental AI programming tools from production-ready ones.

Real-World Results: Massive Requirements Decomposed into 20+ Step Parallel Workflows

According to the author, real-world usage has already shown "quite impressive results": large feature specifications can be transformed into workflows with more than 20 steps, with 5 to 7 agents running in parallel at any given execution stage.

The author explicitly states that dynamic workflows perform significantly better than handwritten workflows, and also better than single-prompt solutions. This comparison is quite compelling — it suggests that the value of dynamic workflows lies not only in eliminating the hassle of manual orchestration, but also in the AI leader's ability to design superior task decomposition structures that humans might never have conceived.

awman's choice of a TUI (Terminal User Interface) rather than a Web GUI reflects a philosophical divide in AI programming tool design. Representative TUI frameworks include Python's Textual and Rust's Ratatui, and their advantages include: running directly on remote servers via SSH, extremely low startup overhead, and natural scriptability. This choice clearly targets "power users" — developers who are comfortable in command-line environments and have high expectations for tool programmability. In contrast, AI programming tools centered on IDEs like Cursor and Windsurf lower the barrier to entry through visual diff views and inline suggestions, targeting a broader developer audience. The author's positioning of awman as "a workbench for advanced code agent users" is a direct reflection of these tradeoffs.

Trend Observations: What This Project Tells Us

awman reflects several important directions in the AI programming landscape.

First, the shift from single-model to multi-model orchestration. As mainstream model capabilities become increasingly homogeneous, combining the strengths of different models while avoiding their individual weaknesses is becoming a new lever for improving output quality.

Second, the open-source community is "reverse-engineering" closed-source capabilities. Claude's dynamic workflows are a proprietary product feature, while awman attempts to replicate and extend them in an open-source, framework-agnostic way. The pattern of "vendors define concepts, the community provides open implementations" will become increasingly common in the AI tooling ecosystem.

Third, engineering-grade fault tolerance is the dividing line for agent deployment. Auto-repair, environment isolation, test verification — these seemingly mundane engineering details are precisely what determines whether an AI agent can truly be used in production.

Of course, as an individual developer project, awman is currently aimed primarily at power users, and its configuration complexity, stability, and ecosystem maturity remain to be proven over time. But the multi-agent collaborative programming approach it demonstrates represents a direction worth continued attention in the evolution of AI development tools.

Key Takeaways