Factory vs YYLO
Factory wins · 29–14 (18 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to FactoryFactory hosts an actual llms.txt at docs.factory.ai/llms.txt (HTTP 200) confirmed by direct probe, and its docs describe an agent-native platform with structured agent-oriented documentation (droid-cli, agent-readiness, missions) that an agent could be pointed at. missing for 10: independent/hands-on confirmation that an agent successfully consumes llms.txt in practice, and no explicit vendor statement encouraging users to point agents at llms.txt.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.factory.ai/llms.txt # Factory Documentation > Documentation for Factory, the agent-native software…”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “Run the /readiness-report slash command in a Factory App web or desktop session, or in the Droid CLI, to evaluate a repository's readiness l…”
YYLOnone0/10Direct probes show no llms.txt (404), no docs.md machine-readable variant (404), and no OpenAPI spec (404), meaning there is no agent-oriented docs endpoint to point an agent at; the only docs are standard human-facing HTML pages.
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to FactoryFactory documents droid exec as a one-shot CLI command explicitly designed for CI/CD pipelines, shell scripts, and batch processing, with tiered autonomy controls for unattended operation. This directly satisfies headless/CI automation. Missing for 10: independent/hands-on third-party verification of CI usage and more detail on exit codes/output formats for pipeline integration.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [probe] “official CLI documented at https://docs.factory.ai/droid-cli/quickstart”
YYLO is a CLI orchestrator with scriptable commands (init, task start, ledger, loop, parallel-runner, run-until-completion) that produce structured watch receipts with exit codes and JSON state, and it's installable via npm as a public package with documented bins (yylo, yy, ypl) suitable for CI invocation. missing for 10: no explicit CI pipeline example (e.g., GitHub Actions config), no independent hands-on report of running it headlessly in CI, and llms.txt/openapi probes returned 404 suggesting thinner machine-readable integration docs.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
- [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
- [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
- [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · round to FactoryDocs explicitly state Droid CLI can connect MCP tools alongside Jira/Notion/Slack/Linear/PagerDuty integrations, confirming MCP client support. However, there is no detail on setup/configuration process, supported transport types, or independent/hands-on confirmation of MCP tool usage in practice. missing for 10: configuration details for adding MCP servers, examples of MCP tools being invoked, independent verification of functionality.
- [claimed-docs] “Connect Jira, Notion, Slack, Linear, PagerDuty, and MCP tools to keep development synchronized with team systems”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
ai-native userConnect an agent via an official MCP server
weight 3 · round to FactoryFactory is primarily a coding agent (Droid), and factory-docs-4 shows it can connect OUT to MCP tools (client-side), which wouldn't count under the na rule — but factory-probe-3 explicitly indicates an official MCP server is documented at docs.factory.ai/harness/mcp, flipping this to the applicable server-side capability. However, the evidence pack only confirms the page's existence via a probe hit with no detail on what the server exposes or how other agents connect to it. Missing for 10: detailed documentation of the MCP server's tool surface, setup instructions for external agents, and independent confirmation of a working connection.
- [probe] “official MCP server documented at https://docs.factory.ai/harness/mcp”
- [claimed-docs] “Connect Jira, Notion, Slack, Linear, PagerDuty, and MCP tools to keep development synchronized with team systems”
YYLOnone0/10YYLO is a CLI orchestrator for coding agents/workflows, and as such platform-type product it could plausibly ship an official MCP server for other agents to connect to, but no evidence pack item mentions MCP at all (only 'open-standard' skills installation, ledger, workflow-runner, etc.). No official MCP server documentation, endpoint, or announcement exists in the evidence.
ai-native userUse an official CLI
weight 2 · round to FactoryFactory ships an official Droid CLI with documented quickstart, terminal/editor/Git integration, bash mode, one-shot exec for CI/CD, and slash-command features—clearly an official CLI for AI-native workflows. Missing for 10: independent/hands-on third-party corroboration beyond vendor docs.
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “Press ! to toggle bash mode and run shell commands directly without AI interpretation.”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [probe] “official CLI documented at https://docs.factory.ai/droid-cli/quickstart”
YYLO ships an official CLI (@yylo/cli) with documented commands (init, ledger, loop, doctor, task start, merge land) and is verifiably published on npm plus MIT-licensed on GitHub, matching an AI-native agentic workflow tool. missing for 10: independent third-party usage reports/reviews beyond vendor docs and registry probes, and some llms.txt/docs-md/openapi endpoints 404 suggesting incomplete machine-readable doc surface.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
- [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
ai-native userDrive the product through a documented public API
weight 3 · round to FactoryFactory documents a public API for creating and driving Droid sessions (factory-docs-13) plus CLI/exec automation paths (droid exec, CI/CD) that give programmatic control, but there's no discoverable OpenAPI/swagger spec (probe found only 404s), suggesting the API reference is thinner or less formally specified than a full REST API story would require. missing for 10: a published OpenAPI/swagger schema, broader API endpoint coverage beyond sessions, independent third-party confirmation of API usage.
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.factory.ai/openapi.json, https://docs.factory.ai/swagger.json, https://docs.factory.ai/…”
YYLO exposes a well-documented CLI (`yylo`, `yy`, `ypl`) with structured JSON output, a ledger/task API, YAML workflow contracts, and templating for chaining steps, which an AI-native user could script against — supported by first-party docs and a live public npm package. However, there is no true public HTTP/OpenAPI-style API: explicit probes for llms.txt, docs.md, and OpenAPI specs all returned 404, meaning the only 'API' is the CLI surface, not a documented network API a remote agent could call directly. Missing for 10: an OpenAPI/REST API spec, an llms.txt or machine-readable API manifest, and evidence of remote/programmatic (non-CLI) invocation.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
- [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
- [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
- [probe] “PROBE llms.txt: HTTP 404 at https://yylo.dev/llms.txt”
- [probe] “PROBE docs-md: HTTP 404 at https://yylo.dev/docs/yylo.md”
- [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
ai-native userBuild against official SDKs
weight 2 · round to FactoryFactory documents an API reference for creating/driving Droid sessions (factory-docs-13) and MCP/CLI integration points, suggesting some programmatic access, but there is no evidence of an official language SDK (Python/JS/etc.) and the OpenAPI spec probe returned 404s, indicating thin or unpublished API tooling. missing for 10: no named official SDK packages, no OpenAPI/schema availability, no code samples showing SDK usage.
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.factory.ai/openapi.json, https://docs.factory.ai/swagger.json, https://docs.factory.ai/…”
- [probe] “official MCP server documented at https://docs.factory.ai/harness/mcp”
YYLOnone0/10YYLO ships an official CLI (@yylo/cli) and open MIT-licensed repo, but there is no evidence of an SDK (client library/API) to build against — OpenAPI/spec probes and llms.txt/docs-md endpoints all return 404, and no SDK docs are mentioned anywhere in the pack.
- [probe] “PROBE llms.txt: HTTP 404 at https://yylo.dev/llms.txt”
- [probe] “PROBE docs-md: HTTP 404 at https://yylo.dev/docs/yylo.md”
- [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
- [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnFactorynone0/10No evidence of webhook subscription support; docs mention API sessions, MCP tools, and integrations (Jira, Slack, etc.) but nothing about webhooks for event notifications. missing for 10: any webhook documentation, event types, subscription endpoints, or third-party confirmation of webhook support.
YYLOnone0/10No evidence of any webhook subscription mechanism; YYLO documents Slack/GitHub integrations pulling into kanban but nothing about outbound event webhooks, and API/openapi probes returned 404s.
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
- [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”
Agentic features
ai-native userSet up automations that run autonomously in the background
weight 2 · round to YYLOdroid exec supports one-shot autonomous runs with tiered autonomy suited for CI/CD, scripts, and batch automation, and the API supports creating/driving Droid sessions programmatically, which enables background automation setups. However, there's no evidence of a scheduling/trigger system (e.g., cron-like or event-driven automations) or a dedicated 'automations' dashboard for persistent background jobs. Missing for 10: native scheduling/triggers for autonomous background runs, independent hands-on confirmation of unattended long-running automations, and a dedicated automations management UI.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [claimed-docs] “Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration.”
Docs describe multiple mechanisms for autonomous, repeated execution — `yy loop` for repeating shell commands, run-until-completion scripts that iterate until kanban work is done, a workflow-runner for chained multi-step automations, a bounded parallel-runner for concurrent fan-out, and integrations that pull Slack/GitHub work into a kanban queue and post results back. This supports background-style autonomous task execution, and sessions can be resumed via `yy continue SESSION_ID` rather than reconstructed from a terminal. However, there's no evidence of a persistent scheduler/cron-like trigger or a hosted background service — everything appears CLI/session-driven, and there is no independent or hands-on confirmation that these loops truly run unattended over long periods. Missing for 10: evidence of scheduled/triggered automations independent of an active session, and third-party corroboration of long-running unattended execution.
- [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
- [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
- [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
- [claimed-docs] “Choose Workflow Runner when a step consumes `{{ steps.<id>.response }}`, a generated file, or a session from an earlier step.”
- [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · round to FactoryFactory's core product is built around delegating tasks to Droid agents via App, CLI, or exec, with clear docs on task delegation, custom droids, and session management. missing for 10: independent/hands-on corroboration beyond vendor docs, and quantified reliability of delegated task completion.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “delegate scoped tasks to Custom Droids via /droids, and package reusable procedures as Skills with /skills or /create-skill”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
YYLO's CLI lets a user delegate a task to an AI agent via `--subagent claude` and manage it through kanban/ledger workflows, so task delegation to an AI is documented, but the AI capability is an external subagent (e.g., Claude) invoked by the orchestrator rather than an assistant built into YYLO itself. missing for 10: evidence of an assistant embedded in the product (not requiring an external model/agent), and any first-party assistant UI/API rather than orchestration of third-party agents.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
ai-native userOperate the product with natural-language commands
weight 2 · round to FactoryFactory's Droid CLI and App let users delegate tasks, run commands, and manage workflows via natural-language prompts, with bash-mode fallback and slash commands (/droids, /skills, /readiness-report) layered on top of NL interaction, showing deep agentic natural-language operation across CLI, exec, and Missions. missing for 10: independent/hands-on user reports confirming NL command quality and reliability outside vendor docs.
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “Press ! to toggle bash mode and run shell commands directly without AI interpretation.”
- [claimed-docs] “delegate scoped tasks to Custom Droids via /droids, and package reusable procedures as Skills with /skills or /create-skill”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration.”
- [probe] “official CLI documented at https://docs.factory.ai/droid-cli/quickstart”
YYLOnone0/10YYLO's interface is a structured CLI (yylo/yy commands with explicit flags like --task, --subagent) rather than a natural-language command interface; the --task string is passed through to a subagent, not parsed as an operator instruction to YYLO itself. No evidence shows a chat-like or NL command surface for driving YYLO's own operations (init, start, finish, ledger, merge, etc.).
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round drawnFactorynone0/10Factory does have an API reference section (docs.factory.ai/api-reference/sessions) but there's no evidence of an interactive, runnable-example explorer — the probe for standard OpenAPI/Swagger interactive docs (openapi.json, swagger.json, etc.) returned 404 at all candidate paths, suggesting no live 'try it' interface exists.
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.factory.ai/openapi.json, https://docs.factory.ai/swagger.json, https://docs.factory.ai/…”
YYLOnone0/10YYLO is a CLI orchestrator for coding agents, not an API product; there is no evidence of an interactive API reference, and explicit probes for openapi.json/swagger.json and llms.txt all return 404, indicating no such reference exists.
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round drawnFactorynone0/10Factory has an API reference (sessions endpoints) but probes for standard OpenAPI/swagger spec locations all returned 404, indicating no downloadable machine-readable spec is published; missing for 10: any accessible OpenAPI/swagger JSON file or equivalent machine-readable spec.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.factory.ai/openapi.json, https://docs.factory.ai/swagger.json, https://docs.factory.ai/…”
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
YYLOnone0/10Explicit probes for llms.txt, docs-md, and OpenAPI/swagger endpoints all returned 404, and no evidence shows any downloadable machine-readable API spec; YYLO is a CLI orchestrator without a documented API surface to spec.
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to YYLOFactorynone0/10Factory's evidence covers coding agent workflows (CLI, sessions, MCP, readiness reports) but nothing addresses a sandbox environment for testing separate from production data. No mention of sandbox mode, staging environment, or data isolation guarantees.
YYLO's task worktrees isolate work from the protected target SHA, preflight checks are documented as read-only, and merges compose changes into a private detached candidate rather than touching the live branch directly, while the benchmark tool explicitly runs 'isolated attempts' with 'recover safely' semantics—together these describe a sandboxed testing flow that avoids touching the protected/production state. Missing for 10: explicit 'production data' terminology or a dedicated staging/prod environment concept, and independent (non-vendor) confirmation that isolation holds up in practice.
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “`doctor workspace` is intentionally nonzero when it finds an actionable topology problem; it never fetches or changes the workspace.”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
- [claimed-docs] “Plan immutable experiments, execute isolated attempts, retain evaluator provenance, recover safely, and produce bounded reports.”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnFactorynone0/10There is an API reference (sessions) but no evidence of API versioning scheme or a documented deprecation policy; the OpenAPI spec probe even returned 404s across candidate paths, suggesting no formal versioned spec is exposed.
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.factory.ai/openapi.json, https://docs.factory.ai/swagger.json, https://docs.factory.ai/…”
YYLOnone0/10No evidence of any versioned API contract or documented deprecation policy; the product is a CLI orchestrator with a version like 0.2.1rc6, but no API versioning scheme or deprecation guarantees are mentioned, and openapi/llms.txt probes returned 404.
- [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”
- [probe] “PROBE llms.txt: HTTP 404 at https://yylo.dev/llms.txt”
- [probe] “PROBE docs-md: HTTP 404 at https://yylo.dev/docs/yylo.md”
- [claimed-docs] “The 0.2.1rc6 channel adds ID-first general Records and typed task, wiki, workflow, and artifact profiles.”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round to YYLOdroid exec is explicitly documented as a one-shot command 'ideal for CI/CD pipelines, shell scripts, and batch processing,' and the API lets users programmatically create/drive many Droid sessions, both enabling bulk automation across items. However, there's no explicit example, docs, or tooling demonstrating a native 'run across many files/repos/tickets at once' bulk operation feature — it relies on the user scripting droid exec in loops rather than a built-in bulk-operation UI/command. Missing for 10: a dedicated bulk-operation command or documented multi-item batch workflow example, and independent/hands-on evidence of it working at scale.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [claimed-docs] “Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration.”
YYLO's parallel-runner explicitly supports 'bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item,' and run-until-completion repeats iterations until all kanban work is done, directly enabling bulk operations across many items with automated evidence capture. This is corroborated by a live public CLI (npm registry, MIT-licensed source), though there's no independent hands-on report of large-scale fan-out in practice. Missing for 10: independent/third-party validation of bulk-scale runs and concrete concurrency limits or throughput numbers.
- [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
- [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
- [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
- [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to YYLOFactory's droid exec is explicitly designed to run as a one-shot command in CI/CD pipelines, shell scripts, and batch jobs, which implies it can be wired to external events (e.g., git hooks, CI triggers) with tiered autonomy controlling what runs unattended — but this is an execution mode, not a native rule/trigger definition system where a user declares 'on event X, do Y'. Missing for 10: explicit rule/trigger authoring UI or config, built-in event listeners (e.g., webhook triggers, issue-created triggers), and any documented automation-rules engine beyond CI invocation.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [claimed-docs] “Open Software Factory to see your delivery lifecycle as an automation coverage map.”
YYLO's integrations pull Slack messages and GitHub issues into its kanban system and return responses to source threads, which is a form of event-triggered automation, and run-until-completion/workflow-runner allow chained/looping actions. However there's no evidence of a general user-defined rule engine (conditions + custom triggers) — the event handling is limited to specific hardcoded integrations rather than an open rule-definition system. Missing for 10: a documented rules/conditions DSL, support for arbitrary custom event sources/triggers, and evidence of user-authored trigger logic beyond the built-in Slack/GitHub integrations.
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
- [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
- [claimed-docs] “Choose Workflow Runner when a step consumes `{{ steps.<id>.response }}`, a generated file, or a session from an earlier step.”
ai-native userSchedule recurring jobs or workflows
weight 2 · round to YYLOFactorynone0/10Evidence shows droid exec for CI/CD one-shot automation and API session management, but no documentation of scheduling or recurring/cron-style job execution exists anywhere in the pack. missing for 10: any mention of scheduling, cron, recurring triggers, or timed/repeated workflow execution.
YYLO supports repeatable workflows (YAML-saved contracts, `yy loop` shell repetition, run-until-completion looping, workflow-runner chaining) which cover automation-depth, but there is no evidence of a scheduler, cron-like trigger, or time-based recurring job execution — workflows appear to be manually invoked or run-to-completion rather than scheduled on a recurring basis. missing for 10: cron/schedule syntax or trigger mechanism, evidence of unattended recurring execution (e.g., daily/hourly runs), and independent confirmation of scheduling in production use.
- [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
- [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
- [claimed-docs] “Choose Workflow Runner when a step consumes `{{ steps.<id>.response }}`, a generated file, or a session from an earlier step.”
- [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
ai-native userVersion, review, and roll back my automations
weight 1 · round drawnFactory supports reviewing diffs and merging via git workflow (factory-docs-1, factory-docs-2), and packages automations as reusable Custom Droids/Skills (factory-docs-5), which implies some git-based versioning, but there is no explicit documentation of a version-history feature for Droids/Skills nor an explicit rollback mechanism for automations themselves. missing for 10: explicit versioning UI/history for Skills/Droids, dedicated rollback command or feature distinct from generic git revert.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “delegate scoped tasks to Custom Droids via /droids, and package reusable procedures as Skills with /skills or /create-skill”
YYLO ledger provides task versioning-like constructs (immutable task source, worktree branching, candidate composition, expected-old ref protection for merges) and workflow YAML contracts can be saved/reused, giving some review/rollback semantics via git-based merge protections. However there is no explicit 'automation version history', diff/review UI, or a documented rollback command for automations themselves beyond git branch/worktree mechanics. missing for 10: dedicated automation versioning/history view, explicit rollback command for a run/automation (not just git ref protection), review workflow UI, and independent/hands-on confirmation of these rollback flows.
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
- [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
- [claimed-docs] “The 0.2.1rc6 channel adds ID-first general Records and typed task, wiki, workflow, and artifact profiles.”
Autonomous implementation — end-to-end implementation by the agent — multi-file changes, task completionAutonomous implementation
End-to-end implementation by the agent — multi-file changes, task completion
End to end feature delivery
ai-native userHave an agent automatically generate and run tests to validate its own code changes before proposing them
weight 2 · round drawnFactorynone0/10Docs mention integration with 'tests' as part of Git workflow and bash-mode shell execution, plus readiness-report/readiness-fix commands, but none of this describes an agent autonomously generating and running tests to validate its own code changes before proposing a diff. Missing for 10: explicit documentation of automated test generation, self-validation loop, or evidence droid runs tests as a pre-proposal gate.
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “Press ! to toggle bash mode and run shell commands directly without AI interpretation.”
- [claimed-docs] “Run the /readiness-report slash command in a Factory App web or desktop session, or in the Droid CLI, to evaluate a repository's readiness l…”
- [claimed-docs] “Automatically fix failing criteria with the /readiness-fix slash command in a Factory App web or desktop session, or in the Droid CLI”
YYLOnone0/10The evidence explicitly states that tests and semantic reviews are 'explicit project checks outside merge' and that YYLO's merge step 'launches no models, chooses no reviewers, schedules no suites, and maintains no validation cache' (yylo-gh-6). While `yy loop` can repeat arbitrary shell commands, there is no evidence of an agent autonomously generating tests or validating its own changes before proposing them.
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
- [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
developerHave an agent autonomously diagnose and fix a reported bug
weight 3 · round to FactoryFactory's Droid CLI/exec and delegated task workflow support autonomous code changes (diff review and merge) and integrations like Jira/Linear/PagerDuty for bug tracking, plus tiered autonomy for unattended operation, which together plausibly support autonomous bug diagnosis and fixing. However, no evidence explicitly describes an end-to-end 'diagnose a reported bug from ticket to verified fix' workflow or hands-on validation of bug-fixing accuracy. Missing for 10: explicit bug-diagnosis workflow documentation, independent/hands-on evidence of successful autonomous bug fixes, and details on root-cause diagnosis capability.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [claimed-docs] “Connect Jira, Notion, Slack, Linear, PagerDuty, and MCP tools to keep development synchronized with team systems”
- [claimed-docs] “Automatically fix failing criteria with the /readiness-fix slash command in a Factory App web or desktop session, or in the Droid CLI”
YYLO orchestrates coding agents through task worktrees, kanban-driven work items, and iteration loops (run-until-completion, subagent tasking) that could be pointed at a bug-fix task, and it supports ingesting GitHub issues into kanban as a trigger. However there is no evidence of autonomous bug diagnosis (root-causing, log/trace analysis) as a distinct capability — the docs describe generic task/workflow orchestration and merge/validation boundaries rather than an end-to-end 'diagnose then fix' agent behavior. missing for 10: explicit diagnosis/root-cause capability, an end-to-end bug-fix case study or hands-on validation, evidence the agent itself (vs. the orchestrator) performs debugging reasoning.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
product-managerGo from a mockup or design to a working implementation without an engineering handoff
weight 2 · round to FactoryFactory's agent-readiness docs explicitly describe the exact scenario: "A designer shares a mockup, and the system implements it without handoffs" (factory-docs-8), backed by delegation/review/merge workflow (factory-docs-1) and readiness tooling (factory-docs-9, factory-docs-10) that lets non-engineers trigger and validate implementation. Missing for 10: independent or hands-on corroboration of a PM-specific end-to-end mockup-to-merge case study, and detail on how a non-technical PM reviews/approves the diff without engineering involvement.
- [claimed-docs] “A designer shares a mockup, and the system implements it without handoffs.”
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Run the /readiness-report slash command in a Factory App web or desktop session, or in the Droid CLI, to evaluate a repository's readiness l…”
- [claimed-docs] “Automatically fix failing criteria with the /readiness-fix slash command in a Factory App web or desktop session, or in the Droid CLI”
YYLOnone0/10YYLO's evidence describes a CLI orchestrator for coding agents (task/worktree/merge/ledger workflows) aimed at developers and project operators, with no mention of ingesting mockups/designs or enabling a non-technical PM to go from a design to working code without engineering involvement.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
developerHave an agent implement a requested feature end-to-end, including writing tests
weight 3 · round to FactoryFactory's docs show agents can be delegated end-to-end feature tasks (delegate, diff review, merge), run in terminal/CI with test execution and git workflow, and orchestrate multi-feature projects via Missions, but no explicit first-party evidence confirms the agent autonomously writes tests as part of implementation. missing for 10: explicit documentation of test-writing behavior, independent/hands-on verification of end-to-end feature delivery.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration.”
YYLO documents an end-to-end task loop (yylo init --task ... --subagent claude, worktree creation, commit-and-queue candidate flow) showing an agent can implement a described feature autonomously, but the evidence explicitly states 'tests and semantic reviews are explicit project checks outside merge' — meaning YYLO's own agent loop does not itself guarantee test-writing as part of implementation, only that separate check scripts exist for validation. missing for 10: explicit evidence the invoked subagent writes/adds tests as part of a task, and any example showing test-authoring within the init/finish workflow.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
Environment setup
developerHave an agent automatically clone the repo, install dependencies, and configure its own working environment
weight 2 · round to YYLOFactory's Droid CLI/exec can run shell commands autonomously (bash mode, tiered autonomy for unconfirmed operations) and operates within a repo's terminal/Git workflow, which implies it could run clone/install commands, but no evidence explicitly describes an agent autonomously cloning a repo or bootstrapping its own dev environment from scratch. missing for 10: explicit documentation of automated repo cloning, dependency installation, or environment provisioning as a first-class capability, and any hands-on example showing this workflow.
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “Press ! to toggle bash mode and run shell commands directly without AI interpretation.”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
Docs and GitHub README describe `task start`/`yy init` hydrating a dedicated worktree from a protected base SHA and completing 'configured dependency hydration' before reporting WORKING, which covers automated environment setup and dependency install; the CLI is confirmed live on npm and the repo public. Missing for 10: explicit description of cloning an arbitrary remote repo (vs. hydrating a pre-defined workspace), and independent/hands-on confirmation that dependency install works end-to-end.
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
- [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”
Interactive takeover
developerTake over an in-progress agent task in my editor, terminal, or browser to finish or redirect the work
weight 2 · round to FactoryFactory explicitly supports multi-surface access (App/web, terminal via Droid CLI, browser) and delegating tasks, reviewing diffs, and merging from any of these surfaces, which implies continuity across surfaces. However, there's no explicit documentation of a 'takeover mid-task' handoff flow (e.g., pausing an in-progress session in one surface and resuming/redirecting it live in another) — the evidence shows task delegation and review/merge but not explicit interactive takeover semantics. Missing for 10: explicit documentation of resuming/redirecting an in-progress session across surfaces, and independent/hands-on confirmation of this handoff working smoothly.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
YYLO offers terminal-based session continuation (`yy continue SESSION_ID`) that lets a developer pick back up captured agent work rather than reconstructing it from scrollback, and task start/finish flows expose worktree/branch state that could be inspected or redirected from the CLI. However, there is no evidence of any editor integration or browser UI for taking over tasks — YYLO is documented purely as a CLI/orchestrator tool. Missing for 10: editor plugin/extension support, browser-based task takeover UI, and explicit interactive 'redirect mid-task' semantics beyond resuming a session.
- [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
developerSend follow-up instructions to an active agent session to steer its work without restarting
weight 2 · round to FactoryFactory's API reference explicitly supports creating and driving Droid sessions including sending messages within an active session (factory-docs-13), and the CLI is interactive by nature, implying follow-up prompts are possible without restarting. However, there is no explicit documentation describing mid-task interruption/steering while the agent is actively executing a long-running task (e.g., Missions or droid exec), so the steering-while-running behavior is not directly evidenced. Missing for 10: explicit docs on interrupting/redirecting an in-progress autonomous run, and independent/hands-on confirmation that follow-up messages actually steer ongoing work rather than queue for the next turn.
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration.”
YYLOnone0/10YYLO's docs describe task lifecycle (init/start/preflight/finish) and resuming a captured session via `yy continue SESSION_ID`, but there is no evidence of sending new instructions to an already-running agent session to redirect its work mid-flight; `continue` appears to resume/reattach rather than inject steering input. missing for 10: any documented mechanism for mid-session instruction injection or steering, evidence that an active agent process accepts new prompts without restart.
- [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
Sandbox execution
developerHave an agent safely execute code and install dependencies inside an isolated sandbox
weight 3 · round drawnFactorynone0/10Evidence describes tiered autonomy, bash mode, and CI/CD execution (droid exec) but never mentions an isolated sandbox environment for code execution or dependency installation; no container/VM isolation is documented.
YYLOnone0/10YYLO's docs describe git-worktree/branch isolation for tasks and merge safety, but none of the evidence mentions a sandboxed execution environment (container/VM) for running agent code or installing dependencies safely. Worktree isolation protects git state, not runtime/process isolation.
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
Human oversight — keeping a human in the loop — approvals, checkpoints, interruptsHuman oversight
Keeping a human in the loop — approvals, checkpoints, interrupts
Approval controls
developerConfigure an agent to auto-approve all its actions instead of confirming each one
weight 2 · round to FactoryFactory's docs confirm 'tiered autonomy' in droid exec that controls what operations run without manual confirmation, implying a configurable auto-approve mode for CI/batch use, but there's no explicit documentation of a full 'auto-approve all actions' toggle or its exact configuration options/flags. missing for 10: explicit config syntax/flag for full auto-approval, independent confirmation of behavior, coverage of auto-approve in interactive (non-exec) sessions.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
YYLOnone0/10The evidence describes YYLO's orchestration architecture (task worktrees, ledger, merge protections) but nothing addresses a configurable auto-approve/no-confirmation mode for agent actions; in fact merge land explicitly requires checks and human-oversight-style gating rather than blanket auto-approval. Missing for 10: any documented auto-approve flag/setting, evidence of confirmation prompts being bypassable, or explicit human-oversight configuration options.
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
product-managerApprove key agent decisions from my phone while agents continue working
weight 1 · round to FactoryDocs mention delegating tasks, reviewing diffs, and merging 'from the App or your terminal' and tiered autonomy that gates operations needing confirmation, implying some human-in-the-loop review outside the terminal, but there is no explicit evidence of a mobile/phone app or of approving in-flight agent decisions remotely while agents keep working. Missing for 10: explicit mobile app/phone interface, evidence of asynchronous approval while agent continues running, and independent confirmation of this workflow.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
YYLOnone0/10YYLO is documented purely as a CLI/terminal orchestrator (yylo/yy commands, ledger, worktrees, merge gating) with no mention of any mobile app, phone notification, or remote-approval interface for product managers. The axis is plausible for an agent-orchestration tool but no evidence supports it.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
engineering-leadSet tiered autonomy levels controlling what an agent can do without manual confirmation
weight 3 · round to FactoryFactory explicitly documents 'tiered autonomy' in droid exec to control which operations run without manual confirmation, directly matching the story, but this is scoped to the CI/CD-oriented droid exec mode rather than a broader, configurable set of autonomy tiers across all agent surfaces. missing for 10: detail on specific tier levels/permissions, configuration UI or granular controls, and evidence this applies uniformly across App/CLI sessions, not just droid exec.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
YYLOnone0/10Evidence shows preflight/read-only checks, merge protections, and validation boundaries, but there is no mention of configurable tiered autonomy levels or a settings mechanism letting an engineering-lead define graduated confirmation thresholds for agent actions. missing for 10: explicit autonomy-level configuration, tiered permission settings, evidence of user-controlled confirmation thresholds.
Model control
ai-native userHave each task prompt automatically routed to the most suitable underlying model
weight 2 · round drawnFactorynone0/10No evidence describes automatic routing of prompts to the most suitable underlying model; docs mention model-agnostic droid workflows, custom droids, and orchestration but nothing about auto-selecting models per task.
YYLOnone0/10Evidence shows YYLO lets users manually specify a subagent/model (e.g. `--subagent claude`) but nothing describes automatic routing of a task prompt to the 'most suitable' underlying model based on task characteristics. missing for 10: any evidence of automatic model-selection logic, routing criteria, or multi-model comparison/selection mechanism.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
engineering-leadSwitch away from automatic model selection to a specific model of my choice
weight 1 · round to YYLOFactorynone0/10No evidence in the pack mentions model selection, automatic model routing, or the ability to choose a specific model over an automatic default; the docs cover CLI usage, integrations, missions, and readiness reports but nothing about model choice controls.
The CLI init command shows a --subagent flag (e.g. 'claude') letting a user specify which model/agent to use instead of relying on defaults, implying manual model selection is possible; however there is no documentation of an explicit 'automatic model selection' mode being overridden, no list of supported models, and no engineering-lead-oriented control/settings UI shown. missing for 10: explicit documentation of an automatic/default model-selection mode, a full list of selectable models, and confirmation that this override is persistent/configurable at a project or team level.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
Visibility monitoring
developerWatch what a running agent is doing in real time, including its current status
weight 3 · round to FactoryFactory's session API lets you create and manage Droid sessions—including lifecycle, settings, and messages—implying some ability to track a running agent's state, and the App/CLI let you review diffs as work progresses. However, there is no explicit documentation of a live status dashboard, streaming logs, or real-time progress view of an in-flight agent. Missing for 10: dedicated real-time monitoring UI/stream, explicit 'live status' feature documentation, independent confirmation of live tracking.
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
The GitHub docs mention a successful run ending in a 'watch receipt' with a state field (e.g. COMPLETED, exit_code, log_bytes), implying some status-tracking mechanism exists, and 'task start' reports a WORKING state before completion. However there is no dedicated 'watch' command, live dashboard, or streaming log evidence showing real-time observation of an in-progress agent's actions. missing for 10: explicit real-time streaming/monitoring command or UI, documentation of live status polling during execution, independent confirmation of watch behavior.
- [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
developerGet notified when an agent completes a task or needs my input
weight 2 · round to YYLOFactory integrates with Slack and PagerDuty and supports tiered autonomy that pauses for manual confirmation, implying some mechanism for alerting developers when input is needed, but there's no explicit documentation of a notification feature for task completion or input requests. missing for 10: explicit notification/alert documentation, evidence of completion pings, confirmation of Slack/PagerDuty being used specifically for task-status alerts.
- [claimed-docs] “Connect Jira, Notion, Slack, Linear, PagerDuty, and MCP tools to keep development synchronized with team systems”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
YYLO emits watch receipts with a COMPLETED state/exit_code after a run finishes, and its Slack/GitHub integrations can return completed responses to the originating thread, giving developers a way to learn a task finished. However there's no evidence of a proactive notification for when an agent 'needs input' mid-task, nor any push/alert channel beyond polling receipts or the source-thread reply. Missing for 10: explicit 'needs input' alerting, a dedicated notification/webhook system, and independent confirmation the integration loop works end-to-end.
- [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
Intent to spec — stories about intent to spec in this arenaIntent to spec
Stories about intent to spec in this arena
Natural language task intake
developerDescribe a feature or bug in plain language and have it automatically turned into a scoped implementation task
weight 3 · round drawnFactory supports delegating tasks described in plain language (via droid CLI, App, or Missions) which get turned into scoped, executable work with diffs to review and merge, and readiness tooling helps scope repo work automatically. However, there's no explicit documented workflow for turning a raw bug/feature description into a formal 'scoped implementation task' spec artifact (e.g., structured ticket/spec generation before execution) distinct from just running the agent. missing for 10: explicit intent-to-spec artifact generation/preview step, independent/hands-on evidence of accurate scoping from vague input, and detail on how ambiguous requests are clarified before execution.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “delegate scoped tasks to Custom Droids via /droids, and package reusable procedures as Skills with /skills or /create-skill”
- [claimed-docs] “A designer shares a mockup, and the system implements it without handoffs.”
- [claimed-docs] “Run the /readiness-report slash command in a Factory App web or desktop session, or in the Droid CLI, to evaluate a repository's readiness l…”
- [claimed-docs] “Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration.”
YYLO's CLI lets a developer pass a plain-language task string (e.g. `yylo init --task "Describe one verifiable outcome"` or `yy ledger create "Validate recovery"`) which is then hydrated into a dedicated branch/worktree and handed to a subagent (yylo-docs-1, yylo-docs-2, yylo-gh-4, yylo-docs-11). This covers the 'turned into a scoped implementation task' half of the story, but there's no evidence of NLP-based scoping/decomposition logic — the description appears passed through largely as-is rather than analyzed/refined into a structured spec. Missing for 10: evidence of automatic task decomposition or requirement extraction from free-text input, and independent/hands-on confirmation that vague feature/bug descriptions produce well-scoped tasks.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
product-managerConvert user feedback submissions into structured tasks with proposed scope
weight 2 · round to YYLOFactorynone0/10Factory documents task delegation, Missions planning, and integrations with Jira/Linear/Notion, but nothing in the evidence describes ingesting user feedback submissions and outputting a structured task with proposed scope — this specific PM workflow is not documented.
YYLO can ingest external feedback (Slack messages, GitHub issues) directly into its kanban/ledger as structured tasks (yylo-docs-10), and a dedicated `feedback-yylo` CLI binary is confirmed live on npm (yylo-probe-rt-1), suggesting a feedback-to-task pathway exists. However, there is no documented mechanism for generating a 'proposed scope' alongside the task — no scope estimation, sizing, or planning artifact is described anywhere in the docs or GitHub evidence. Missing for 10: explicit scope-proposal output tied to feedback conversion, documentation of what the feedback-yylo binary actually produces, and any PM-facing evidence of structured scoping fields.
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
- [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
Plan approval
developerReview and approve an agent's implementation plan before any code changes are made
weight 3 · round to FactoryFactory's tiered autonomy in droid exec implies some operations require manual confirmation before running, and Missions offer 'plan and execute' orchestration, suggesting a planning phase exists, but there is no explicit documentation of a discrete implementation-plan artifact that a developer reviews and approves before any code changes are made — the described workflow (docs-1) instead centers on reviewing the diff/output after changes. missing for 10: explicit plan-approval UI/step description, evidence of a pre-execution plan artifact, confirmation that no code is touched until plan is approved.
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [claimed-docs] “Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration.”
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
YYLOnone0/10Evidence describes YYLO's task lifecycle (init, start, preflight read-only, finish queuing a candidate, merge land) but nothing indicates the agent produces an implementation plan that a developer reviews and approves before any code is written — preflight/checks occur on already-produced work, not a pre-code plan gate.
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
engineering-leadApprove a task's scope and contract before an agent is allowed to modify the repository
weight 2 · round drawnFactory documents tiered autonomy that limits what operations run without manual confirmation and diff review before merge, which implies some human-gate mechanics, but there's no explicit evidence of an engineering-lead approving a task's defined scope/contract *before* the agent is permitted to touch the repository — reviews are framed as post-hoc diff review rather than pre-execution scope sign-off. Missing for 10: explicit scope/contract definition step, an approval gate that blocks agent execution until lead sign-off, and evidence this is lead-specific rather than generic autonomy tiering.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
YYLO documents a task/contract concept (YAML contracts, ledger tasks) and isolates agent work in dedicated branches/worktrees with a read-only preflight before any commit is queued (yylo-docs-2, yylo-docs-4, yylo-gh-4), which implies some spec-first gating. However there is no documented human approval/sign-off step where an engineering-lead explicitly reviews and approves scope/contract before the agent is permitted to start modifying the repo—task start appears automatic once invoked. Missing for 10: explicit lead-approval gate/workflow, evidence of a review UI or command requiring human sign-off, and confirmation that agent modification is blocked pending that approval.
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
- [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
Ticket driven tasking
developerAssign a coding task to an agent directly from an existing issue or ticket
weight 3 · round to YYLOFactory documents integrations with Jira and Linear ('Connect Jira, Notion, Slack, Linear, PagerDuty, and MCP tools to keep development synchronized with team systems'), implying tickets can feed into agent workflows, but there is no explicit documentation of assigning/triggering a droid task directly from an issue or ticket UI. missing for 10: explicit workflow/screenshot showing task creation from a Jira/Linear ticket, confirmation that ticket assignment auto-triggers an agent session, independent corroboration.
- [claimed-docs] “Connect Jira, Notion, Slack, Linear, PagerDuty, and MCP tools to keep development synchronized with team systems”
YYLO integrations pull GitHub issues into its kanban ledger and return completed responses to the source thread, and ledger tasks can then be started with a subagent via task start or yylo init, supporting the flow of turning an issue into an agent task. Missing for 10: a single documented command that directly converts one specific issue into an agent task in one step, and hands-on confirmation the GitHub-issue import works end-to-end.
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userExport all of my data in open formats and leave
weight 3 · round to YYLOFactorynone0/10No evidence addresses data export or portability in open formats, nor any account-deletion/data-takeout mechanism; the docs focus on session management, CLI, and integrations, not exporting user data to leave the platform.
Workflow contracts can be saved as YAML (yylo-docs-4) and the CLI/ledger source is fully open-source under MIT (yylo-probe-rt-2), suggesting no vendor lock-in, but there is no documented single 'export all data' command covering ledger records, task history, sessions, and artifacts in open formats. Missing for 10: an explicit data-export command/feature, documentation of export formats for ledger/kanban/session data, and confirmation that all state (not just workflow YAML) is portable.
- [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
- [claimed-docs] “The 0.2.1rc6 channel adds ID-first general Records and typed task, wiki, workflow, and artifact profiles.”
- [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
ai-native userRead the product's source under an open license
weight 2 · round to YYLOFactorynone0/10No evidence of an open-source license or publicly available source code for Factory/Droid; all evidence points to closed docs and a proprietary CLI/platform. missing for 10: any license file, GitHub repo, or open-source statement covering the product's source code.
The GitHub repo is public and licensed under MIT, confirmed by a runtime probe reading the LICENSE file directly, and the repo (yylo-dev/yylo) is documented as the CLI orchestrator's source. missing for 10: no independent third-party audit or community commentary confirming completeness of the published source beyond the license file check.
- [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
ai-native userSelf-host the core product
weight 3 · round to YYLOFactorynone0/10Factory is presented as a cloud-hosted platform (Factory App, Droid CLI connecting to hosted services, API sessions) with no evidence of a self-hostable core server or on-prem deployment option anywhere in the docs or probes.
YYLO is an open-source, MIT-licensed CLI orchestrator (installable via npm, source on GitHub) that runs locally against a user's own repo/agents, so self-hosting the core product is inherently satisfied — confirmed by the public npm registry listing and the MIT LICENSE in the public repo. missing for 10: no dedicated self-hosting/deployment guide (e.g. server install, Docker, or persistent-service setup instructions) and no independent third-party report of someone self-hosting it in production.
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
- [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
Pricing limits — free-tier ceilings, usage caps, and rate limits before you have to payPricing limits
Free-tier ceilings, usage caps, and rate limits before you have to pay
Enterprise licensing
engineering-leadLicense an enterprise deployment with SSO and commercial support for organization-wide rollout
weight 2 · round drawnFactorynone0/10No evidence pack items mention enterprise licensing, SSO, or commercial support offerings; documentation only covers product features like Droid CLI, MCP integration, and readiness reports. Missing for 10: any mention of SSO/SAML, enterprise tier, commercial support SLAs, or org-wide licensing terms.
YYLOnone0/10YYLO's evidence pack shows only an open-source CLI orchestrator (MIT-licensed, npm package) with no mention of enterprise licensing tiers, SSO integration, or commercial support offerings; there is no pricing/plans page or enterprise sales material in evidence. missing for 10: enterprise/SSO licensing tier, commercial support plans, organization-wide deployment documentation.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
- [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
Model flexibility
engineering-leadBring my own LLM or API key so agents run on the model of my choice
weight 2 · round drawnFactorynone0/10No evidence pack item mentions bringing your own LLM, custom API keys, or model selection/configuration options; all docs focus on CLI, integrations, and workflow features.
YYLOnone0/10Evidence shows a `--subagent claude` CLI flag implying some agent selection, but there is no documentation of configuring API keys, choosing alternate LLM providers, or any pricing/billing control for engineering leads. Missing for 10: explicit BYO-API-key setup, multi-provider/model configuration docs, and any pricing-limits guidance.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userControl data retention and deletion
weight 2 · round drawnFactorynone0/10No evidence pack items address data retention policies, deletion controls, or privacy settings for user data; all citations relate to product features like CLI, MCP integrations, and agent workflows rather than privacy posture.
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnFactorynone0/10No evidence in the pack mentions telemetry, usage tracking, data collection, or any opt-out/privacy settings for Factory or the Droid CLI.
Repo integration — stories about repo integration in this arenaRepo integration
Stories about repo integration in this arena
Knowledge context
developerAdd a context file describing my codebase conventions so agents generate more relevant plans and code
weight 3 · round drawnFactorynone0/10The evidence pack does not mention any context file mechanism (e.g., AGENTS.md, .factory config, or similar) for describing codebase conventions to guide agent behavior; it covers CLI usage, integrations, readiness reports, and missions but nothing about persistent repo-convention context files.
YYLOnone0/10The evidence pack covers task orchestration, kanban ledgers, merge protections, and workflow runners, but nowhere describes a context/conventions file that agents read to generate more relevant plans or code. No mention of AGENTS.md, project instructions, or codebase-convention configuration exists in the docs or GitHub items provided.
Project management integration
product-managerConnect issue trackers like Jira, Linear, ClickUp, or Monday.com so agents can manage tickets directly
weight 3 · round to FactoryDocs confirm Jira and Linear integration explicitly (factory-docs-4), but ClickUp and Monday.com are not mentioned anywhere in the evidence, and there's no detail on ticket management workflows (creating/updating tickets) beyond 'connecting' systems to sync development. Missing for 10: ClickUp integration, Monday.com integration, concrete ticket-management/CRUD workflows via these connectors, independent corroboration.
- [claimed-docs] “Connect Jira, Notion, Slack, Linear, PagerDuty, and MCP tools to keep development synchronized with team systems”
YYLOnone0/10The integrations doc only mentions bringing Slack messages or GitHub issues into kanban (yylo-docs-10); there is no mention of Jira, Linear, ClickUp, or Monday.com anywhere in the evidence pack. Missing for 10: any documented connector or API integration for Jira, Linear, ClickUp, or Monday.com.
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
Version control integration
developerConnect a GitHub repository so an agent can access the code and open pull requests against it
weight 3 · round to FactoryDocs indicate Factory works within Git workflows (delegate tasks, review diffs, merge from App/terminal) and can run in CI/CD via droid exec, implying repo access and PR-opening capability, but there is no explicit documentation describing connecting/authorizing a GitHub repository or an explicit PR-creation feature. Missing for 10: explicit GitHub repo connection/auth flow documentation, explicit 'open pull request' feature description, and independent/hands-on confirmation of PR creation.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
YYLOnone0/10Evidence shows YYLO operates on local git worktrees/branches and has an internal 'merge land' step, and can pull GitHub issues into its kanban, but there is no evidence of connecting a GitHub repository as a remote and having the agent open pull requests against it — the merge feature explicitly stays local/internal with no GitHub PR API integration mentioned.
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
developerGrant an agent access to my repositories with a one-click install, without complex setup
weight 2 · round drawnFactorynone0/10Evidence shows Factory integrates with Git workflows, CLI, and external tools like Jira/Slack/MCP, but there is no mention of a one-click GitHub/repo install or simplified OAuth-based repo authorization flow. Setup appears to require CLI installation and configuration rather than a one-click grant.
YYLOnone0/10YYLO is documented as a CLI orchestrator requiring `npm install -g @yylo/cli` plus explicit `yylo init`/`task start` workflows that freeze SHAs, create worktrees, and hydrate dependencies — this is CLI-based setup, not a one-click repo-access grant. No evidence describes a GitHub App-style one-click install or OAuth flow for repo access. Missing for 10: any one-click install/authorization mechanism, evidence of simplified non-CLI onboarding, or a hosted install button.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
Review quality gates — quality gates on changes — review flow, required checks, merge protectionReview quality gates
Quality gates on changes — review flow, required checks, merge protection
Ci remediation
engineering-leadHave failed CI workflows automatically diagnosed and fixed with a proposed pull request
weight 3 · round to FactoryFactory's droid exec is explicitly designed to run in CI/CD pipelines as a one-shot task with tiered autonomy, and Droid CLI integrates with Git workflows, suggesting the building blocks exist for automating CI fixes. However, there is no direct evidence of a dedicated feature that detects a failed CI workflow, diagnoses the failure, and automatically opens a proposed pull request end-to-end. missing for 10: explicit CI-failure detection/trigger integration, automatic diagnosis-to-PR workflow documentation, and any hands-on/independent proof of this specific use case.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
YYLOnone0/10YYLO is a CLI orchestrator for coding agents/workflows with kanban, ledger, and merge tooling, but nothing in the evidence pack mentions CI workflow failure detection, diagnosis, or auto-generating a fix PR from a failing CI run. Merge/land explicitly excludes running tests or validation ('Tests and semantic reviews are explicit project checks outside merge'), which is the opposite of an integrated CI-fix loop.
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
developerTrigger an agent from CI/CD pipelines to fix a broken build or failing test
weight 2 · round to FactoryFactory explicitly documents `droid exec` as a one-shot CLI command designed for CI/CD pipelines, shell scripts, and batch processing, with tiered autonomy controls for unattended operation — directly enabling triggering an agent from CI to fix builds/tests. Missing for 10: a concrete worked example of a CI pipeline invoking droid exec on a failing test/build, and independent/hands-on corroboration beyond vendor docs.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [probe] “official CLI documented at https://docs.factory.ai/droid-cli/quickstart”
YYLOnone0/10YYLO is documented as a CLI orchestrator with kanban tasks, workflow/parallel runners, and Slack/GitHub-issue integrations, but nothing in the evidence describes triggering it from a CI/CD pipeline or having it react to a failing build/test. Since it's a scriptable CLI, this axis plausibly applies, but there is no documented CI hook, GitHub Actions example, or build-failure-triggered workflow.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
Diff review
developerConfigure an agent to automatically open a pull request when its task completes
weight 2 · round to FactoryDocs show git workflow integration (droid-cli git workflow, delegate task then review diff and merge, droid exec for CI/CD pipelines) which implies PR-related automation, but there is no explicit documentation of a feature to automatically open a pull request when a task completes. Missing for 10: explicit config/flag for auto-PR creation, first-party example of a droid opening a PR on completion, independent/hands-on confirmation.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
YYLOnone0/10YYLO's docs describe task branches, worktrees, and an internal 'merge land' step that composes a candidate directly, explicitly stating merge 'launches no models, chooses no reviewers'—there is no mention anywhere of opening a GitHub pull request on task completion, only importing issues into kanban and returning responses to source threads. No CLI flag, workflow step, or integration doc references PR creation.
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
developerReview a diff of an agent's changes and approve it before it becomes a pull request
weight 3 · round to FactoryDocs explicitly describe the delegate-review-merge workflow ('Delegate a task, review the diff, and merge from the App or your terminal') and tiered autonomy controls that gate what runs without confirmation, supporting a review-before-PR gate. However, there is no detailed documentation of the diff review UI itself, approval mechanics, or independent/hands-on confirmation of this exact flow. Missing for 10: dedicated diff-review UI documentation, explicit approval-step mechanics, and independent verification of the review-before-PR gate.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
YYLOnone0/10Docs describe worktrees, candidate branches, and a 'merge land' step, but nowhere is there evidence of a diff-review UI or an explicit developer approval gate before a pull request is opened; in fact merge is described as launching 'no models, no reviewers' and reviews are called 'explicit project checks outside merge', with no PR-creation flow documented at all.
- [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
- [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
Pr review automation
ai-native userHave incoming issues automatically triaged with severity suggested and routed to the right owner
weight 2 · round drawnFactorynone0/10Factory documents integrations with issue trackers like Jira, Linear, and PagerDuty (factory-docs-4) and generic custom droid/skill automation (factory-docs-5), but there is no evidence of an automated triage workflow that suggests severity or routes issues to an owner. missing for 10: any documented triage feature, severity classification logic, or owner-routing capability.
- [claimed-docs] “Connect Jira, Notion, Slack, Linear, PagerDuty, and MCP tools to keep development synchronized with team systems”
- [claimed-docs] “delegate scoped tasks to Custom Droids via /droids, and package reusable procedures as Skills with /skills or /create-skill”
YYLOnone0/10YYLO's integrations feature only pulls GitHub issues/Slack messages into a kanban board and returns responses to the source thread (yylo-docs-10); there is no evidence of automated severity classification or owner-based routing logic anywhere in the pack.
- [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
engineering-leadHave every pull request automatically reviewed with AI-generated inline comments
weight 3 · round drawnFactorynone0/10Evidence shows Factory's droid CLI/exec can review diffs, be triggered in CI/CD, and connect to Git workflows, but nothing in the pack describes automatic PR review with AI-generated inline comments posted to pull requests. Missing for 10: any documentation of automated PR-triggered review, inline comment generation on PRs, or GitHub/GitLab PR integration specifics.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
YYLOnone0/10YYLO's own docs describe it as a CLI orchestrator for coding-agent tasks, workflows, and receipt-backed merges — not a PR-review tool. Evidence explicitly states 'Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers' (yylo-gh-6), meaning there is no automated AI-generated inline PR review capability in the product.
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
- [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
Readiness checks
engineering-leadAutomatically fix failing agent-readiness criteria in my repository
weight 1 · round to FactoryFactory explicitly documents a /readiness-fix slash command that automatically fixes failing agent-readiness criteria, usable from the Factory App or Droid CLI, complementing the /readiness-report diagnostic command. This directly matches the story's ask, though only first-party docs support it with no independent/hands-on corroboration. Missing for 10: independent or hands-on verification that /readiness-fix reliably resolves criteria, and detail on which criteria types it can/cannot auto-fix.
- [claimed-docs] “Run the /readiness-report slash command in a Factory App web or desktop session, or in the Droid CLI, to evaluate a repository's readiness l…”
- [claimed-docs] “Automatically fix failing criteria with the /readiness-fix slash command in a Factory App web or desktop session, or in the Droid CLI”
YYLOnone0/10YYLO's diagnostic tool (`doctor workspace`) explicitly never fetches or changes the workspace, and merge/tests are described as explicit checks with no automated remediation; there is no documented feature that automatically fixes failing agent-readiness criteria.
engineering-leadRun a readiness report that evaluates how ready my repository is for autonomous agents
weight 2 · round to FactoryFactory explicitly documents a `/readiness-report` slash command (in App or Droid CLI) that evaluates a repository's agent-readiness level, plus a companion `/readiness-fix` command to auto-remediate failing criteria, directly matching the engineering-lead's story. Missing for 10: independent/hands-on validation of report contents and no sample report output shown.
- [claimed-docs] “Run the /readiness-report slash command in a Factory App web or desktop session, or in the Droid CLI, to evaluate a repository's readiness l…”
- [claimed-docs] “Automatically fix failing criteria with the /readiness-fix slash command in a Factory App web or desktop session, or in the Droid CLI”
- [claimed-docs] “A designer shares a mockup, and the system implements it without handoffs.”
YYLO ships a `doctor workspace` check that flags actionable topology problems without mutating the repo, and its GitHub description references 'release-readiness boundaries,' which gesture at repo-readiness diagnostics, but there is no documented dedicated report scoring or evaluating overall repository readiness for autonomous agents. missing for 10: a named readiness-report command/output, criteria for 'agent readiness' beyond topology checks, and any sample report artifact.
Scale parallelism — running many jobs at once — concurrency, fleets, queueingScale parallelism
Running many jobs at once — concurrency, fleets, queueing
Concurrent execution
engineering-leadRun many agent tasks concurrently to scale delivery throughput
weight 3 · round to FactoryFactory provides several building blocks for scaling agent work: droid exec is designed for one-shot, CI/CD, and batch processing use cases, the Sessions API lets you create and manage multiple Droid sessions programmatically, and Missions support orchestrating large multi-feature projects with structured coordination. Together these imply the ability to run many concurrent tasks, but no evidence explicitly states a documented concurrency limit, dashboard for tracking many simultaneous droids, or independent case study proving throughput scaling. Missing for 10: explicit concurrency/parallelism guarantees or limits, a multi-task monitoring UI description, and independent/hands-on validation of running many tasks simultaneously.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration.”
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [claimed-docs] “Open Software Factory to see your delivery lifecycle as an automation coverage map.”
YYLO documents a 'bounded concurrent fan-out' parallel-runner for independent kanban tasks with structured evidence per item, plus run-until-completion looping, which supports running multiple agent tasks concurrently. However, evidence lacks details on concurrency limits, scaling numbers, resource isolation at scale, or independent/hands-on validation of throughput gains. missing for 10: concrete concurrency limits/benchmarks, independent third-party validation of parallel scaling, evidence of large-scale (10s-100s of tasks) usage in production.
- [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
- [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
- [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
Deployment flexibility
engineering-leadSelf-host agent infrastructure locally, in containers, or on my own VMs
weight 2 · round to YYLOFactorynone0/10No evidence describes self-hosting Factory's agent infrastructure locally, in containers, or on customer-owned VMs; all evidence points to Factory's own cloud-hosted App, CLI, and API rather than a deployable/self-hosted backend.
YYLO is an open-source, MIT-licensed CLI (npm package + public GitHub repo) that runs locally as an orchestrator, implying it can be run on a developer's own machine, in containers, or VMs since it's just a Node CLI operating on a local git worktree. However, there is no explicit documentation of container/VM deployment, Docker images, self-hosting guides, or infrastructure requirements for running at scale. missing for 10: explicit self-hosting/deployment docs (Docker/container images, VM setup guides), infrastructure/scaling guidance, and confirmation of statelessness or multi-instance operation for parallel agent infrastructure.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
- [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
- [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”
Headless automation
developerRun an agent headlessly inside CI/CD pipelines and shell scripts
weight 2 · round to FactoryFactory explicitly documents droid exec as a one-shot headless command designed for CI/CD pipelines, shell scripts, and batch processing, with tiered autonomy controls for unattended operation. Missing for 10: independent/hands-on confirmation of real-world CI pipeline usage beyond first-party docs.
- [claimed-docs] “droid exec runs as a one-shot command that completes a task and exits, making it ideal for CI/CD pipelines, shell scripts, and batch process…”
- [claimed-docs] “Droid exec uses tiered autonomy to control what operations can run without manual confirmation.”
- [claimed-docs] “Use the Droid CLI to run Factory from your terminal, editor, tests, and Git workflow.”
YYLO is a CLI-first orchestrator with commands (init, task start, ledger, loop, workflow-runner, parallel-runner) that are inherently scriptable and non-interactive, and its runtime bins (yylo, yy, ypl) are published on npm confirming CLI availability. However, there's no explicit CI/CD documentation, no exit-code/error-handling guarantance for pipeline use beyond doctor workspace, and no CI examples (GitHub Actions, GitLab CI, etc.) or headless/no-TTY confirmation. missing for 10: explicit CI/CD pipeline examples or docs, confirmed non-interactive/headless mode guarantees, exit-code contract documentation for scripting, independent hands-on CI usage reports.
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
- [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
- [github] “`doctor workspace` is intentionally nonzero when it finds an actionable topology problem; it never fetches or changes the workspace.”
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
Not comparable on these axes
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · not comparableFactorynone0/10No evidence of scoped or least-privilege API credential/token issuance for agents; docs mention API sessions and integrations (Jira, Slack, MCP) but nothing about credential scoping, permission tiers for API keys, or least-privilege access control. Tiered autonomy (factory-docs-7) governs action confirmation, not credential scoping.
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableFactoryn/aFactory is an agentic coding platform focused on delegating software development tasks (code diffs, PRs, readiness reports), not a data analytics or BI product that surfaces AI-generated insights/suggestions from a user's own data. This story is a category error for this product type.
YYLOnone0/10YYLO is an orchestration/CLI tool for running coding agents, workflows, and task ledgers; it launches subagents to perform tasks but nothing in the evidence describes it generating analytic insights or suggestions from a user's own data. Merge/validation explicitly avoids invoking models (yylo-gh-6), and no docs mention dashboards, analytics, or AI-generated insight surfacing.
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
developerAttach a marked-up screenshot or mockup to a task so the agent implements the correct visual change
weight 2 · not comparableFactorynone0/10Evidence only mentions a designer sharing a mockup conceptually (factory-docs-8), with no documented capability to attach an image/screenshot with markup annotations to a task or session, nor any multimodal image-input feature described.
- [claimed-docs] “A designer shares a mockup, and the system implements it without handoffs.”
YYLOn/aYYLO is a CLI orchestrator for text-based task/workflow management around coding agents; there is no evidence of image/screenshot attachment, mockup annotation, or any visual-input handling in its task creation or ledger features. Attaching marked-up visual mockups to drive implementation is a UI/multimodal-input capability outside this CLI orchestration product's category.
ai-native userDo everything through the API that I can do in the UI
weight 2 · not comparableFactory documents a real API (session creation/lifecycle) alongside its CLI and UI, showing some functional overlap, but there's no OpenAPI spec (404s on all candidate URLs) and no evidence that UI-exclusive features like Missions, Software Factory's coverage map, or readiness-report/fix slash commands are exposed via the API. missing for 10: documented API parity for Missions, Software Factory, and readiness commands; a public OpenAPI/schema confirming full surface coverage.
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
- [claimed-docs] “Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration.”
- [claimed-docs] “Open Software Factory to see your delivery lifecycle as an automation coverage map.”
- [claimed-docs] “Run the /readiness-report slash command in a Factory App web or desktop session, or in the Droid CLI, to evaluate a repository's readiness l…”
- [claimed-docs] “Automatically fix failing criteria with the /readiness-fix slash command in a Factory App web or desktop session, or in the Droid CLI”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.factory.ai/openapi.json, https://docs.factory.ai/swagger.json, https://docs.factory.ai/…”
YYLOn/aYYLO is a CLI/command-line orchestrator (yy/yylo commands) with no evidence of any graphical UI to compare against; the story presumes a UI+API product with parity concerns, which doesn't fit a CLI-first tool where the CLI itself is the sole interface.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
- [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
engineering-leadSee and manage plan-based daily task and concurrency limits for agent workflows
weight 2 · not comparableFactorynone0/10No evidence of plan-based daily task limits, concurrency caps, or admin controls for managing such limits; docs cover CLI, sessions, missions, and integrations but nothing on usage/plan limit visibility or management.
YYLOn/aYYLO is a self-hosted, open-source CLI orchestrator with no evidence of a hosted plan/pricing model or subscription tiers; concepts like 'plan-based daily task and concurrency limits' apply to SaaS pricing tiers, not to a locally-run open-source tool where users control their own concurrency via config (e.g., parallel-runner). This story's axis (plan/subscription-based usage limits) does not fit this product's category.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
- [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
ai-native userChoose where my data is stored (region/residency)
weight 2 · not comparableFactorynone0/10No evidence in the pack addresses data residency, regional storage options, or compliance/data-location controls; all evidence covers agent workflows, CLI, and integrations unrelated to data storage location.
YYLOn/aYYLO is a CLI orchestrator that runs locally on the user's own machine/repo, coordinating coding agents and git workflows—it does not store user data in a hosted service where region/residency would be a choice. Data residency is a category error for a local CLI tool rather than an unmet capability.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableFactorynone0/10No evidence in the pack addresses data usage/training opt-out, privacy policy, or data retention controls; the docs focus entirely on product features like CLI, missions, and integrations.
YYLOn/aYYLO is a CLI orchestrator for coding agents and repo workflows, not a data-processing/AI training service; the axis of preventing data from being used for AI model training does not apply to this kind of product, and nothing in the evidence pack even implies YYLO handles user data for model training purposes.
developerTag an agent in a chat thread to discuss and delegate a bug or task
weight 2 · not comparableFactory's docs mention connecting Slack as an integration to 'keep development synchronized with team systems,' implying some chat-based interaction, but there is no explicit evidence of an @-mention/tagging mechanism in a chat thread to discuss or delegate a specific bug/task to the agent. Missing for 10: explicit Slack @droid tagging workflow, thread-based task delegation UI, and confirmation that discussion happens inline in chat rather than just triggering external actions.
- [claimed-docs] “Connect Jira, Notion, Slack, Linear, PagerDuty, and MCP tools to keep development synchronized with team systems”
YYLOn/aYYLO is a CLI orchestrator for coding agents and repo workflows, not a chat/messaging interface where users tag agents in threads; its integrations (yylo-docs-10) pull Slack/GitHub items into a kanban board rather than supporting in-thread @-mention delegation. This is a category mismatch, not a missing feature.
developerQuery generated documentation for any public or private repository
weight 1 · not comparableFactorynone0/10The evidence pack covers Factory's CLI, agent-readiness reports, missions, and integrations, but nothing describes generating or querying documentation for a repository's codebase (e.g., an auto-generated repo wiki/docs feature). This is a plausible capability for a repo-integrated dev tool, so the axis applies, but no supporting evidence exists.
engineering-leadHave security alerts automatically validated and remediated with an opened pull request
weight 2 · not comparableFactorynone0/10Evidence covers task delegation, CLI automation, readiness reports/fixes, and CI/CD execution, but nothing describes ingesting security alerts (e.g., from a scanner like Dependabot/Snyk) and automatically validating and remediating them via an opened PR. No security-alert-specific workflow or integration is documented.
YYLOn/aYYLO is a CLI orchestrator for coding-agent task workflows, kanban tasks, and merge/candidate management, not a security-scanning or SCA/dependency-alert tool; there is no concept of security alerts to validate. This is a category mismatch rather than an unmet capability.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
engineering-leadCreate agent sessions on behalf of other users in my organization
weight 2 · not comparableFactorynone0/10The API reference (factory-docs-13) shows session creation/management exists, but nothing in the evidence indicates an org-admin or lead can create/manage sessions on behalf of other specific users within an organization. missing for 10: evidence of org-level user impersonation, admin controls for delegating sessions to teammates, or role-based session ownership across users.
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
YYLOn/aYYLO is a single-user CLI orchestrator for coding agents run locally; it has no organization/user-management, multi-tenant, or delegated-access model referenced anywhere in the evidence. Creating sessions 'on behalf of other users in an org' is a category mismatch for a local CLI tool rather than a missing feature.
- [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
- [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
developerUse a managed cloud offering to run agents without operating my own backend infrastructure
weight 2 · not comparableFactory's docs describe a hosted 'Factory App' (web/desktop) where users delegate tasks and review diffs without local setup, plus an API for creating and managing Droid sessions server-side, indicating a managed backend rather than self-hosted infra. Missing for 10: independent/hands-on confirmation of the cloud service's scalability and infrastructure details beyond first-party docs.
- [claimed-docs] “Delegate a task, review the diff, and merge from the App or your terminal.”
- [claimed-docs] “Run the /readiness-report slash command in a Factory App web or desktop session, or in the Droid CLI, to evaluate a repository's readiness l…”
- [claimed-docs] “Automatically fix failing criteria with the /readiness-fix slash command in a Factory App web or desktop session, or in the Droid CLI”
- [claimed-docs] “Create and drive Droid sessions: manage their lifecycle, settings, and messages.”
YYLOn/aYYLO is a local CLI orchestrator that runs on a developer's own machine/repo (npm-installed, git worktrees, local kanban/ledger) rather than a managed cloud service; there is no evidence of a hosted runtime, cloud dashboard, or backend YYLO operates on the user's behalf. This story asks about offloading backend infra to a vendor-run cloud, which is a different product category than a CLI tool.