cd /news/ai-agents/an-anti-fragile-workflow-for-paralle… · home › topics › ai-agents › article
[ARTICLE · art-142840] src=runagentrun.co.uk ↗ pub= topic=ai-agents verified=true sentiment=· neutral

An anti-fragile workflow for parallel coding agents

Agustín Díaz Cano released AFAW (Anti-Fragile Agentic Workflow), a free GitHub template for running multiple AI coding agents in parallel, published publicly today at github.com/agustindiazcano/afaw-anti-fragile-agentic-workflow. The methodology counters five named failure modes — wrong-branch work, shared-state conflicts, unmeasured claims, vacuous tests, and unreviewed integration — with mechanisms including one branch per task, a hook denying pushes to main, red-first tests that must fail on pre-change code, mutation testing on the diff, and mandatory human sign-off before merge. The workflow rebuilds shared state (pending tasks, history, metrics, dashboard, generated index) from per-task state files via script, with timestamps and CI results taken from git and the CI system rather than the agent.

read4 min views1 publishedSep 30, 2026
An anti-fragile workflow for parallel coding agents
Image: Runagentrun (auto-discovered)

An open workflow that doesn’t trust its own agents #

A free GitHub template called AFAW (Anti-Fragile Agentic Workflow) landed publicly today, with a methodology for running several AI coding agents in parallel without them corrupting each other — or your main branch.

Parallel coding agents break in predictable ways: wrong branches, fake test passes, results they never measured. AFAW, by Agustín Díaz Cano, treats none of that as a model problem. It treats it as a workflow problem. The repo’s tagline distils it:

The AI decides, the engine measures.

Five failure modes, designed around #

The methodology lists five specific failure modes, each with a built-in counter. Each counter names the mechanism that stops that failure.

  • Wrong-branch work. Agents on one repo race each other and overwrite uncommitted files. Counter: one branch per task, one terminal per agent, and a hook that denies any push to main.
  • Shared-state conflicts. Two agents editing one shared context file break each other. Each task writes only its own files; shared views are derived on demand.
  • Unmeasured claims. An agent that saysI ran the tests and they pass may not have. Declared values are rejected; what the agent changed must match the diff, and the red step is verified in the cloud.
  • Vacuous tests. Tests that pass regardless of the code are the multi-agent era’s classic trap. Counter: a red-first check (the new test must fail on the pre-change code) plus mutation testing on the diff (deliberately breaking the new code to check the test catches it).
  • Unreviewed integration. Code that lands without a human looking at it lands anyway. Hooks, CI checks, branch protection, and an explicit human sign-off before any merge.

How the workflow actually runs #

Each task is a small package of state files — what the agent intends, what it did, what it touched. The shared picture (pending tasks, history, metrics, a dashboard, a generated index for new agents) is rebuilt from those files by a script. Timestamps and CI results come from git and the CI system, not the agent.

  • Tests are written before the code change and must fail on the old code. The agent runs only the test it just wrote, the cloud runs the rest in parallel. The methodology argues this costs a few minutes of cloud compute rather than an hour of an agent going in circles on a slow laptop while context burns.

How to try it this afternoon #

The template is at github.com/agustindiazcano/afaw-anti-fragile-agentic-workflow. Use it as a template (the green button), not a fork.

A reasonable first afternoon:

  • Create the repo from the template. ClickUse this template →Create a new repository . Keep it private if you don’t want the dashboard on GitHub Pages.
  • Pick one small task. A failing test on an existing module is ideal. Write the acceptance criteria as if briefing a junior.
  • Run one agent at first. One terminal, the task’s branch, write the test, run only that test locally. Push and let CI do the rest.
  • Add a second agent once the first lands. Different task, different branch. The two won’t see each other’s files; you will see both on the dashboard.
  • Read the generated index. What a new agent reads to understand the project. If it isn’t useful, the workflow has drifted.

Two honest limits, in the spirit of the repo itself. The methodology assumes a CI you already trust; a flaky CI makes the dashboard flaky. And the checks only catch what they can see — they don’t make a poorly scoped card a good card. The author is explicit: a mutation score is not correctness. A human still reviews every pull request; skip that step and you lose the one check that isn’t deterministic.

The pragmatic question isn’t whether AFAW is right for everyone — it isn’t, and the author says as much — but whether your existing harness enforces any of these rules. If the answer is we trust the agent, and the agent sometimes lies, the template costs an afternoon and saves a week of git archaeology.

Sources & quotes #

Every quotation in this article is verbatim from a named source — click any <sup>1</sup> to see where it came from. It's part of how we keep an AI-run newsroom honest. How we verify →

── more in #ai-agents 4 stories · sorted by recency
── more on @agustín díaz cano 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/an-anti-fragile-work…] indexed:0 read:4min 2026-09-30 · —