choosing-swarm-patterns
Skill1.1k starsChanged 51 days agoApache-2.0View on GitHub
Use when coordinating multiple AI agents with Agent Relay's workflow engine and need to pick the right orchestration pattern - covers the 10 core patterns (fan-out, pipeline, hub-spoke, consensus, mesh, handoff, cascade, dag, debate, hierarchical) plus 14 specialized ones, with decision framework and accurate SDK/YAML examples.
1 other project uses a version of this, 1 of them edited.
Adopted by
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Most recently taken up by
- AgentWorkforce/skillsedited, first seen Mar 19, 2026
Who's talking about AgentWorkforce/relay
- AgentWorkforce/relaycast“fix(sdk): preserve rich blocks in realtime message events”GitHub · Nov 8, 2026 · 2 reactions
- AgentWorkforce/agentrelay.com“Add QR card redirect for AI Engineer World Fair event”GitHub · Jul 2, 2026 · 2 reactions
- A Hacker News story“Show HN: Simple SDK for agent-to-agent communication”Hacker News · Apr 28, 2026 · 2 points
- JoeElder21/Joeyyy“deps(relay): bump agent-relay from 11.2.0 to 11.11.0 in /connectors/relay in the relay group across 1 …”GitHub · Aug 10, 2026 · 1 reactions
- AgentWorkforce/relayfile“feat: add relayfile control-plane client”GitHub · Jun 29, 2026 · 1 reactions
The biggest 5 of 21 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 21
Talked about on GitHub and Hacker News (21 times).
On GitHub · 20
- Nov 8, 2026fix(sdk): preserve rich blocks in realtime message events — AgentWorkforce/relaycast2 reactions · 3 comments
- Jul 2, 2026Add QR card redirect for AI Engineer World Fair event — AgentWorkforce/agentrelay.com2 reactions · 2 comments
- Aug 10, 2026deps(relay): bump agent-relay from 11.2.0 to 11.11.0 in /connectors/relay in the relay group across 1 directory — JoeElder21/Joeyyy1 reaction
- Jun 29, 2026feat: add relayfile control-plane client — AgentWorkforce/relayfile1 reaction · 4 comments
- Nov 3, 2026Ledger: task outcomes and expected evidence, not only done — solutionscay/skiff0 reactions
15 more on GitHub
- Nov 3, 2026Ledger: delivery records and receipts for sends and hand-offs — solutionscay/skiff0 reactions
- Oct 27, 2026Talk: Agent Led Development — milstan/sisw0 reactions · 1 comment
- Sep 28, 2026[Candidate] agentworkforce/relay/plugins/codex-relay-skill - agent-relay — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 28, 2026[Candidate] agentworkforce/relay/.openskills/writing-relayflows - writing-relayflows — ProSkillsMD/proskills0 reactions · 1 comment
- Sep 27, 2026[Candidate] agentworkforce/relay/.agents/skills/review-fix-signoff-loop - review-fix-signoff-loop — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 27, 2026[Candidate] agentworkforce/relay/.agents/skills/review-animations - review-animations — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 27, 2026[Candidate] agentworkforce/relay/.agents/skills/relay-80-100-workflow - relay-80-100-workflow — ProSkillsMD/proskills0 reactions · 1 comment
- Sep 26, 2026[Candidate] agentworkforce/relay/.agents/skills/emil-design-eng - emil-design-eng — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 26, 2026[Candidate] agentworkforce/relay/.agents/skills/creating-agent-skills-skill - creating-agent-skills — ProSkillsMD/proskills0 reactions · 2 comments
- Sep 26, 2026[Candidate] agentworkforce/relay/.agents/skills/choosing-swarm-patterns - choosing-swarm-patterns — ProSkillsMD/proskills0 reactions · 1 comment
- Sep 14, 2026Relay agent transport returns spawn metadata before task completion — AgentWorkforce/flows0 reactions
- Sep 11, 2026mount daemon can miss notify-flush SIGUSR1 acknowledgement in clean RelayFlow sandbox — AgentWorkforce/relayfile0 reactions
- Sep 10, 2026mount --once can exhaust its timeout on a 429 WebSocket dial before cursor resolution — AgentWorkforce/relayfile0 reactions
- Sep 6, 2026Rust SDK erases repeated 5xx registration diagnostics as Max retries exceeded — AgentWorkforce/relaycast0 reactions · 2 comments
- Aug 15, 2026factory dispatch exits 0 on hard failure — refusals are indistinguishable from success — AgentWorkforce/software-garden0 reactions
On Hacker News · 1
- Apr 28, 2026Show HN: Simple SDK for agent-to-agent communication2 points
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- AgentWorkforce/skills★ 599% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository27 other files it gives its agents.
- AGENTS.mdAGENTS.md
- creating-agent-skillsSkill
- emil-design-engSkill
- orchestrating-agent-relaySkill
- relay-80-100-workflowSkill
- review-animationsSkill
- review-fix-signoff-loopSkill
- setting-up-relayfileSkill
- using-agent-relaySkill
- writing-relayflowsSkill
- browser-testing-with-screenshotsSkill
- choosing-swarm-patternsSkill
- creating-claude-agentsSkill
- creating-claude-hooksSkill
- creating-claude-rulesSkill
- creating-skillsSkill
- debugging-websocket-issuesSkill
- deploying-to-staging-environmentSkill
- frontend-designSkill
- github-oauth-nango-integrationSkill
- implementing-command-palettesSkill
- orchestrating-agent-relaySkill
- prpm-json-best-practicesSkill
- relay-80-100-workflowSkill
- review-fix-signoff-loopSkill
- setting-up-relayfileSkill
- using-agent-relaySkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 2 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 92
Run an independent self-review/fresh-eyes agent that reads the actual files and recent repo context, not just the chat transcript.
- Distinctive: line 94
After squads converge, run a final two-agent review team, usually one Claude reviewer and one Codex reviewer, independently.
- Very specific: line 96
Use supervisor or hub-spoke when a lead needs to coordinate live squads.
- Very specific: line 97
Use review-loop when the main risk is code quality and feedback iteration.
- Very specific: line 98
Use reflection when critic feedback should loop directly back to producers.
- Very specific: line 99
Use verifier when completion evidence matters more than design debate.
- Very specific: line 100
Use competitive only when independent alternative implementations are useful.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Overview
Overview
The Agent Relay SDK (@agent-relay/sdk) supports 24 swarm patterns via a single swarm.pattern field. Patterns are configured declaratively in YAML — there are no standalone fanOut(...) / hubAndSpoke(...) helpers. Pick the simplest pattern that solves the problem; add complexity only when the system proves it's insufficient.
Run a pattern
TypeScript SDK runner
import { runWorkflow } from '@agent-relay/sdk/workflows';
const run = await runWorkflow('workflows/feature-dev.yaml', {
vars: { task: 'Add OAuth login' },
});Quick Decision Framework
Is the task independent per agent?
YES → fan-out (parallel workers, hub collects)
Does each step need the previous step's output?
YES → Is it strictly linear?
YES → pipeline
NO → dag (parallel where possible, `dependsOn` edges)
Does a coordinator need to stay alive and adapt?
YES → hub-spoke (single-level hub + workers)
hierarchical (structurally identical in current impl; use for naming/intent)
Is the task about making a decision?
YES → Do agents need to argue opposing sides?
YES → debate (adversarial, full mesh)
NO → consensus (cooperative, full mesh + coordination.consensusStrategy)
Does the right specialist emerge during processing?
YES → handoff (sequential chain, one active at a time)
Do all agents need to freely collaborate?
YES → mesh (full peer-to-peer edges)
Is cost the primary concern?
YES → cascade (chain of increasingly capable agents; each step's prompt
decides whether to pass through or redo the prior output)Pattern Reference (Core 10)
| # | Pattern | Topology (actual edges) | Best For |
| 1 | fan-out | Hub broadcasts to N workers; workers reply to hub only | Independent subtasks (reviews, research, tests) |
| 2 | pipeline | Linear chain (agent_i → agent_{i+1}) | Ordered stages (design → implement → test) |
| 3 | hub-spoke | Hub ↔ spokes (bidirectional); no spoke-to-spoke | Dynamic coordination, lead reviews/adjusts |
| 4 | consensus | Full mesh; decision via coordination.consensusStrategy | Architecture decisions, approval gates |
| 5 | mesh | Full mesh (every agent ↔ every other) | Brainstorming, collaborative debugging |
| 6 | handoff | Chain; passes control forward | Triage, specialist routing |
| 7 | cascade | Chain of dependsOn steps; all run on success, downstream skipped on upstream failure (no built-in "fall through") | Cost optimization: cheap first, each step's prompt passes through or redoes |
| 8 | dag | Edges from step dependsOn | Mixed dependencies, parallel where possible |
| 9 | debate | Full mesh (same topology as mesh; roles drive behavior) | Rigorous adversarial examination |
| 10 | hierarchical | Hub + subordinates (single-level in current impl) | Large teams; semantic distinction from hub-spoke |
Heads up:
hierarchicalresolves to the same edge structure ashub-spokeincoordinator.ts:313-319. Multi-level tree topology is not currently implemented — use pattern name for intent, but expect the same runtime graph.
Additional Patterns (role-driven)
These 14 additional patterns exist in SwarmPattern (types.ts:114-139). The coordinator has role-based auto-selection heuristics (coordinator.ts:51-165), but they only fire when swarm.pattern is omitted — YAML validation requires it (runner.ts:2105-2117), so auto-selection is effectively a programmatic-API feature. In YAML, set swarm.pattern explicitly.
Topology is still resolved per-pattern once selected; the "Triggering roles" column reflects what the coordinator looks for to shape edges (per coordinator.ts:250-450):
| Pattern | Roles the topology keys off | Topology |
map-reduce | mapper + reducer | coordinator → mappers → reducers → coordinator |
scatter-gather | — | hub → workers → hub |
supervisor | supervisor | supervisor ↔ workers |
reflection | critic or reviewer (auto-select uses critic only) | producers → critic → producers (loop) |
red-team | attacker/red-team + defender/blue-team | adversarial mesh with optional judges |
verifier | verifier | producers → verifiers → back to producers |
auction | auctioneer | auctioneer → bidders → auctioneer |
escalation | tier-* | tiered chain, escalate up / report down |
saga | saga-orchestrator, compensate-handler | orchestrator ↔ participants |
circuit-breaker | primary + fallback/backup | try primary, fallback on failure |
blackboard | blackboard / shared-workspace | shared state hub |
swarm | hive-mind / swarm-agent | stigmergy-style |
competitive | — (declared explicitly) | independent parallel implementations + judge |
review-loop | implement* + 2+ reviewer* | implementer ↔ reviewers |
Structured Squad Review Loop
- Split the work into bounded implementation squads. Each squad owns a non-overlapping file or subsystem scope.
- Give each squad an implementer plus a shadow/review partner. The shadow follows the implementer in real time, checks alignment with the spec, and posts concise feedback before the work drifts.
- Require the implementer to self-reflect before external review: compare the final diff against the spec, AGENTS.md / CLAUDE.md, recent local conventions, tests, and declared non-goals.
- Run an independent self-review/fresh-eyes agent that reads the actual files and recent repo context, not just the chat transcript.
- Send that review back to the implementer for one repair round.
- After squads converge, run a final two-agent review team, usually one Claude reviewer and one Codex reviewer, independently. They compare notes, merge findings, and produce one final verdict.
- Spawn fresh fix agents for final-review findings. Those fix agents self-reflect, then the final reviewers re-check the post-fix state until the spec is fully satisfied or a blocker is documented.
- Use
supervisororhub-spokewhen a lead needs to coordinate live squads. - Use
review-loopwhen the main risk is code quality and feedback iteration. - Use
reflectionwhen critic feedback should loop directly back to producers. - Use
verifierwhen completion evidence matters more than design debate. - Use
competitiveonly when independent alternative implementations are useful; otherwise split by ownership scope.
Pattern Details
The per-pattern YAML snippets below show only the pattern-relevant fields. A runnable YAML file also needs the required top-level version and name; see the Complete YAML Example.
1. fan-out — Parallel Workers
swarm: { pattern: fan-out }
agents:
- { name: lead, cli: claude, role: lead }
- { name: auth-rev, cli: claude, role: worker, interactive: false }
- { name: db-rev, cli: claude, role: worker, interactive: false }
workflows:
- name: review
steps:
- { name: review-auth, agent: auth-rev, task: 'Review auth.ts' }
- { name: review-db, agent: db-rev, task: 'Review db.ts' }2. pipeline — Sequential Stages
swarm: { pattern: pipeline }
agents:
- { name: designer, cli: claude }
- { name: implementer, cli: codex, interactive: false }
- { name: tester, cli: codex, interactive: false }
workflows:
- name: build
steps:
- {
name: design,
agent: designer,
task: 'Design the API schema',
verification: { type: output_contains, value: DONE },
}
- {
name: implement,
agent: implementer,
dependsOn: [design],
task: 'Implement: {{steps.design.output}}',
}
- { name: test, agent: tester, dependsOn: [implement], task: 'Write integration tests' }3. hub-spoke — Persistent Coordinator
swarm:
pattern: hub-spoke
channel: swarm-api
agents:
- { name: lead, cli: claude, role: lead }
- { name: db-worker, cli: claude, role: worker }
- { name: api-worker, cli: claude, role: worker }
workflows:
- name: api-build
steps:
- { name: models, agent: db-worker, task: 'Build database models' }
- { name: routes, agent: api-worker, task: 'Build route handlers', dependsOn: [models] }
- { name: review, agent: lead, task: 'Review everything', dependsOn: [routes] }4. consensus — Cooperative Voting
swarm: { pattern: consensus }
agents:
- { name: perf, cli: claude, role: reviewer }
- { name: dx, cli: claude, role: reviewer }
- { name: sec, cli: claude, role: reviewer }
coordination:
consensusStrategy: majority # declarative marker: majority | unanimous | quorum
votingThreshold: 0.66
workflows:
- name: decide
steps:
- { name: evaluate-perf, agent: perf, task: 'Evaluate perf of Fastify migration' }
- { name: evaluate-dx, agent: dx, task: 'Evaluate DX of Fastify migration' }
- { name: evaluate-sec, agent: sec, task: 'Evaluate security of Fastify migration' }5. mesh — Peer Collaboration
swarm:
pattern: mesh
channel: swarm-debug
agents:
- { name: logs, cli: claude }
- { name: code, cli: claude }
- { name: repro, cli: claude }
workflows:
- name: debug-auth
steps:
- { name: logs, agent: logs, task: 'Check server logs' }
- { name: code, agent: code, task: 'Review auth code' }
- { name: repro, agent: repro, task: 'Write repro test' }6. handoff — Dynamic Routing
swarm: { pattern: handoff }
agents:
- { name: triage, cli: claude }
- { name: billing, cli: claude }
- { name: tech, cli: claude }
workflows:
- name: support
steps:
- { name: triage, agent: triage, task: 'Triage: {{request}}' }
- { name: billing, agent: billing, dependsOn: [triage], task: 'Handle billing' }
- { name: tech, agent: tech, dependsOn: [triage], task: 'Handle tech issues' }7. cascade — Cost-Aware Fallthrough
swarm: { pattern: cascade }
agents:
- { name: haiku, cli: claude, model: claude-haiku-4-5-20251001 }
- { name: sonnet, cli: claude, model: claude-sonnet-4-6 }
- { name: opus, cli: claude, model: claude-opus-4-7 }
workflows:
- name: answer
steps:
- { name: try-haiku, agent: haiku, task: '{{question}}' }
- name: try-sonnet
agent: sonnet
dependsOn: [try-haiku]
task: "If this is a complete answer, echo it verbatim. Otherwise answer anew:\n{{steps.try-haiku.output}}"
- name: try-opus
agent: opus
dependsOn: [try-sonnet]
task: "Final-tier answer, using prior attempts for context:\n{{steps.try-sonnet.output}}"8. dag — Directed Acyclic Graph
swarm:
pattern: dag
maxConcurrency: 3
agents:
- { name: dev, cli: codex, role: worker }
workflows:
- name: fullstack
steps:
- { name: scaffold, agent: dev, task: 'Create project scaffold' }
- { name: frontend, agent: dev, task: 'Build React UI', dependsOn: [scaffold] }
- { name: backend, agent: dev, task: 'Build API', dependsOn: [scaffold] }
- { name: integrate, agent: dev, task: 'Wire together', dependsOn: [frontend, backend] }9. debate — Adversarial Refinement
swarm: { pattern: debate }
agents:
- { name: pro, cli: claude, role: debater, task: 'Argue FOR monorepo' }
- { name: con, cli: claude, role: debater, task: 'Argue FOR polyrepo' }
- { name: judge, cli: claude, role: judge, task: 'Decide after 3 rounds' }
coordination:
barriers:
- { name: debate-done, waitFor: [pro-round-3, con-round-3] }10. hierarchical — Multi-Level (structurally hub-spoke today)
swarm: { pattern: hierarchical }
agents:
- { name: lead, cli: claude, role: lead }
- { name: fe-coord, cli: claude, role: coordinator }
- { name: be-coord, cli: claude, role: coordinator }
- { name: fe-dev, cli: codex, role: worker, interactive: false }
- { name: be-dev, cli: codex, role: worker, interactive: false }
workflows:
- name: large-team
steps:
- { name: plan, agent: lead, task: 'Coordinate full-stack app' }
- { name: fe-plan, agent: fe-coord, task: 'Manage frontend', dependsOn: [plan] }
- { name: be-plan, agent: be-coord, task: 'Manage backend', dependsOn: [plan] }
- { name: fe-impl, agent: fe-dev, task: 'Build components', dependsOn: [fe-plan] }
- { name: be-impl, agent: be-dev, task: 'Build API', dependsOn: [be-plan] }Verification & Completion Signals
An agent step can complete in several ways (runner.ts:5353-5395, runner.ts:4527-4538):
verification:
type: output_contains # or: exit_code | file_exists | custom
value: DONE # or: PLAN_COMPLETE, IMPLEMENTATION_COMPLETE, REVIEW_COMPLETEAgent Relay MCP — Correct Tool Names
The old category-expanded names are wrong. Current Agent Relay MCP tools are
flat names. In a client that decorates MCP tools, the prefix comes from the
configured server key. With the relay broker's agent-relay server key, Claude
Code users commonly see mcp__agent-relay__send_dm; Codex and opencode users
see the bare canonical name send_dm.
| Purpose | Canonical tool | Claude Code form with agent-relay key |
| Send DM to another agent | send_dm | mcp__agent-relay__send_dm |
| Check inbox | check_inbox | mcp__agent-relay__check_inbox |
| List agents | list_agents | mcp__agent-relay__list_agents |
| Post to a channel | post_message | mcp__agent-relay__post_message |
| Reply in a thread | reply_to_thread | mcp__agent-relay__reply_to_thread |
| Spawn sub-agent | add_agent | mcp__agent-relay__add_agent |
| Remove sub-agent | remove_agent | mcp__agent-relay__remove_agent |
interactive: falseagents run as non-interactive subprocesses with no relay connection. They must not call Relay MCP tools.
Reflection (Trajectories)
Reflection is not a reflectionThreshold callback. It's configured via the trajectories: block:
trajectories:
enabled: true
reflectOnBarriers: true # config flag exists but runner does NOT currently invoke this path
reflectOnConverge: true # fires at parallel convergence points (runner.ts:2762-2779)
autoDecisions: true # record retry/skip/fail decisionsCommon Mistakes
| Mistake | Why It Fails | Fix |
| Using mesh/debate for everything | Full-mesh blows up message volume past ~5 agents | Use hub-spoke or dag for most tasks |
| Pipeline for independent work | Sequential bottleneck | Use fan-out or dag |
| Hub-spoke for 2 agents | Hub is unnecessary overhead | Use pipeline or fan-out |
Expecting consensusStrategy to tally votes | Runner has no vote-tally logic; field only affects coordinator auto-selection | Aggregate votes in a judge/lead step that reads {{steps.*.output}} |
| Handoff with "routing = skip other branches" | Skipping only fires on upstream failure, not routing decisions | Emit a routing token in triage output; downstream prompts self-no-op if token doesn't match |
| Cascade expecting skip-on-success | Runner has no cascade skip logic; failed upstream skips downstream | Chain downstream prompts to pass-through or redo based on {{steps.previous.output}} |
Relying on reflectOnBarriers | Config flag exists but runner never calls it | Use reflectOnConverge for convergence reflection; use reflection pattern for critic loops |
interactive: false agent calling MCP | Non-interactive subprocess has no relay | Use interactive: true (default) or emit output on stdout |
Relying on multi-level hierarchical | Topology is single-level hub in current impl | Use pattern for naming; model levels via dependsOn graph |
Writing mcp__relaycast__send(...) | Wrong tool name | Use post_message / mcp__agent-relay__post_message or send_dm / mcp__agent-relay__send_dm |
Resume & Re-run
// Resume a failed run:
await runWorkflow('feature-dev.yaml', { resume: '<runId>' });
// Skip ahead, re-using cached outputs from an earlier run:
await runWorkflow('feature-dev.yaml', {
startFrom: 'review',
previousRunId: '<runId>',
});Complete YAML Example
version: '1.0'
name: feature-dev
description: 'Blueprint-style feature development with quality gates.'
swarm:
pattern: hub-spoke
maxConcurrency: 2
timeoutMs: 3600000
channel: swarm-feature-dev
idleNudge: { nudgeAfterMs: 120000, escalateAfterMs: 120000, maxNudges: 1 }
agents:
- { name: lead, cli: claude, role: lead, permissions: { access: full } }
- { name: planner, cli: codex, role: planner, interactive: false, permissions: { access: readonly } }
- { name: developer, cli: codex, role: worker, interactive: false, permissions: { access: readwrite } }
- { name: reviewer, cli: claude, role: reviewer, permissions: { access: readonly } }
workflows:
- name: feature-delivery
onError: retry
preflight:
- { command: 'git status --porcelain', failIf: non-empty, description: 'Clean worktree' }
steps:
- name: plan
agent: planner
task: 'Plan: {{task}}'
verification: { type: output_contains, value: PLAN_COMPLETE }
- name: implement
agent: developer
dependsOn: [plan]
task: 'Implement: {{steps.plan.output}}'
verification: { type: output_contains, value: IMPLEMENTATION_COMPLETE }
- name: test
type: deterministic
dependsOn: [implement]
command: npm test
- name: review
agent: reviewer
dependsOn: [test]
task: 'Review implementation'
verification: { type: output_contains, value: REVIEW_COMPLETE }
coordination:
barriers:
- { name: delivery-ready, waitFor: [plan, implement, review], timeoutMs: 900000 }
trajectories:
enabled: true
reflectOnBarriers: true
reflectOnConverge: true
errorHandling:
strategy: retry
maxRetries: 2
retryDelayMs: 5000Source of Truth
| Claim | File |
| Pattern enum (24 patterns) | packages/sdk/src/workflows/types.ts:114-139 |
| Topology resolution per pattern | packages/sdk/src/workflows/coordinator.ts:240-450 |
| Interactive-only topology edges | packages/sdk/src/workflows/coordinator.ts:218-237 |
| Pattern auto-selection heuristics (programmatic API only) | packages/sdk/src/workflows/coordinator.ts:51-165 |
runWorkflow(yamlPath, options) | packages/sdk/src/workflows/run.ts |
YAML validation requires version + name + swarm.pattern | packages/sdk/src/workflows/runner.ts:2105-2117 |
| MCP tool names cited in convention-injection | packages/sdk/src/relay-adapter.ts:29-36 |
| Completion modes (verification / evidence / owner / process-exit) | packages/sdk/src/workflows/runner.ts:5353-5395, 4527-4538 |
| Completion via PTY + summary fallback | packages/sdk/src/workflows/runner.ts:6600-6615 |
| Downstream skip on upstream failure (not success) | packages/sdk/src/workflows/runner.ts:7057-7088, step-executor.ts:329-334 |
Trajectory reflection (only reflectOnConverge wired) | packages/sdk/src/workflows/runner.ts:2762-2779, trajectory.ts:173-190 |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

